Copilot cloud agent: from issue to PR without losing control

Assigning an issue to an agent is easy.

Getting a reviewable PR is different. The cloud agent can search the repo, plan, edit code, and open a PR. But it does not know your product boundaries, risk tolerance, or definition of done unless you write them down.

Quality starts in the issue.

1. Write the issue like a contract

A good agent issue includes:

• observed problem;
• expected result;
• likely files or areas;
• what is out of scope;
• test or proof expected;
• no direct merge.

Example:

## Goal
Add the empty state on /ai-coding when no tutorials are published.

## Constraints
- Do not change the Astro collection.
- Do not touch the header.
- Keep the EN version consistent.

## Acceptance
- bun run build passes.
- A screenshot or render note is included in the PR.

The goal is not micromanagement. It is removing expensive ambiguity.

2. Split broad issues

Bad task: “improve the blog UX”.

Good task: “limit the daily feed to eight articles and add a See all link”.

The cloud agent is useful on a verifiable unit of work. Put three product decisions in the same issue and the review becomes an investigation.

3. Review scope before code

Before line review, check:

• files changed;
• dependencies added;
• migrations;
• config changes;
• routes touched;
• deleted or skipped tests.

If the PR leaves the contract, ask for an iteration before reading details. It is faster than commenting fifteen lines.

4. Feedback that works

When the agent drifts, answer like you would to a developer:

The PR goes out of scope by changing the header.
Return to the original contract:
- only /ai-coding
- no global design changes
- keep tests/build
Then explain what you removed.

The more operational the feedback, the less the second pass drifts.

Sources

• GitHub Docs - Copilot cloud agent
• GitHub Docs - Starting Copilot sessions