CertifyDeck
All cheat sheets
GH-700 · CHEAT SHEET

GitHub Certified: Agentic AI Business Professional

Key concepts grouped by official exam weight.

Download as PDF (free, no sign-up)

1. Use GitHub platform features

20–25%

Apply GitHub management best practices and policies

  • User-level budgets cap each person and always enforce a hard stop; cost center, organization and enterprise budgets limit metered charges and only block when the stop-usage setting is enabled. They work together: whichever has the least headroom blocks first, and a higher budget never extends a user-level budget.
  • Each interaction consumes input, output and cached tokens, priced according to the model. To reduce them, match the model to the task, write clear prompts with a stopping condition, keep context lean with new conversations or /compact, enable only the tools you need, and avoid changing model or reasoning mid-session.
  • Organization custom instructions share language, security or compliance guidance with all members, but they do not guarantee compliance. To enforce standards, use rulesets and CODEOWNERS, which also bind Copilot, and organization-level custom agent profiles for consistent configuration.
  • Secret scanning detects exposed credentials, and the priority after an alert is to rotate them; push protection blocks them before they reach the repository. Copilot cloud agent only receives Agents secrets, not Actions secrets, and those with the COPILOT_MCP_ prefix are reserved for MCP servers.
  • Copilot policies control features and models; when a user has licenses from several organizations, the least restrictive usually applies. Content exclusion makes Copilot ignore files, and Copilot cloud agent offers traceability: co-authored commits, session logs and mandatory human review before merging.

Plan and manage work

  • A project can start blank, from a built-in GitHub template or from an organization template, and recommended templates are suggested first. A template or a copy carries over views, custom fields, draft issues, configured workflows except auto-add ones, and insights, but a copy does not keep the original items, collaborators or team and repository links.
  • Each project view can use a table, board or roadmap layout, with its own filters, grouping and sorting. On a board, columns come from a single select or iteration field, and column limits only warn. Built-in workflows update status and add or archive items, while custom date, number, text, single select and iteration fields enrich the data.
  • In an organization project, the base role sets general access and can be complemented by read, write or admin roles for teams and individuals. The base role does not affect owners or people with individual access. Public or private visibility applies only to the project itself: viewing an item from a private repository requires access to that repository.
  • Issues track tasks, bugs and ideas, and can be created from a repository, a comment or a line of code. Sub-issues build hierarchies, dependencies mark blockers and labels classify work inside each repository: the triage role can apply labels and assign issues, but creating or editing labels requires write access.
  • GitHub offers several collaboration channels: issues for tasks and bugs with a clear owner, pull requests for proposing and commenting on changes, and GitHub Discussions for open conversations, announcements and polls. Mentions alert people and teams, and Copilot helps summarize long threads in issues and discussions.

Track and capture work

  • A pull request proposes merging a compare branch into a base branch and brings together conversation, checks and changed files. A draft shares work in progress that cannot be merged and does not request code owner reviews. Without write access you start from a fork, and templates and Copilot summaries help give reviewers context.
  • Assignees show who is working on a pull request, which differs from reviewers, who are asked for feedback. You can assign people with write permissions, anyone who has commented and organization members with read access, one at a time or in bulk. Teams can distribute reviews automatically with round robin or load balance routing.
  • Linking a pull request to an issue shows that work is in progress and closes the issue on merge into the default branch. You link with keywords in the description, which are ignored for any other target branch, or manually with write permissions from the sidebar; only the issue sidebar accepts a pull request from another repository.
  • A project is fed by issues and pull requests added individually, in bulk or through the auto-add workflow, which does not include existing items. Draft issues exist only in the project until converted to issues. Linking a project to a repository lists it there, provided that both have the same owner.
  • A repository wiki hosts long-form documentation, while the README summarizes the project. You edit it on GitHub or locally, because it is a Git repository: every change is a commit you can compare and revert. It follows the visibility of the repository, and by default only people with write access can edit it. If search engines must index the content, use GitHub Pages.

