Study Guide

Copilot Business and Copilot Enterprise licenses each come with a monthly amount of AI credits, and those credits are pooled across the billing entity rather than kept per person. Budgets decide how people draw from that pool and how much paid usage is allowed once it's gone. A user-level budget caps one person's total use across both the pool and the paid (metered) phase, and it's always a hard stop. There are three kinds, from broadest to most specific: a universal budget for every licensed user, a cost center user-level budget for everyone in a cost center, and an individual budget for one person. The most specific one applies.

Cost center, organization, and enterprise budgets are different: they only cap metered charges after the pool is exhausted, and they don't limit how much a team draws from the pool. They stop usage only if "Stop usage when budget limit is reached" is turned on, and that setting is off by default. An enterprise budget therefore isn't a monthly total; the maximum bill is the license fees plus the budget.

The controls interact. Whichever budget has the least headroom left blocks the user first, so a generous personal budget doesn't help if the enterprise budget is nearly spent, and raising a team budget doesn't unblock someone who hit their personal cap. Paid usage beyond the pool also requires the AI credit paid usage policy, which is enabled by default.

Every Copilot interaction uses tokens: input tokens sent to the model, output tokens it generates, and cached tokens it reuses. Each token is priced by the model, and the total converts into AI credits, where one credit is one cent. So the cost of a request depends on two things: which model handles it and how many tokens it processes. A short chat on a light model costs a fraction of a credit; a long cloud agent session on a frontier model costs much more. Copilot Chat, Copilot CLI, the cloud agent, and Spaces are billed in credits, while code completions are not.

Usage shows on your Copilot settings page ("Usage this cycle"), and against your user-level budget if one applies. Individuals see a breakdown by model on the AI usage page.

GitHub's guidance for using fewer credits: pick the model the task needs; write prompts with a clear task, the relevant context, and a stopping condition; keep context lean by starting a new conversation for a new problem or compacting a long Copilot CLI session with /compact; enable only the tools you need; and don't switch models, reasoning level, or tools mid-session, because that invalidates the cache and the whole context is billed again. Copilot CLI can also set an AI credit session limit that stops a single task cleanly.

GitHub's rollout guidance starts from one rule: nobody, human or agent, should be able to put unreviewed AI work straight into an important codebase. A branch ruleset enforces that by requiring an approved pull request before merging and blocking force pushes. CODEOWNERS files add automatic review requests for sensitive files, and rulesets can require reviews from code owners and passing workflows before merge.

Security configurations add code scanning, secret scanning, and push protection across organizations. Custom instructions then steer Copilot toward the standards in the first place: organization instructions set a baseline (they apply only on the GitHub website), and repository instructions add project detail and apply in more places.

The guidance also covers people: communicate the expectations (for example, that all agent work gets a thorough review), train users, name champions, and plan how to revert a bad change and check audit logs for ruleset bypasses.

A secret such as an API key or token committed to a repository can be found and misused. Secret scanning searches a repository's whole Git history on all branches, plus issues, pull requests, discussions, and wikis, and raises an alert when it finds a credential. The first response to an alert is to rotate or revoke the credential; scrubbing it from history is slow and often unnecessary once it no longer works.

Push protection works earlier: it blocks a push, web commit, upload, or API request that contains a secret, before it reaches the repository. Repository push protection needs GitHub Secret Protection and is off by default; push protection for users is on by default and covers pushes to public repositories. People with write access can bypass a block with a reason, which creates an alert and an audit log entry.

Automations need credentials too. GitHub Actions secrets are encrypted and can be stored at the organization, repository, or environment level; a workflow reads one only if it names it, and environment secrets can require an approver before a job can use them. Grant the least permission needed, and prefer a GitHub App, whose short-lived tokens aren't tied to a person who might leave. Logs redact secrets, but redaction isn't guaranteed.

Copilot policies live on an enterprise's AI controls tab or in organization settings. They control which features, agents, and models users can use, such as Copilot CLI, the Copilot app, or MCP servers. An enterprise can enable or disable a policy or let organizations decide. When a user gets Copilot from two organizations in the same enterprise with different settings, the least restrictive one usually applies; across different enterprises, the most restrictive almost always applies. The Copilot app and Copilot CLI have separate policies, so one can be allowed without the other.

For privacy, content exclusion tells Copilot to ignore chosen files: they get no inline suggestions, don't inform suggestions or responses, and aren't reviewed by Copilot code review. Repository admins, organization owners, and enterprise owners can configure it.

GitHub also recommends watching for policy drift by limiting who can change policies and using the audit log to track changes. Its governance guidance warns against being too restrictive: if useful features stay disabled, people may turn to tools outside the company's controls, so restrict features only where there's a compliance reason and scope restrictions to sensitive organizations.

The six principles are fairness (treat people fairly), reliability and safety (behave consistently and safely, including in unexpected conditions), privacy and security, inclusiveness (empower everyone), transparency (AI systems should be understandable), and accountability (people remain accountable for AI systems).

GitHub turns these into practical guidance for Copilot users. Output may be inaccurate, incomplete, biased, or irrelevant, so a human should review and validate it before relying on it. Take particular care with consequential decisions, such as those affecting someone's employment, finances, or health, and with agentic AI in sensitive domains where actions can't be undone.

