Copilot's cloud agent: a checklist before you assign the task · Resource

Open this card next to the repository before you assign an issue to GitHub Copilot's cloud agent. Its six blocks follow the order of the work: first you decide whether the task suits the agent at all, then you write the issue, check the repository and the guardrails, and finally run the review. The last block is for a one-off: your first trial with the team. Each block has boxes to tick and one sentence to remember.

One reminder before you start. The cloud agent works alone, in its own environment on GitHub Actions, and hands back a pull request. You aren't sitting next to it, so everything it needs has to be written down beforehand.

1. Is this a task for the agent

[ ] The task can be described in a few sentences, with no "we'll see as we go".
[ ] You can judge the result in a short review: a bug fix, a test, a small UI change, accessibility, documentation, configuration, technical debt in one place.
[ ] The task doesn't need knowledge across several repositories or a large redesign where consistency matters.
[ ] The task doesn't touch a production outage, an incident, security, personal data or authentication.
[ ] It isn't a task a developer wants to do themselves to learn something.
[ ] If any point above fails, leave the task to a person or split it into smaller ones.

The agent gets tasks whose result you can judge quickly. Move that line only once you have seen what it handles well.

2. An issue that works as a prompt

[ ] Read the issue as if it were an instruction to a model. Is it clear what to do?
[ ] The description of the problem or the work is clear and complete.
[ ] Acceptance criteria are written down, for example whether unit tests are expected, what must pass, what must not change.
[ ] Pointers to the files or directories to change are added wherever you know them.
[ ] For a larger task, ask first for research, a plan and changes on a branch, and for a pull request only after you have seen the diff.

The issue text is the whole instruction the agent gets from you. If it would not work as a prompt, don't assign it.

3. A repository ready for the agent

[ ] The repository has a .github/copilot-instructions.md file describing the project, how to build and test it, and its conventions.
[ ] Rules for particular file types live in .github/instructions/**/*.instructions.md with an applyTo key, not in the main file.
[ ] Project dependencies are pre-installed in copilot-setup-steps.yml, so the agent doesn't have to find them by trial and error.
[ ] The agent can build the project and run tests and linters in its own environment.
[ ] For recurring, specialized work, consider a custom agent with a limited toolset, for example a testing agent that can't change production code.

An agent that can build and test its own change is more likely to hand back pull requests ready to merge. An agent that guesses dependencies hands back pull requests that need fixing.

4. Guardrails before you switch it on

[ ] You know which organizations and repositories the agent will be enabled in.
[ ] You know which MCP servers it will reach, and each one is a deliberate decision.
[ ] Rulesets in repositories with the agent have the requirements you need, such as code scanning results.
[ ] No existing ruleset blocks the agent through commit metadata requirements.
[ ] Copilot and MCP configuration files are listed in CODEOWNERS, with a rule requiring code owner review.
[ ] Secrets the agent should not see stay as GitHub Actions secrets and variables. What it needs goes into agent secrets and variables.
[ ] The agent runs on GitHub-hosted runners or on ephemeral self-hosted runners.
[ ] You know whether workflows on the agent's pull requests wait for approval from someone with write access, and repository administrators know the setting.
[ ] Default GITHUB_TOKEN permissions are reviewed, and copilot-setup-steps.yml uses minimum permissions.

The agent's built-in protections (no pushing to the default branch, no merging) are the starting point. You set the rest of the limits before the agent gets the repository.

5. Reviewing the agent's pull request

[ ] You review it the same way as a pull request from a person: same bar, same tests.
[ ] You collect your remarks into one review (Start a review) and submit them together, not as single comments.
[ ] Your comment tags @copilot and says specifically what is wrong or what to change.
[ ] Comments come from someone with write access, because the agent ignores the rest.
[ ] For merge conflicts, you ask the agent to resolve them or fix the branch yourself.
[ ] Before merging, you check that the pull request title and description match the final change.

One batched review is one round of work for the agent. Five single comments are five separate rounds.

6. A first trial with the team

[ ] The trial team includes people from different roles.
[ ] The trial repository is low-risk, for example documentation or internal tools, and already has project context.
[ ] The agent is enabled in that repository, with instructions and environment tools prepared.
[ ] You have picked a few concrete use cases, such as test coverage or accessibility.
[ ] Issues are rewritten along the lines of block 2, and the team knows reviews are coming.
[ ] Every week you refine the instructions, the tools, MCP access and the way issues are written.
[ ] You track how many AI credits and GitHub Actions minutes the agent consumes, to budget for a wider rollout.
[ ] You judge the impact by the goals the team already has, not by the number of pull requests the agent opened.

The trial exists to settle your rules for working with the agent. Its output is better instructions and issues, not just a yes or no.

After the card

If blocks 1 to 5 are all ticked, assign the issue and come back to it at review time. If a point fails, stop right there: fixing the issue or the rule takes less time than reviewing a pull request that was built without it.