GH-700 study guide: GitHub Agentic Workflows

Design and implement agentic workflows and automations is the largest GH-700 skill area, at 25–30% of the exam. This lesson covers GitHub Agentic Workflows (gh-aw, after the command-line tool that runs them): choosing a task, breaking it into steps, writing the workflow file, and how it differs from Copilot automations. One example runs throughout: a weekly status summary posted as an issue. GitHub Agentic Workflows have been in public preview since June 2026, so details can change.

Now you can get Claude Certified and earn OpenAI badges and certifications too → Here's how

What the official study guide covers

What an agentic workflow is

An agentic workflow is a Markdown file that gives an AI agent a task and the rules for when and how it may act. GitHub Actions is GitHub's built-in automation service, which teams already use to run tests and builds. The agentic workflow is turned (compiled) into a normal Actions workflow, so it runs on the same machines and appears in the same run history.

The file has two parts. The frontmatter is a block of settings in YAML (a simple "name: value" format) between two --- lines at the top. The Markdown body below it holds the instructions in plain language. GitHub Copilot is the default agent, called the engine; the engine setting can choose Claude, Codex or Gemini instead.

Choosing a use case and breaking it into tasks

GitHub's documentation says standard Actions workflows suit deterministic work, such as builds, tests and deployments, where the same input must always give the same result. Agentic workflows suit work that needs reasoning: triage, investigation, review, research and writing, such as labelling new issues or weekly status reports.

Next, break the use case into tasks and decide where each one goes in the file:

Reading is granted, judgement is described in words, and every write is declared in advance as a safe output (a write the agent may request but cannot perform itself).

The worked example

This is .github/workflows/weekly-status.md, based on the examples in GitHub's documentation.

---
on: weekly on monday
permissions:
  contents: read
  issues: read
  pull-requests: read
tools:
  github:
    toolsets: [default]
safe-outputs:
  create-issue:
    title-prefix: "[weekly status] "
    labels: [status-report]
    close-older-issues: true
---

# Weekly status summary

Review this repository's activity from the last 7 days.

Create one issue titled "Week of" followed by today's date, with four sections:

1. Done: pull requests merged and issues closed, one line each with a link.
2. In progress: open pull requests updated this week.
3. Blocked: open issues labelled `blocked`, or where the latest comment asks for a decision.
4. Needs attention: open issues with no reply for more than 5 days.

Write for a manager who does not read code. Stay under 300 words.
If there was no activity, say so in one sentence.

The frontmatter, line by line

There is no network line, so the agent gets the default: only the basic infrastructure the run needs, not the open internet.

The instructions

The four numbered sections fix the shape of the report. The definitions of Blocked and Needs attention are the decision-making criteria: without them, two runs could sort the same issue differently. The last two lines set the reader, the length and what to do when there is nothing to report. GitHub's guidance is to write as if explaining the task to a new team member: be specific, use action verbs, give criteria where decisions must be consistent, and cover unusual cases.

Schedules, triggers and permissions

The on setting accepts any GitHub Actions trigger, such as an issue being opened, plus readable schedules. on: weekly on monday in the example is the short form; the longer form is on: followed by schedule: weekly on monday.

Times are in UTC unless you add an offset, such as daily around 9am utc-5. GitHub recommends the fuzzy forms. For triggers people cause, such as a new issue, only users with the admin, maintainer or write role can start the workflow by default.

Note that the agent job gets no write access to repository content. One permission looks like an exception: in an organization with Copilot, you also add copilot-requests: write, a special permission that lets the workflow bill Copilot use to the organization's plan through the built-in Actions token. It does not let the agent change anything. A personal repository has no organization plan, so you store a token (a password-like key) as a repository secret named COPILOT_GITHUB_TOKEN instead.

Folder structure

.github/
  workflows/
    weekly-status.md          (you write and edit this)
    weekly-status.lock.yml    (generated by gh aw compile)

gh aw is an extension to the GitHub CLI (command-line interface). gh aw compile turns the Markdown file into the .lock.yml file, the GitHub Actions workflow that actually runs. Its header says "DO NOT EDIT", and you commit both files.

The body is loaded when the workflow runs, so a change to the instructions applies on the next run without recompiling. Any change between the --- lines needs gh aw compile again, then both files are committed.

What happens when it runs

On Monday, GitHub Actions starts the compiled workflow as a chain of separate jobs:

1. Activation prepares the context and checks that the lock file is current.
2. Agent runs Copilot in an isolated container behind a firewall. It reads activity with a read-only token and writes its draft issue as a request. It cannot create the issue.
3. Detection runs a separate AI check on the proposed output. If it finds something unsafe, the safe outputs are not applied as written: depending on the threat-detection settings, they are blocked or flagged for human review.
4. Safe outputs is the only job allowed to write issues. It creates the issue with the prefix and label, then closes last week's report.
5. Conclusion writes the run summary.

By default the agent step stops after 20 minutes, and one run may spend at most 1,000 AI credits (US$10). gh aw logs shows token use and estimated cost. To test without writing anything, add staged: true under safe-outputs; the run summary then shows a preview.

