Assign an issue to Copilot

Take the first item off the backlog: the validation edge case where an order sitting exactly at the threshold should require approval, but currently slips through as under it. You could open VS Code and fix it in Agent mode — it’s a small change. But it’s also the kind of task you’d happily hand a teammate and forget about until their PR shows up. That’s precisely what the cloud agent is for.

What “assign” actually does

When you assign work to Copilot, GitHub spins up an ephemeral GitHub Actions environment — a fresh, isolated checkout of the repo that exists only for the duration of this task and is torn down afterward. The agent works entirely in there: it reads the issue, explores the code, makes its changes, runs whatever it can, and packages the result. None of it happens on your machine. You’re not watching a loop run; you’ve handed off a unit of work and the next thing you’ll hear from it is a pull request.

That’s why this is async in a way nothing earlier in the course was. There’s no chat view to babysit. The unit of interaction is the issue, and the unit of return is the PR.

Where you can kick it off

There’s no single button — assignment lives in several places, so you can start the agent from wherever you already are:

• The Agents panel on GitHub.com — the central place to see and start agent work across your repos.
• Assigning an Issue to Copilot — the most natural one for clearing a backlog. Open the issue, assign it to Copilot like you’d assign it to a person, and it begins. This is the move for our threshold edge case: write the issue clearly, assign, walk away.
• @copilot in a pull request comment — start or extend agent work from inside a PR thread (you’ll lean on this in the next lesson).
• From VS Code — hand a task off to the cloud agent without leaving the editor, when you realize mid-session that something is better run async than driven by hand.
• From security alerts or campaigns — point it at a flagged vulnerability and let it propose the fix.

There are also ways to assign from outside GitHub entirely — an issue tracker, for instance — but those arrive via integrations and are still preview, so treat them as a convenience on top, not the core path. The dependable spine is the list above.

Write the issue like you mean it

The quality of what comes back tracks the quality of the issue, the same way a prompt’s clarity shaped Copilot’s answer in the modes chapter — except now there’s no follow-up turn to course-correct in real time. Describe the behavior you want and the boundary of the change: “Orders exactly at the approval threshold currently skip approval; they should require it. Fix the comparison and add a test for the boundary.” You’re not writing pseudocode, you’re writing the same crisp behavioral description that’s served you all along — it just has to stand on its own, because you won’t be in the room while it works.

And it won’t be working from a blank slate. The cloud agent reads the same custom instructions and skills you wrote earlier in the course, so it already knows your conventions and the audit-event pattern before it touches a line.

Assign the issue. The agent goes to work, and what it brings back is the subject of the next lesson — it proposes, you merge.