How Copilot Workspace approaches a task

GitHub Copilot Workspace is a Copilot-native development environment built for everyday coding tasks. You can open an issue, pull request, template repository, or ad-hoc task from GitHub and work through it in sessions that flow through distinct stages:

  • Spec/Brainstorming (optional): Ask questions about your codebase and explore approaches to your task with Copilot as a thought partner.
  • Plan: Copilot determines which files need changes and what changes each requires. Plans are fully editable—you can add, edit, or remove steps.
  • Implementation: Copilot streams code suggestions into the environment. You can verify changes using the built-in terminal or a codespace before opening a pull request.

You can bounce between these stages as needed, regenerating suggestions at any point. Once a solution lands, you can raise a pull request, create a branch, or in some cases spin up a new repository.

After five months of the technical preview, the GitHub Next team and community have collected a set of practical tips for getting the most out of the tool.

Define what done means, explicitly

Vague goals are the leading cause of poor AI results. The clearer you can state what success looks like, the more reliably Copilot Workspace will match your expectations. This applies to any interaction with GitHub Copilot, but in Copilot Workspace it starts with your task description.

Write a few bullet points capturing your acceptance criteria in the issue or task itself—no need for lengthy prose. If you know which files, classes, components, or directories are involved, name them. Copilot Workspace can also pull context from URLs referenced in your task, including issues, pull requests, and repository files, as well as public documentation. Linking to style guides, unit test conventions, or other relevant docs helps steer the solution in the right direction.

Break larger tasks into smaller pieces

For bigger problems, articulating the desired end state becomes harder. Decomposing work into smaller, well-defined tasks makes it easier to specify what done looks like, and it aligns with the usual development practice of one commit per logical change.

Treat the output as a draft, then iterate

Copilot Workspace is designed so users can steer the process at every step. That means treating each suggestion as a first attempt rather than a final answer deserves some revision and back-and-forth, just as you would with another developer.

When a session starts, review the task description to verify Copilot is solving the right problem—edit it if not. Every stage is intentionally editable so you can adjust course. If the plan or spec looks wrong, modify or regenerate it. You can also undo suggestions and return to an earlier state. Rephrasing prompts and reworking outputs as you go will generally produce better results than accepting the first pass.

Edit the code directly when tweaks are small

Iterating through task, spec, and plan is not always the fastest path when only minor code changes remain. The Copilot Workspace editor supports direct editing, and Copilot's ghost text and other language services work in the environment. Sometimes it makes more sense to just make the change by hand than to re-prompt Copilot.

Run builds and tests in the environment

Validating changes before opening a pull request is standard practice, and it works in Copilot Workspace too. The built-in terminal lets you run your local build and test suite, and terminal assist can help resolve errors. This lets you iterate to an acceptable level of quality inside Copilot Workspace before the more rigorous CI checks and peer review kick in on your pull request.