2. Enhance productivity by using GitHub Copilot

20–25%

Chat with GitHub Copilot

  • Copilot models have different strengths: fast models suit simple, repetitive questions, deep reasoning models suit weighing trade-offs and analysing logs, and multimodal models suit diagrams and screenshots. Choose by task rather than by name. Copilot Fusion or Auto hand that decision to Copilot, and your organization can limit which models are available to you.
  • In GitHub Copilot CLI, /new starts a session, /resume switches to another with its full history, /rename names it, and /exit closes it without deleting it. Archiving moves a session out of the active list without removing it; Copilot cloud agent sessions on GitHub Actions can be archived but not deleted. In VS Code you can pin a session at the top of the list.
  • Choose the agent by the job: in the IDE, the agents dropdown switches between Ask, Plan and Agent; built-in agents cover common work such as code review or a second opinion; and a custom agent defines a reusable role with its own instructions and tools. On GitHub you select one when assigning an issue or in the agents panel, and in GitHub Copilot CLI with /agent.
  • In Copilot Chat on GitHub, typing @ opens a list of items you can attach, such as files, issues, pull requests and repositories. In GitHub Copilot CLI, @ adds the contents of a file and # includes an issue or pull request. In Visual Studio Code, @ invokes chat participants. To query external services during a task, you use Copilot connectors or MCP servers.
  • Slash commands save you from writing long prompts, and those available vary by environment. In the IDE, /explain explains code, /fix proposes fixes, /tests generates tests and /doc adds documentation. On GitHub, /clear and /delete manage conversations. /chronicle uses your session history for standup reports, tips, searches and improvements to custom instructions.

Write instructions and prompts that produce reliable outputs

  • Ask explicitly for what the response must contain: a sentiment classification of feedback, a cohesive summary with trends and insights, the target audience or the tone. Put your most important requirements first and state them directly. Lasting preferences belong in custom instructions, although Copilot may not apply them the same way every time, so always review the output.
  • State precisely which data Copilot must act on: open the issue so that it loads as context, include its URL or paste the content into chat. Avoid ambiguous references such as 'this'. Prompt files are reusable templates that can define input variables, so the same task can run with different data each time. Check summaries of very long threads carefully, as quality can drop.
  • To control the shape of a response, state the format directly, put the most important requirements first and add an example of the expected output. Lasting preferences can go in custom instructions, but these guide the model without guaranteeing compliance, and always demanding a certain level of detail can cause problems in large repositories.
  • In GitHub Copilot CLI, /undo or /rewind opens a picker to return to the state before a prompt, either in the conversation only or also in the files Copilot changed, without overwriting your later edits. The action cannot be undone. Visual Studio Code checkpoints restore files and chat history, but they do not reverse commands or changes to external services.

Create and manage custom agents

  • A custom agent profile grants web access through the web alias in its tools list and defines how to use that information in the Markdown content below the frontmatter. The reference states that this alias does not apply to Copilot in the cloud. A one-off cited report does not require a new agent, because the /research command in GitHub Copilot CLI is enough.
  • An agent profile is saved as a file: in .github/agents for a repository, in ~/.copilot/agents for personal use in the CLI, or in /agents of the .github or .github-private repository for the whole organization. On GitHub it appears after merging into the default branch. From a project, you can assign an issue to Copilot and choose that agent.
  • An agent's guardrails combine a restricted tools list, properties such as disable-model-invocation, and hooks such as preToolUse, which run code and can deny a tool, whereas instructions only guide the model. Copilot cloud agent adds the firewall, a single branch for pushes, and human review before merging.
  • The pull request description states which custom agent did the work, and each commit links to session logs that show the reasoning and the tools used. To monitor usage across the organization, filter the audit log by actor:Copilot, although local prompts do not appear there. With /chronicle you can review your own Copilot CLI sessions.

3. Design and implement agentic workflows and automations

25–30%