GitHub names overreliance as a risk: accepting wrong or incomplete output because the mistakes are hard to see. The remedy is to treat Copilot as a tool rather than a replacement and keep review in the process.

A branch is a safe place to change work without affecting the default branch; changes reach the default branch only when a pull request merges them. That pattern, called the GitHub flow, is what review and automation hang on.

Policies protect important branches. A branch protection rule or a ruleset can require pull requests with approvals, passing status checks, or signed commits, and can block force pushes. Rulesets are more flexible: several can apply to the same branch, their enforcement can be switched off without deleting them, anyone with read access can see them, and organizations can target many repositories. Push rulesets can also block pushes by file path, extension, or size across a repository's fork network.

For agent work, GitHub recommends at least "Require a pull request before merging" with one approval and "Block force pushes" on production branches.

Copilot offers many models, and they have different strengths: some respond with low latency, others reason through complex problems, handle large context, or hallucinate less. The same prompt can therefore produce answers of different depth, speed, and accuracy depending on the model. Which models you can pick depends on your plan, the surface (IDE, GitHub.com, Copilot CLI, the Copilot app), and administrator policies, and models are added and retired over time.

With bring your own key (BYOK), an organization can connect its own provider's model; GitHub notes that quality and safety then depend on that provider, and the customer is responsible for validating the output.

For explaining an answer, Copilot Chat on GitHub.com may include links to the files, issues, or documentation it used as context, which lets a reader check the sources. Explanations Copilot writes can still be inaccurate or incomplete, so they need the same human review as any other output.

GitHub's guidance is to use as much model capability as the task needs and no more. Reasoning models suit architecture decisions, complex debugging, and system design. Mid-tier models suit execution once the plan is clear. Lighter models suit refactoring, formatting, documentation updates, and other routine, well-scoped changes. Overusing reasoning models raises token use and can even lower quality on simple work.

Some models also let you set a reasoning level. Higher levels can help on hard problems but use more tokens, so start at the regular level. A common pattern is to plan with a strong reasoning model and implement with a cheaper one; subagents can run on lighter models too.

Auto model selection routes each request to a suitable model based on task complexity and real-time availability, reserving expensive models for complex problems. It switches models at cache boundaries, routes around busy models, and gives paid plans a discount. GitHub's model comparison page lists recommended models by task area, and the list changes as models come and go.