How agentic workflows differ from Copilot automations

Copilot automations also run an agent on a schedule or event, so both appear in this skill area.

GitHub's automations page points to agentic workflows when you want an automation stored as code, reviewed through pull requests or run by a different agent.

Rules that decide exam answers

1. Reading goes in permissions and tools; writing goes in safe-outputs. Prefer a safe output to giving the agent write permission.
2. Judgement and decision criteria go in the Markdown body. Builds, tests and deployments stay in standard Actions workflows.
3. Body-only change: applies on the next run. Frontmatter change: run gh aw compile and commit both files.
4. Edit the .md file, never the .lock.yml file.
5. Must be in Git, reviewed by pull request, or run on a non-Copilot engine: choose an agentic workflow.

Two sample questions

These are original Timo practice questions, not official exam questions.

Question 1

A weekly status workflow posts a new report issue every Monday. After a month, four reports are open and readers are unsure which is current. The team wants each new report to close the earlier ones, but only once the new report exists. Which frontmatter change does this?

A. Under create-issue, set max: 1 so that only one report issue can be open at a time.B. Under create-issue, set close-older-issues: true so each new report closes the earlier ones.C. Under permissions, set issues: write and tell the agent to close last week's report itself.D. Under safe-outputs, add close-issue with target: "triggering" to close the earlier report.

Answer: B. close-older-issues closes earlier open issues from the same workflow as "not planned", and only after the new issue is created. A fails because max limits how many issues one run may create (the default is already 1) and ignores earlier issues. C gives the agent write access, which the read-only design keeps from it, and leaves closing to the agent's judgement. D fails because "triggering" means the issue that started the run, and a scheduled run has none.

Question 2

A product team wants a weekly summary that runs without anyone starting it. The head of engineering asks that the setup be stored in the repository, changed only through reviewed pull requests, and visible to every maintainer. What should the team build?

A. A Copilot automation created in the repository's Agents tab with a weekly schedule triggerB. An agentic workflow Markdown file in .github/workflows, merged through a pull requestC. A Copilot cloud agent session that a maintainer starts by hand from the Agents tab each MondayD. A custom agent file in .github/agents that sets a weekly schedule in its frontmatter

Answer: B. An agentic workflow is a file in the repository, so every change is a reviewable commit that anyone who can read the repository can see. A fails because automations are stored outside the repository, are not committed to Git, and are private to their creator. C is not automatic and stores no setup. D fails because a custom agent's frontmatter sets things such as its description, tools and model, but has no trigger or schedule.

Build exercise

Use a free test repository where you have write access and GitHub Actions is enabled.

1. Create five issues. Label one blocked, close one, and create a label called status-report.
2. Install the GitHub CLI first. Then run gh extension install github/gh-aw, then gh aw add-wizard githubnext/agentics/daily-repo-status. The wizard stores the key the agent needs (the engine secret) and opens a pull request adding a .md and a .lock.yml file. Merge it and read both files.
3. Create .github/workflows/weekly-status.md from the example, adding staged: true as the first line under safe-outputs:. Run gh aw compile, then commit and push both files.
4. Run gh aw run weekly-status. The run summary should show a preview of the issue, and no issue should be created.
5. Remove staged: true, compile, commit and run again. An issue titled "[weekly status] Week of ..." should appear. Run once more: a second report appears and the first is closed.
6. Add a "Risks" section to the body only, commit without compiling and run again. The new section should appear. Run gh aw logs to see token use and cost.

Practise this topic

The free GH-700 practice test has 20 questions across all four skill areas. The GH-700 practice tests add 200 questions, including four timed 50-question mocks, for US$15. The GH-700 prep material has one module per skill area with guided labs, also US$15, or US$25 for both, at GH-700 practice tests and prep material. The GH-700 exam guide covers the exam format and all four skill areas.

Now you can get Claude Certified and earn OpenAI badges and certifications too

• Register for all four Claude certification exams through Amotion AI, which is Certified in the Claude Partner Network. Claude Certified Associate covers business and knowledge work, not coding.
• Take 11 OpenAI PartnerU learning programs with assessments and course-completion certificates, and work towards the expert badges for ChatGPT, Codex and APIs.
• Practise with 20 full-length Claude mock exams.

Join Timo for Claude and OpenAI certifications

Sources

• Microsoft Learn: Study guide for Exam GH-700
• GitHub Docs: GitHub Agentic Workflows
• GitHub Docs: Creating GitHub Agentic Workflows
• GitHub Docs: Your first agentic workflow
• GitHub Docs: Copilot automations
• GitHub Docs: Custom agents configuration
• GitHub Changelog: GitHub Agentic Workflows is now in public preview
• gh-aw: How agentic workflows work
• gh-aw: Workflow structure
• gh-aw: Frontmatter
• gh-aw: Markdown
• gh-aw: Schedule syntax
• gh-aw: Triggers
• gh-aw: Permissions
• gh-aw: Safe outputs
• gh-aw: Staged mode
• gh-aw: Security architecture
• gh-aw: Working with workflows

Independent Timo practice material. Not affiliated with or endorsed by GitHub or Microsoft.