Design agentic workflows and automations

  • Agentic workflows suit repetitive tasks that require interpretation or investigation, such as triaging issues, reviewing CI failures or generating reports, and they deliver reviewable outputs. Reproducible steps, such as builds or deployments, remain better in GitHub Actions. Copilot automations are configured with triggers and are not committed to Git.
  • Split a use case by the nature of each task: deterministic steps collect data and the agent interprets it. Use sub-issues when each piece needs its own discussion and assignee, and an orchestrator with workers when permissions change or several repositories are involved. Each phase should leave a concrete artifact and a human checkpoint.
  • Judgment calls belong in the instructions, with definitions, examples and conditional logic; objective conditions go in the frontmatter (if:, names:, skip-if-match:, on.roles:, stop-after:) and are evaluated before the agent runs. Auto-apply low-risk changes and keep priorities and dates as suggestions for people to decide.
  • Choose the pattern by what starts the work and how it flows: IssueOps for new issues, LabelOps for labels, ChatOps for commands, DispatchOps for manual runs, MonitorOps for watching other workflows, BatchOps for large independent volumes, WorkQueueOps for backlogs, and ResearchPlanAssignOps when scope is unclear until analysis runs.

Implement agentic workflows

  • An agentic workflow is a Markdown file with YAML frontmatter for configuration and a body of instructions. Create it with Copilot on the web, with a coding agent or by hand; gh aw compile generates the .lock.yml file. To reuse one, adapt it with a coding agent or use gh aw add, pinning a version when updates must be controlled.
  • The frontmatter sets when the workflow runs (fuzzy schedules, cron or events), what the agent can read (read-only permissions by default) and what it can ask to write (safe outputs with limits such as allowed and max). Separate jobs carry out those outputs, and staged: true lets you preview them without writing anything.
  • The .md source and its compiled .lock.yml file live together in .github/workflows and are both committed; use kebab-case names. Shared components usually go in .github/workflows/shared, agent files in .github/agents and skills in .github/skills. The agent's temporary files belong under /tmp/gh-aw/agent/ so that they are preserved as artifacts.
  • Write instructions as if explaining the task to someone new: specific, with context, criteria, output templates and failure handling, plus a call to noop when there is nothing to do. Avoid over-complexity and assumed knowledge. The Markdown body is loaded at runtime, so editing it does not require recompilation of the workflow.
  • Self-critique rests on several documented pieces: the rubber duck agent reviews plans with another model and edits nothing; evals ask yes or no questions about the output; and outcome evaluation checks the real state of the repository. Reliable loops cap retries, accept only on evidence and keep durable state for the next run.

Implement automations

  • An automation runs on a schedule, when an issue is created, when a pull request is opened or synchronized, or through the API with additional context. Filters narrow when it fires and, by default, events from users without write access are ignored to reduce the risk of prompt injection. You can test it by simulating a trigger.
  • The prompt describes the task Copilot performs on each run and is visible in sessions to anyone with read access, so sensitive values go in repository secrets. The model and reasoning level are optional: auto selection matches the model to the task, and higher reasoning helps with complex work at the cost of more time and usage.
  • Tools determine what Copilot can do in an automation and are the main way to limit its scope: grant only those needed. GitHub tools act in a single repository; tools from MCP servers, which an administrator configures, reach whatever their credentials allow. Review that access before you select them, and let Copilot suggest a list if you are unsure.