Custom instructions are always-on context: Copilot applies them automatically to every request in their scope. Repository-wide instructions go in .github/copilot-instructions.md, path-specific ones in .github/instructions/*.instructions.md with an applyTo pattern, and AGENTS.md serves agents; organizations and individuals can also set instructions on GitHub. They suit standards that apply broadly, such as a writing style or review checklist.

Prompt files (.prompt.md, usually in .github/prompts/) are reusable templates for one focused task, with input variables. You run them on purpose from chat, so they suit a task you repeat with different inputs. They're supported in IDEs such as VS Code and Visual Studio, not on GitHub.com or in Copilot CLI.

Agent skills are folders with a SKILL.md, plus any scripts and resources, that Copilot loads automatically when they're relevant to the prompt. They suit multi-step workflows with bundled assets, such as release-note drafting or deployment procedures. Project skills live in the repository (for example .github/skills), personal skills in your home directory, and the format is an open standard shared by other AI tools.

The Model Context Protocol (MCP) is an open standard for connecting AI models to data sources and tools. With an MCP server, Copilot can call into another system, for example to read tickets, query a database, or drive a browser, instead of relying only on what's in the conversation and repository.

MCP works across Copilot surfaces: IDEs, Copilot CLI (which has the GitHub MCP server built in), the Copilot app, and the cloud agent and code review on GitHub.com, where repository-level MCP configuration applies and the GitHub and Playwright MCP servers are set up by default. The GitHub MCP Registry lists partner and community servers.

Organizations control it with the MCP servers in Copilot policy, which is off by default. Each server's tools also add to the context on every request, so enable only the tools a task needs.

A GitHub project is a table, board, and roadmap that stays in sync with your issues and pull requests. Organization projects can track work from the organization's repositories; user projects track your own repositories. To create one, open Projects for the organization or your profile and choose New project.

You can start from scratch with a Table, Board, or Roadmap, or from a template. Templates come from GitHub's built-in set, from your organization, or from the list your organization recommends. A template carries its views, custom fields, draft issues, workflows (except auto-add), and insights, so teams start the same way. You can also copy an existing project or import every item from a repository when you create it.

After creating the project, set its name, short description, and README so people know what it tracks.

Each saved view can use its own layout. A table is a spreadsheet you can group, sort, and filter. A board spreads items across columns taken from a single select or iteration field, usually Status, and dragging a card changes that field. A roadmap places items on a timeline using date and iteration fields.

Custom fields add metadata beyond assignees, labels, and milestones: text, number, date, single select (for example Priority with Urgent, High, Medium, Low), and iteration for planning work in fixed periods. A project can have up to 50 fields.

Built-in workflows automate the project: they set Status when items are added, closed, or merged, archive items that meet criteria, and auto-add items from a repository that match a filter. Two are on by default, setting Done when items close and when pull requests merge. The GraphQL API and GitHub Actions offer more control.

Admins of an organization project can manage access for the whole organization, teams, individual members, and outside collaborators. The base role applies to organization members who aren't owners and don't have individual access: No access, Read, Write, or Admin. Organization owners are always project admins.

Invited collaborators get Read (view), Write (view and edit), or Admin (also add collaborators). You can invite teams, organization members, and outside collaborators who already collaborate on at least one organization repository. Giving a team Read or more also lists the project on the team's page.

Visibility is separate from access: a public project can be seen by anyone on the internet, while a private one is visible only to people with at least Read.

Issues track ideas, feedback, tasks, and bugs. You can create one from a repository's Issues tab, from a comment, from a line of code, or with a URL query; issue templates and forms collect the information maintainers need.

Assign up to 10 people to show who's working on it. You can also assign an issue to Copilot, which works on it on its own, opens a pull request, and asks you to review it.

To link work, mention an issue with # to create a reference, add sub-issues to break large work into a hierarchy, or set issue dependencies to show what blocks what; a closing keyword in a pull request closes the issue on merge. To tag, apply labels (anyone with triage access can apply them; GitHub provides defaults such as bug and enhancement), issue types, and milestones.

Collaboration on GitHub happens around the work itself. Issues hold tasks and bugs, and @mentioning someone draws them into a conversation; typing # links related issues. Projects give the team a shared plan built from those issues and pull requests.

GitHub Discussions suits conversations that aren't tasks: questions, announcements, and open-ended ideas. An issue that turns into a discussion can be converted.

Pull requests are where changes are reviewed: reviewers comment, suggest changes, and approve before a merge, which keeps a record of who decided what.

A pull request asks for the commits on one branch to be merged into another. When you create one, you choose the base branch (where the changes go, often main) and the compare branch (where you made them), then write a title and description. Pull requests open only between two different branches; without write access, you fork the repository first.

You can open a pull request ready for review or as a draft. A draft can't be merged, and code owners aren't asked to review it automatically, which suits work in progress. Other statuses are open, closed without merging, and merged.

GitHub CLI can create one with gh pr create.

Like issues, pull requests take up to 10 assignees, which show who's responsible for moving the change forward. You can assign yourself, people who commented, people with write permission, and organization members with read permission.

Reviewers are different: they're asked to look at the changes and approve or request changes. Requesting a review needs write access, and you can ask a person or a team with read access. Suggested reviewers come from who last changed the affected lines. After you make changes, you can re-request a review.

You can also request a review from Copilot, which leaves feedback and suggested changes. Requesting a large team can notify everyone, so auto assignment or notifying only requested members reduces noise.

Linking a pull request to the issue it addresses shows others that work is under way, and closes the issue automatically when the pull request merges into the default branch.

The usual way is a closing keyword in the description: close, closes, closed, fix, fixes, fixed, resolve, resolves, or resolved, followed by #number (or owner/repo#number for another repository). Keywords are ignored when the pull request targets any branch other than the default. A keyword in a commit message also closes the issue on merge, but the pull request isn't listed as linked.

You can also link manually from the pull request sidebar if you have write permission, up to ten issues in the same repository. To remove a keyword link, edit the description.

A project is built from the issues and pull requests you add. You can paste an item's URL into the bottom row, type # to search a repository, bulk add from a repository with filters such as label:bug, add from a repository's issue list, or let a built-in workflow add matching items automatically. Draft issues capture ideas and can later become real issues.

Items stay in sync in both directions: change an issue's labels or assignee and the project updates; change a field in the project and the issue reflects it. Adding or removing an item, and changing its Status, adds an event to the item's timeline.

A project can hold up to 50,000 items across its views and archive.

Every repository comes with a wiki for long-form content such as how to use the project, how it was designed, or its principles; a README gives the quick overview. A public repository's wiki is public, and a private repository's wiki is visible only to people with access. By default only people with write access can edit, though a public repository can allow everyone to contribute.

To add a page, open the Wiki tab, choose New Page, write the content (Markdown by default, or another format), add an edit message, and Save Page. Editing works the same way from the page's Edit button.

Wikis are Git repositories, so you can clone one, edit files locally, and push. Only changes pushed to the default branch are published. The file name becomes the page title and the extension sets how it renders. For content that search engines must index, GitHub suggests GitHub Pages.

On GitHub.com, in IDEs, in Copilot CLI, and in the GitHub Copilot app you can change the model Copilot uses. Different models can give better or more useful answers depending on the question, and some are premium models with advanced capabilities. The models you see depend on your plan and the policies your organization sets.

In the Copilot app you also choose a reasoning effort. Higher effort gives the agent more time on complex problems but can take longer, and both settings can change mid-session. With Auto selected, the app shows which model handled each response.

For business work, GitHub's guidance is to match capability to the task and split big work into phases: research, plan with a strong reasoning model, then implement with a cheaper one, each in its own session so context stays small.

In the GitHub Copilot app, a session runs in its own isolated workspace on its own branch, so several can run in parallel. You start one by choosing a project, where it runs (a new working tree, your local repository, or a cloud sandbox), the mode and model, and then the task. Chats open a conversation without creating a branch, which suits brainstorming.

In Copilot CLI, sessions are saved and, by default, synced to your GitHub account. copilot --continue resumes the latest session and copilot --resume or /resume lets you pick one; resuming reloads the full history. /rename NEW_NAME gives a session a name you'll recognize in that list, and the app has /rename too.

Archiving keeps a session's history but removes it from your list; the app's Manage sessions view can archive, delete, or restore archived chats. Copilot cloud agent sessions can be archived after they stop but never deleted; only local sessions can be deleted. The bullet also names pinning, which none of the GitHub Docs or Learn pages used for this deck describe, so no card covers it.

A custom agent is a specialist persona with its own instructions, tool limits, and context. You select one from the agent dropdown in your IDE, on GitHub.com, or in Copilot CLI; in the Copilot app, /agent selects one for the session. Pick one when work has distinct stages or needs strict limits, such as a read-only auditing agent.

Some agents are built in. In the Copilot app, the rubber duck agent reviews your plan, implementation, or tests as a constructive critic, running on a different model from your session. When it is enabled, Copilot can consult it automatically at key points; otherwise you call it with /rubber-duck.

On GitHub.com, typing @ in Copilot Chat lists items you can attach: discussions, extensions, files, issues, pull requests, and repositories. Chat there also has built-in tools for tasks such as creating branches and creating or updating issues.

In VS Code, @ calls a chat participant, a helper with a specialty: @github for GitHub skills, @terminal for the terminal, @vscode for the editor. # adds a chat variable such as #file or #selection to include context.

In Copilot CLI, @path attaches a repository file and #number references an issue or pull request. The Copilot app follows the same pattern, with / for commands. Attaching the exact item beats describing it, because vague references lead to wrong answers.

In IDE chat, /explain explains the code in the active editor, /fix proposes a fix for problems in the selected code, and /tests generates unit tests. Visual Studio adds /doc for a documentation comment. These save writing a long prompt for routine requests.

On GitHub.com, conversation commands manage the chat itself: /clear clears the conversation, /delete deletes it, /new starts a new one, and /rename renames it.

/chronicle belongs to Copilot CLI (and the Copilot app, which is built on it). It reviews your session history: standup summarizes recent work, tips gives personalized tips, search finds past sessions, and improve suggests changes to your instructions file. Available commands vary by environment and context.

A bare request leaves the model to guess. Detailed instructions that list the points and tone you want, such as an enthusiastic greeting, thanks to the team, and a positive outlook, produce output much closer to what you need. That's how you set the sentiment of a response.

For a coherent, on-target answer, GitHub recommends starting with the broad goal and then listing specific requirements, most important first, because Copilot gives extra weight to the start and end of a prompt. Avoid ambiguous words like "this", break large tasks into smaller steps, and state rules directly ("Return the result as JSON"). Learn's GitHub Copilot module sums it up as the 4 Ss: single, specific, short, surround.

Creativity is partly a model setting. Where temperature is exposed, a higher value gives more varied, divergent output that suits creative writing, and a lower value gives focused, concrete output that suits something like a legal document. Adjust temperature or top_p, not both.

A prompt has parts. Primary content is what the model acts on, such as a report to summarize or a table to query. Supporting content shapes the output without being the target, such as the date, the reader, or their preferences. Clear separators between sources, and headings or variables in capitals, make the parts easy to tell apart.

For reuse, prompt files (.prompt.md) are templates that can include input variables, so you run the same prompt with different data each time. They're supported in IDEs such as VS Code and Visual Studio.

When delegating to Copilot cloud agent, the data is the task scope: select the repository and base branch, then give the objective, acceptance criteria, and relevant files, with screenshots or mockups when visual detail matters.

Specifying the output structure has a big effect on quality. Asking the model to cite its sources makes statements more likely to be grounded, because a fabricated claim would also need a bad citation. A fixed structure, such as entity, relationship, entity, avoids compound statements that are hard to check.

Say the format and length directly: "Return the result as JSON" or "Answer in as few words as possible." A cue at the end of the prompt, such as "Here's a bulleted list of key points:" followed by a bullet, starts the answer in the form you want. Tables are also a space-efficient way to give the model data.

A checkpoint can mean a saved summary created when a long conversation is compacted, a restore point for file edits, or a point to fork a conversation, and which of these a client offers varies. In Copilot CLI, /session checkpoints lists the compaction checkpoints, which help you review what happened and see what was kept.

To undo work in Copilot CLI, wait until Copilot is idle, then press Esc twice or use /undo (alias /rewind) to open the rewind picker. Choose a point, then "Conversation only" or "Conversation + files". The rewind goes back to just before that prompt, restores only files Copilot changed, skips files you edited afterward, and puts the prompt back so you can edit it.

Rewinding can't itself be undone: later history is removed. It isn't available before your first prompt, for remote-backed sessions, or while work is still running.

Custom agents are specialized versions of the Copilot agent, tailored to a workflow so you don't repeat the same instructions in every prompt. Each is defined in an agent profile: a Markdown file whose YAML frontmatter holds an optional name, a required description, optional tools and MCP servers, and whose body is the prompt that sets the agent's behavior (up to 30,000 characters).

Tools decide what the agent can do. Omitting tools gives it every available tool; listing tools limits it to those. To let an agent search the web, add the web alias (or WebSearch or WebFetch) to its tools, and tell it in the prompt when to search. The web alias isn't currently applicable to Copilot cloud agent.

Profiles can live at the user level (~/.copilot/agents/), in a repository (.github/agents/), at the organization level (the organization's .github or .github-private repository), or at the enterprise level.

On GitHub, the agents tab can create a profile for you: choose a repository, choose Create an agent, and GitHub opens a template my-agent.agent.md in .github/agents. Rename it, configure the name, description, tools, and prompt, then commit it and merge it into the default branch. The agent then appears in the agent dropdown.

In VS Code, agents in the repository's .github/agents/ folder are workspace agents: they're shared with everyone on the project through version control. Agents in your user profile are personal and follow you across workspaces.

This deck reads the bullet's "GitHub project" as the project's repository, because that's where GitHub stores agent profiles; GitHub Projects (the planning tool) doesn't hold agents.

The first guardrail is the agent's own profile: list only the tools it needs (for example ["read", "search"] for a read-only agent), use an empty list to disable all tools, or allow only certain tools from an MCP server. The prompt can also limit the agent's scope, such as "only modify documentation files".

Copilot cloud agent has built-in protections. Only users with write access can trigger it, it pushes to a single branch, it can't approve, merge, or mark its own pull requests ready, the person who asked for a pull request can't approve it, and workflows on its pull requests don't run until someone with write access approves them. Its internet access is restricted by a firewall, and hidden characters such as HTML comments are filtered out of its input to reduce prompt injection.

Organizations add their own: rulesets apply to the agent like any developer, CODEOWNERS with "Require review from Code Owners" protects agent and MCP configuration files, Actions secrets stay out of the agent's reach while Agents secrets give it only what it needs, and GitHub-hosted runners give each session a fresh machine.

Every Copilot cloud agent session appears in the agents panel and on the agents page. Opening one shows the log and overview: Copilot's reasoning, the tools it used, the checks it ran, token usage, and session length. Logs help, but they don't replace your own review and testing.

Agent work is traceable. Commits are authored by Copilot with the requester as co-author, signed so they show as Verified, and each commit message links to the session logs. Administrators also have audit log events.

Cloud agent sessions are shared by default with anyone who can access the repository; local sessions from Copilot CLI, IDEs, or the app are unshared unless you share them, view-only. You can also ask Copilot Chat natural-language questions about the sessions you started, as long as they're synced.

GitHub Agentic Workflows are repository automations written in Markdown and run as GitHub Actions workflows (in public preview). Unlike fixed if-then automation, they use a coding agent to understand context and decide what to do. Typical uses are triaging and labeling issues, investigating CI failures, writing daily or weekly status reports, keeping documentation in sync with code, and improving test coverage. The gh-aw gallery adds pull request review, dependency analysis, repository reporting, and cross-repository tracking.

Standard GitHub Actions workflows remain the right tool for deterministic work: builds, tests, linting, deployments, and reproducible scripts, where the same input should always give the same steps and output. Agentic workflows complement that pipeline rather than replacing it, and can include deterministic steps of their own.

Learn frames the difference between assistants and agents. An assistant suggests and waits for you to act; an agent keeps a goal across steps, decides intermediate actions, uses tools, creates durable artifacts such as branches and pull requests, and iterates on feedback from checks and reviews.

A reliable agent task reads like a contract. Inputs are what the agent needs: the issue context, constraints, and boundaries such as which folders it may change. Outputs are what it produces: a plan, a bounded set of changes in a pull request, and evidence such as workflow runs. Success criteria say how results are judged: checks, scans, and review outcomes. Under-specified tasks produce changes that look plausible but don't solve the problem.

Scope matters too. Rather than letting an agent act across the whole development lifecycle, map it to specific stages where GitHub enforces boundaries. Planning maps to issues and pull request descriptions, implementation to branches, commits, and pull requests, validation to workflow runs and checks, and deployment to environments with approvals, which usually stay restricted. Most teams start with implementation and validation.

Breaking work down also follows GitHub's prompting advice: split a large task into smaller ones, and use sub-issues to turn big work into agent-ready pieces.

An agent needs to know what "good" looks like. Learn warns that "CI passed" is necessary but not always enough; criteria should reflect the task's intent, such as "vulnerability resolved" or "no unexpected files changed". Making the important checks required through rulesets or branch protection means the system enforces success instead of trusting the agent's claim.

Inside an agentic workflow, decisions come from the instructions. The gh-aw guidance is to write explicit criteria and examples: conditional rules (if the issue has error messages, label it bug; if it's a feature request, label it enhancement), label definitions, and priority rules. It also says to call out unusual situations and failure handling, such as filing an issue with the error details and exiting without partial changes.

IssueOps uses issue events, such as a new issue, to trigger triage, routing, and responses. ChatOps triggers a workflow when someone types a slash command such as /review in an issue, pull request, or comment; by default only users with write permission can trigger it. LabelOps uses labels as triggers or state; a label command fires once and removes itself so it can be reapplied.

ProjectOps reads GitHub Projects state and applies field changes for judgment-heavy routing; for simple rule-based moves, built-in project automations are usually enough. OrchestratorOps has one workflow decide what to do and dispatch scoped worker workflows. ResearchPlanAssignOps moves from research to planned issues to Copilot implementation to review and merge, with a human checkpoint at every transition.

DeterministicOps combines scripted steps with AI reasoning: deterministic steps collect and prepare reliable data, then the agent interprets it, which suits reports and release summaries.

Each agentic workflow is a Markdown file with two parts. The YAML frontmatter between --- markers sets when it runs (on), its permissions, tools, network access, safe outputs, and the AI engine (Copilot by default; Claude, Codex, and Gemini are supported). The Markdown body holds the instructions the agent follows.

You compile the file with gh aw compile, which produces a hardened .lock.yml GitHub Actions workflow, then commit and push both files to the default branch. The workflow then runs on its trigger, from the Actions tab, or with gh aw run. Prerequisites are GitHub Actions enabled, an AI engine account, and the GitHub CLI with the gh aw extension.

GitHub recommends creating workflows with a coding agent: run gh aw init once to add authoring skills, instructions, and an agent to the repository, then describe the workflow to the agentic-workflows skill in Copilot CLI or VS Code. You can also start from the repository's Agents tab with a prompt, write the file by hand, or import one from another repository with gh aw add.

Triggers go in on and use standard GitHub Actions syntax: issue and pull request events, comments, workflow_dispatch for manual runs from the Actions tab or gh aw run, and schedule. gh-aw adds slash_command for chat commands and label_command for labels, plus filters such as which roles may trigger a run.

Schedules can be plain phrases. Fuzzy schedules such as daily, weekly on monday, or daily around 9am on weekdays give each workflow a consistent, scattered time to avoid load spikes; fixed intervals and cron also work. GitHub Actions enforces a minimum interval of 5 minutes.

Permissions default to read-only. Writes go through safe outputs declared in safe-outputs, such as create-issue, add-comment, or create-pull-request: the agent requests them, and a separate job with the needed permission performs them. With no safe outputs declared, create-issue is enabled with conservative defaults. For the Copilot engine in an organization repository, copilot-requests: write bills usage to the organization through the built-in token, and max-ai-credits caps a run's inference (1,000 AI credits by default).

Agentic workflows live in .github/workflows/ as Markdown files, each beside the .lock.yml file compiled from it, for example ci-doctor.md and ci-doctor.lock.yml. Use descriptive kebab-case names without spaces, and commit both files; the lock file is generated and starts with a header that lists the secrets and actions it uses.

Parts that several workflows share, such as common tools or an MCP server setup, can live in their own Markdown files (for example under shared/) and be pulled in with imports in the frontmatter, optionally with parameters.

Running gh aw init adds the supporting files a coding agent uses to author workflows in the repository: skills, instructions, and a custom agent.

The Markdown body is the agent's brief. The gh-aw guidance: write as if explaining the task to a new team member, be specific, include project context and constraints, and use headings. Start with action verbs such as analyze, create, update, or triage, and state the expected outcome. Numbered lists suit multi-step processes, conditional statements suit decisions, and templates suit outputs that repeat, such as a weekly status report.

Call out unusual situations and failures explicitly, for example: if the workflow fails, file an issue with the error details, apply a failure label, and exit without partial changes. Common pitfalls are over-complexity, assumed knowledge, inconsistent formatting, missing error handling, and vague success criteria.

The body is loaded at runtime, so you can edit the instructions on GitHub.com without recompiling; only frontmatter changes need gh aw compile. The body can also use GitHub Actions expressions, such as the triggering issue number.

Learn describes agent work as a loop rather than a single pass: plan the steps, act in the repository, then evaluate the results with feedback signals such as workflow runs and checks, review comments, and security scans, and repeat until the success criteria are met. Plans are most reviewable when they state scope, success criteria, and a rollback or escalation path, and separating planning, execution, and validation lets reviewers catch a misunderstanding before it becomes a large diff.

GitHub builds a critique step into Copilot CLI and the Copilot app with the rubber duck agent. The main agent passes its plan, implementation, or tests to a critic that runs on a deliberately different model, so it's less likely to share the same blind spots. The critic is read-only, reports blocking issues, non-blocking issues, and suggestions, and the main agent decides what to apply. By default it isn't invoked automatically; you ask for it, for example "Rubber duck your plan."

Copilot cloud agent does something similar on its own work: it checks code it generates for security issues and gets a second opinion from Copilot code review, trying to resolve what they find before finishing.

Copilot automations let Copilot cloud agent run a task automatically instead of waiting for someone to start a session. You create them in a private or internal repository with cloud agent enabled, from the repository's Agents tab (Automations pane) or the Copilot app's Automations tab; anyone with write access can create one. They're available on Copilot Pro, Pro+, Max, Business, and Enterprise plans, and not in public repositories.

Triggers are: on a schedule (hourly, daily, or weekly), when an issue is created, when a pull request is opened, and when a pull request is synchronized (new commits pushed). Issue triggers can take a search query filter; pull request triggers can also filter by files changed.

To reduce prompt injection, automations ignore events from users without write access by default, so an outside contributor's issue doesn't make Copilot act unless you opt in. Run now tests an automation immediately.

Each automation defines a name, a prompt describing the task, one or more triggers, the model Copilot uses (optional), and the tools it may use. Because the task runs with nobody present, the prompt must stand on its own, for example "Label this issue as a bug, an enhancement, or other, based on its content."

Automations are private to their creator, but the sessions they start are visible to everyone with access to the repository, including the prompt and logs. Never put secrets in the prompt; give Copilot sensitive values through repository secrets for cloud agent.

Automations use the repository's cloud agent configuration: custom instructions, agent skills, firewall rules, and secrets and variables. They're stored outside the repository, so they aren't versioned or reviewed through pull requests, and each run uses Actions minutes and AI credits billed to the creator. Agentic workflow files are the alternative when the automation should live in Git.

Tools are the main way to control an automation: for example pushing changes, updating issue labels, or creating a pull request. Select only the tools the task requires; the Suggest tools button can propose a set from your prompt. An automation acts only in the single repository it's scoped to.

When an automation changes an issue, it can explain each change and rate its confidence, applying high-confidence changes automatically and proposing the others for review.

Built-in protections keep people in control. Pull requests and pushes are attributed to the automation's creator, who therefore can't approve them, which keeps required approvals meaningful, and GitHub Actions workflows on those pull requests wait until someone with write access approves them.

GitHub CLI's gh skill (public preview) finds, previews, installs, updates, and publishes skills from GitHub repositories: gh skill search, gh skill preview OWNER/REPO SKILL, and gh skill install. You can install a specific version with @TAG, lock one with --pin, and refresh unpinned skills with gh skill update.

GitHub warns that skills aren't verified and may contain prompt injections, hidden instructions, or malicious scripts, so preview a skill before installing it.

Without the CLI, download the skill's directory and place it in .github/skills, .claude/skills, or .agents/skills for one repository, or in ~/.copilot/skills or ~/.agents/skills for all your projects. Community collections include github/awesome-copilot.

Create a directory for the skill, lowercase with hyphens, inside a skills folder, and add a file named exactly SKILL.md. Its YAML frontmatter needs a name (usually matching the folder) and a description saying what the skill does and when to use it; license is optional. The Markdown body holds the instructions, examples, and guidelines.

Scripts and other resources can sit in the same folder; Copilot discovers them when the skill is used, and the instructions say when and how to run them. The allowed-tools field can pre-approve tools so Copilot doesn't ask each time, but pre-approving shell or bash removes the confirmation for terminal commands, so do it only for skills you've reviewed and trust.

GitHub's rule of thumb: custom instructions for short guidance that applies to almost every task, skills for detailed instructions that matter only for certain tasks.

Copilot decides when to use a skill based on your prompt and the skill's description. When it chooses one, it injects the SKILL.md into its context and can use the scripts and examples in the skill's folder, so a clear description is what makes a skill get used.

In Copilot CLI you can ask for a skill by name with a forward slash, for example "Use the /frontend-design skill to create a responsive navigation bar." /skills list shows what's available, and /skills reload picks up skills added during a session.

Skills work in Copilot cloud agent, Copilot code review, Copilot CLI, the Copilot app, and agent mode in VS Code and JetBrains IDEs. Code review uses relevant skills from .github/skills; naming a folder for review, such as code-review, makes sure it reads that one.

Agentic workflows expose only the tools you configure. The GitHub MCP server is built in and read-only: under tools: github: you choose toolsets such as repos, issues, pull_requests, actions, or discussions; [default] covers context, repositories, issues, and pull requests. Write actions still go through safe outputs.

For other systems, add servers under mcp-servers: in the frontmatter, either by url for a hosted server or container for one run in Docker, restrict the tools with allowed, and pass any credentials from GitHub Actions secrets. Some integrations, such as Linear, have built-in tool entries.

After compiling, gh aw mcp inspect shows the tools a workflow exposes. Keep the list short: every enabled tool adds to the context sent on each request, which costs tokens.

Responsibility doesn't move to the agent. Learn names the accountable parties: whoever defined the task, set permissions, chose the controls, and approved the change. The pattern is that the agent proposes and humans decide.

The pull request is the main checkpoint. A safe flow is: the agent creates a branch, opens a pull request that includes its plan, reviewers validate the approach, required checks run, and only then can it merge. A pull request template can require a plan with goal, scope, steps, success criteria, risks, and a rollback plan, and CODEOWNERS routes sensitive areas to the right reviewers.

Some actions need approval even before that: deployment usually stays restricted behind environments with required reviewers, workflow and infrastructure changes are higher risk than application code, and agentic workflows can make critical actions require human approval. Watch for anti-patterns that remove judgment: planless execution, over-permissioned agents, hidden reasoning, and blind trust in passing CI.

The GitHub Copilot app and Copilot CLI offer three modes. In Interactive mode you and the agent work together and it waits for your input. In Plan mode it writes a plan that you review and approve before it executes. In Autopilot mode it works on its own: writing code, running tests, evaluating results, and iterating until it judges the task done.

Choose by how clear the task is. Interactive suits exploring a problem or making frequent decisions; Plan suits reviewing the approach first; Autopilot suits a task with a clear outcome and enough detail, and vague or open-ended tasks in Autopilot tend to miss expectations. Autopilot can make many model calls, so watch AI credits.

Autonomy and permissions are separate: Autopilot only decides whether the agent continues without another prompt, while tool permissions decide what it may do without asking. A typical safe flow is to plan in Plan mode, switch to Autopilot, monitor and interrupt if needed, then review the changes. You remain responsible for the result, and stopping doesn't undo work already done.

Copilot CLI escalates by tool risk. Read-only actions such as searching, reading files, and read-only commands run automatically; tools that can change your system, such as editing files, destructive commands, or fetching URLs, ask for approval each time unless you've granted it. Approvals can be saved for a repository or directory.

You can set the path in advance: --allow-tool lets a tool run without asking, --deny-tool blocks it, and deny always wins, even over --allow-all or saved approvals. --available-tools and --excluded-tools go further and hide tools from the model entirely.

For policy-level control, a preToolUse hook in .github/hooks/*.json runs before every tool use in Copilot cloud agent and Copilot CLI and can approve or deny it, for example to block dangerous commands or require approval. Learn's reliability pattern completes the picture: let the agent retry when checks fail, but summarize persistent failures and hand them to a human.

When an automation (Copilot cloud agent automations, GitHub Agentic Workflows, or the APIs) changes issues, it records a rationale for each change and rates its confidence. Changes it holds back appear as suggestions in a panel on the issue, where you accept or decline each one, or accept all or decline all. This covers labels, fields, issue type, closing, and assignees, and is in public preview.

The repository's automation level decides what waits for you: Full control holds everything, Cautious (the default) applies only high-confidence changes, Balanced applies routine ones, and Full automation applies everything not flagged uncertain. GitHub stresses that approvals are a convenience, not a security control; limit what an agent can do with permissions.

For revisions to a pull request Copilot cloud agent opened, mention @copilot in a comment. It reacts with 👀 and starts working, but only for people with write access and only while the pull request is open. In Plan mode, approving or revising the plan is the request you answer before work starts.

A running Copilot cloud agent session can be steered: open it on the agents page and type a follow-up below the log. Copilot applies it after the current tool call, so you change direction without restarting. Each steering message uses AI credits, and steering isn't available for third-party coding agents.

You can also work in stages. Ask cloud agent research questions, have it propose a plan and refine it, then have it implement on a copilot/ branch. Review the Diff, ask for refinements, and create the pull request when you're satisfied; sessions don't open pull requests unless you ask.

With remote control enabled, you can monitor and steer a Copilot CLI session from GitHub.com while it keeps running on your machine, which must stay online. Copilot Chat on GitHub.com can also report a cloud agent session's progress while it runs.

For a failed agentic workflow run, the gh-aw docs recommend starting Copilot CLI, invoking the agentic-workflows skill, and pasting the run URL; Copilot downloads the logs, finds the root cause (missing tools, permission errors, network blocks), and suggests a fix or opens a pull request. gh aw audit RUN-ID produces a detailed report of tools, MCP servers, firewall activity, cost, and safe outputs, and can compare runs.

For Copilot cloud agent, check the session logs first. A stuck session times out after an hour; retry by unassigning and reassigning the issue, or post the comment again if it stalled on one. If it ignores comments, check that the commenter has write access, Copilot is still assigned, and the pull request is open.

Workflows don't run automatically on Copilot's pushes: someone with write access must click Approve and run workflows. If Copilot keeps pushing changes that fail CI, clearer repository custom instructions about how to test help it validate its own work.

An agentic workflow runs as a GitHub Actions workflow, so you stop it like any run: open the Actions tab, select the workflow, open the queued or in-progress run, and click Cancel workflow, which stops all its jobs and steps.

A Copilot cloud agent session has a Stop session button in the session log viewer. Stopping ends its Actions run and keeps any commits already pushed; the stopped session can then be archived.

In Copilot CLI, press Esc twice or Ctrl+C once to cancel the current operation. Stopping doesn't undo work already done, so use the rewind (/undo or /rewind) to restore the files Copilot changed.

Learn's contributor model treats agent work as a contribution judged by the workflow's standards. A review rubric asks about intent (a clear goal and plan), scope (files match the plan), evidence (checks pass, logs and artifacts available), ownership (CODEOWNERS reviewed sensitive areas), policy (rulesets and environments followed), and fallback (rollback or escalation for risky changes).

The model avoids two errors: excessive suspicion, rejecting work because AI wrote it, and excessive trust, accepting it because automation produced it.

To check requirements you need evidence. A well-run agent task leaves a structured plan, a bounded pull request and commit history, links to required check runs, uploaded artifacts such as test reports, and review outcomes; Learn suggests gathering links in an "Evidence" section of the pull request.

Staged mode (staged: true under safe-outputs) lets a workflow run fully while replacing its writes with a preview in the Actions run summary, so maintainers can judge what it would create before it creates anything. It can be applied to some output types only, and it isn't a sandbox for custom jobs, scripts, or external MCP servers.

The gh-aw safe rollout ladder raises autonomy in steps: report-only, staged previews, shadow evaluation against a safe non-production target when the real write path needs testing, then direct production writes. A threat detection job also runs automatically after the agent finishes and before safe outputs apply, checking for prompt injection, secret leaks, and malicious code changes.

For pull requests, decide when the plan is reviewed: a plan-first pull request gets approval before any code, which suits higher-risk or unclear work; plan and code in one pull request is faster. Either way, the output ends up reviewed in a pull request.

Agentic workflow runs appear in the Actions tab like any workflow. gh aw logs lists recent runs with duration, token usage, and AI credit estimates, and gh aw audit RUN-ID inspects one run in detail. Cost has two parts, Actions minutes and inference; max-ai-credits caps a run's inference (1,000 AI credits by default), and with the Copilot engine usage counts toward Copilot AI credits.

To judge impact, gh-aw recommends reading layers separately rather than combining them into one score: operations (run count, completion rate, retries, duration), cost efficiency (AI credits per successful run), outcomes (accepted, rejected, or pending outputs, from gh aw outcomes), and long-term effects such as backlog or review time.

Enterprise admins can watch agent activity on the AI controls page: recent agent sessions (all from the last 24 hours, filterable) and the audit log, which can be streamed. OpenTelemetry can also export Copilot client data to an observability tool.