Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
A hands-on guide to using GitHub Copilot CLI to move from intent to reviewable changes, and how that work flows naturally into your IDE and GitHub.
Most developers already do real work in the terminal.
We initialize projects there, run tests there, debug CI failures there, and make fast, mechanical changes there before anything is ready for review. GitHub Copilot CLI fits into that reality by helping you move from intent to reviewable diffs directly in your terminal—and then carry that work into your editor or pull request.
This blog walks through a practical workflow for using Copilot CLI to create and evolve an application, based on a new GitHub Skills exercise. The Skills exercise provides a guided, hands-on walkthrough; this post focuses on why each step works and when to use it in real projects.
If you want a fully guided version of this workflow, including hands-on practice, check out the GitHub Skills exercise Create applications with the Copilot CLI.
It walks through these patterns step by step in a preconfigured instance of GitHub Codespaces and is a good way to experiment safely before applying them to production code. The exercise covers the following:
Copilot CLI is a GitHub-aware coding agent in your terminal. You can describe what you want in natural language, use /plan to outline the work before touching code, and then review concrete commands or diffs before anything runs. Copilot may reason internally, but it only executes commands or applies changes after you explicitly approve them.
In practice, Copilot CLI helps you:
/plan (or you can hit Shift + Tab to enter planning mode), or suggest concrete commands and diffs you can reviewWhat it does not do:
You stay in control of what runs, what changes, and what ships.
Instead of starting by choosing a framework or copying a template, start by stating what you want to build.
From an empty directory, run:
If you want to generate a proposal in a single prompt instead of entering interactive mode, you can also run:
In the Skills exercise, this pattern is used repeatedly: describe intent first, then decide which suggested commands you actually want to run.
At this stage, Copilot CLI is exploring the problem space. It may:
Nothing runs automatically. You inspect everything before deciding what to execute. This makes the CLI a good place to experiment before committing to a design.
Once you see a direction you’re comfortable with, ask Copilot CLI to help scaffold:
This is where Copilot CLI is most immediately useful. It can:
Copilot CLI does not “own” the project structure. It suggests scaffolding based on common conventions, which you should treat as a starting point, not a prescription.
The important constraint is that you’re always responsible for the result. Treat the output like code from a teammate: review it, edit it, or discard it.
Run your tests directly inside Copilot CLI:
When something fails, ask Copilot about that exact failure in the same session:
If you want a concrete proposal instead of an explanation, try:
This pattern—run (!command), inspect, ask, review diff—keeps the agent grounded in real output instead of abstract prompts.
💡Pro tip: In practice, explain is useful when you want understanding, while suggest is better when you want a concrete proposal you can review. Learn more about slash commands in Copilot CLI in our guide.
Copilot CLI is also well suited to changes that are easy to describe but tedious to execute:
Because these changes are mechanical and scoped, they’re easy to review and easy to roll back. The CLI gives you a concrete diff instead of a wall of generated text.
Eventually, speed matters less than precision.
This is the natural handoff point to your editor or IDE, so it can:
Copilot works there too, but the key point is why you switch environments. The CLI helps you quickly get to something real. The IDE is where you can shape your code into exactly what you want.
A good rule of thumb:
/plan, generate a /diff, and move quickly with low ceremony/IDE when you need to refine logic and make decisions you’ll defend in review/delegate, and collaborate asynchronouslyOnce the changes look good, commit and open a pull request which you can do through the Copilot CLI in natural language:
Now the work becomes durable:
This is where Copilot’s value compounds as part of a flow that ends with shipping versus just being a single surface. The Skills exercise intentionally ends here, because this is where Copilot’s value becomes durable: in commits, pull requests, and review (not just suggestions).
A helpful mental model for Copilot looks like this:
Copilot CLI is powerful precisely because it fits into this system instead of trying to replace it.
If you’re building a developer tool, internal system, or application where agentic execution itself is part of the product (not just something you run in a terminal), you may want to look at the GitHub Copilot SDK, now in technical preview.
The Copilot SDK gives you programmatic access to the same planning and execution engine that powers Copilot CLI, without requiring you to build or maintain your own orchestration layer. Instead of wiring planners, tools, and recovery logic yourself, you define agent behavior and let Copilot handle execution.
Use Copilot CLI when you want fast, interactive execution in your own workflow. Use the Copilot SDK when you want those same agentic capabilities embedded inside your application. The SDK exposes the execution engine behind Copilot CLI, but not GitHub-specific features like repository-scoped memory or delegated pull request workflows.
Copilot CLI is most useful when you treat it like a tool for momentum, not a replacement for judgment.
Used well, it helps you move from intent to concrete changes faster: exploring ideas, scaffolding projects, diagnosing failures, and handling mechanical work directly in the terminal. When precision matters, you move into your editor. When the work is ready to share, it lands on GitHub as a pull request—reviewable, testable, and shippable.
That flow matters more than any single command.
If you take one thing away from this guide, it’s this: Copilot works best when it fits naturally into how developers already build software. Start in the CLI to get unstuck or move quickly, slow down in the IDE to make decisions you can stand behind, and rely on GitHub to make the work durable.
Get started with GitHub Copilot CLI or take the Skills course >