Integrate skills and MCP servers

  • External skills are installed with gh skill install or by moving a downloaded directory to a project or personal location. GitHub does not verify them, so inspect them with gh skill preview and lock versions with --pin. In GitHub Agentic Workflows, declare them in the skills frontmatter field, pinned, rather than installing them on the fly.
  • A custom skill is its own subdirectory with a SKILL.md file, whose frontmatter requires name and description, and a Markdown body of instructions. It can include templates and scripts. Use it for repeatable workflows needed only sometimes, and leave shell out of allowed-tools unless you have reviewed all of its content and trust the source.
  • Copilot decides when to use a skill from the prompt and its description, then injects SKILL.md into the agent's context. In Copilot CLI, you request a specific skill with a slash and its name, and /skills reload picks up those added during a session. The GitHub Copilot app also offers built-in skills, such as /orchestrate, some of which run automatically.
  • An MCP server gives an agent access to external tools and data, and it complements instructions rather than replacing them. In GitHub Agentic Workflows it is connected in the mcp-servers section, with allowed limiting the tools; writes go through safe outputs. In Copilot cloud agent, repository configuration is shared and should allow only read tools, because the agent uses them without asking for approval.

4. Perform human-in-the-loop tasks for agentic workflows

20–25%

Design human review and validation practices

  • Even when an agent works autonomously, some decisions stay human: reviewing changes and tests before committing, marking a pull request ready, approving and merging it, and allowing workflows to run. Sensitive, critical, ambiguous or very complex tasks are best kept with a person. Whoever requested the work cannot supply the required approval, and manual-approval holds an agentic workflow before it runs.
  • Interactive mode suits exploring a problem or making frequent decisions; Plan mode, reviewing the approach before implementation; and Autopilot mode, well-defined tasks the agent can carry through several steps without waiting. Autopilot controls continuation, not permissions: if an action is not permitted, the agent may not finish. You remain responsible for reviewing the result.
  • How an agent escalates depends on the tool and the permission mode: manual approval, assisted permissions or unconditional approval. Deny rules always win, even with allow-all, and a preToolUse hook can approve or deny each use. In agentic workflows, the protected-files policy decides whether sensitive changes go to a review or to an issue for a person.

Interact with agentic workflows

  • When Copilot CLI asks for permission you can approve once, for the session or persistently, or reject and guide the agent with feedback. On a Copilot cloud agent pull request, revisions are requested by mentioning @copilot, and it is best to batch them in a review so it works on all of them at once. It responds only to people with write access and only on open pull requests.
  • While an agent works you can steer it without stopping it: in Copilot cloud agent, with a follow-up prompt below the session log, and in Copilot CLI, with a plain prompt or by queuing one for the next turn. Sessions in a cloud sandbox can be followed from other clients. Stopping a session ends the run and preserves commits already pushed.
  • When something fails, start from existing evidence: session logs in Copilot cloud agent, or the run URL, which an agent can analyze, in GitHub Agentic Workflows. A stuck session is retried by reassigning the issue. Agent Merge watches a pull request and fixes failed workflows or conflicts, and missing MCP tools usually come from the configured toolsets or the allowed list.
  • Stopping a Copilot cloud agent session ends the GitHub Actions run and keeps commits already pushed; stopping does not undo finished work. For an agentic workflow, cancelling a run does not prevent new triggers, whereas gh aw disable disables the workflow and also cancels anything in progress. In Copilot CLI, Ctrl+C cancels the operation and clears the queued prompts.

Supervise and monitor agentic workflows

  • An agentic workflow gains autonomy in stages: report-only, staged mode (a preview of what it would do), shadow evaluation (real writes tested outside production) and direct writes. Requirements are enforced in the frontmatter through safe-outputs, allowed lists, manual-approval and limits, not through instructions. With cloud agent, the acceptance criteria in the issue guide the result.
  • Copilot pull requests deserve the same review as any other: your approval does not count when the repository requires approvals, and you should inspect changes before letting workflows run. Each commit links to the session logs for auditing why a change was made. In agentic workflows, threat detection annotates reviewable outputs, and outcomes are measured from the actual repository state.
  • Cloud agent sessions are followed from the agents panel, with the log, progress, token usage and session length. For agentic workflows, gh aw health gives success rates, gh aw logs analyzes many runs and their results with --outcomes, and gh aw audit breaks down or compares specific runs. The MonitorOps pattern schedules a workflow that summarizes activity and escalates repeated failures into issues.