Get started with GitHub Copilot CLI or take the Skills course >
Copilot CLI bridges the gap between terminal workflows and AI assistance. It keeps engineers in their flow state by handling scaffolding, debugging, and mechanical changes without context switching, while ensuring safety through mandatory manual approval of all suggested actions.
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.
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:
copilot
> Create a small web service with a single JSON endpoint and basic tests
If you want to generate a proposal in a single prompt instead of entering interactive mode, you can also run:
copilot -p "Create a small web service with a single JSON endpoint and basic tests"
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:
> Scaffold this as a minimal Node.js project with a test runner and README
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:
Run all my tests and make sure they pass
When something fails, ask Copilot about that exact failure in the same session:
> Why are these tests failing?
If you want a concrete proposal instead of an explanation, try:
> Fix this test failure and show the diff
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:
> Rename all instances of X to Y across the repository and update tests
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:
Add and commit all files with a applicable descriptive messages, push the changes.
Create a pull request and add Copilot as a reviewer
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.
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 >
The post From idea to pull request: A practical guide to building with GitHub Copilot CLI appeared first on The GitHub Blog.
Continue reading on the original blog to support the author
Read full articleThis demonstrates how to use AI and automation to solve 'tragedy of the commons' issues like accessibility that cross team boundaries. It provides a blueprint for building agentic workflows that enhance human productivity and ensure critical user feedback is never lost in the backlog.
AI-driven code reviews are reaching massive scale, shifting from pattern matching to agentic reasoning. For engineers, this means faster PR cycles and higher-quality feedback, as tools now prioritize architectural context and actionable signals over generic linting or noise.
This article highlights how structured AI integration in production workflows bridges the global talent gap. For engineers, it demonstrates practical strategies for using AI to navigate legacy systems, improve test coverage, and accelerate onboarding in high-stakes environments.
These events provide engineers with hands-on experience in AI-assisted development, helping them integrate tools like GitHub Copilot into their daily workflows. Staying updated on AI tools is crucial for maintaining productivity and efficiency in a rapidly evolving software landscape.