Terminal-first development with GitHub Copilot CLI

Developers live in the terminal: initializing projects, running tests, debugging CI failures, and making quick mechanical edits before code is ready for review. GitHub Copilot CLI is built around that reality, offering a GitHub-aware coding agent that helps you move from intent to reviewable diffs without leaving your shell.

This guide walks through a practical workflow for building an application with Copilot CLI, based on a new GitHub Skills exercise. It focuses on when and why each step matters in real projects, rather than rehashing the exercise itself.

What Copilot CLI does—and what it doesn't

Copilot CLI is a terminal-based coding agent that understands GitHub context. You describe what you want in natural language, use /plan to sketch out work before touching code, and review concrete commands or diffs before anything executes. The agent can reason internally, but it only runs commands or applies changes after you explicitly approve them.

In practice, the tool helps you:

  • Explore a problem based on your stated intent
  • Propose structured plans with /plan (or Shift + Tab for planning mode)
  • Suggest concrete commands and diffs
  • Generate or modify files
  • Explain failures where they occur

What it won't do is silently execute commands, replace careful design work, or remove the need for human review. You remain in control of what runs, what changes, and what ships.

Start with intent, not scaffolding

Rather than picking a framework or template first, begin by describing what you want to build—even from an empty directory:

copilot
> Create a small web service with a single JSON endpoint and basic tests

Prefer a one-shot proposal over interactive mode? Generate a plan in a single prompt:

copilot -p "Create a small web service with a single JSON endpoint and basic tests"

In the Skills exercise, this pattern recurs: state intent first, then review the suggested commands before deciding what to run. At this stage, Copilot CLI explores the problem space—suggesting a stack, outlining files, proposing setup commands—without executing anything automatically.

Scaffold what you're ready to own

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 the CLI delivers immediate value. It can create directories and config files, wire basic project structure, and generate boilerplate you'd otherwise type manually. But it doesn't "own" the resulting structure—treat its output as a starting point from a teammate: review it, edit it, or discard it.

Iterate at the point of failure

Run your tests directly inside Copilot CLI:

Run all my tests and make sure they pass

When something fails, ask about that exact failure in the same session:

> Why are these tests failing?

For a concrete proposal instead of an explanation, request one:

> Fix this test failure and show the diff

The run–inspect–ask–review pattern keeps the agent grounded in real output. explain is ideal when you want understanding; suggest works better when you want a proposal you can review.

Handling mechanical, repo-wide changes

Copilot CLI excels at 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 straightforward to review and roll back. You get a concrete diff rather than a wall of generated prose.

When to move into your editor

At some point, precision outweighs speed. That's the natural handoff point to your IDE, where you can reason about edge cases, refine APIs, and make design decisions you'll defend in review. Copilot works there too, but the reason for switching is clear: the CLI helps you get to something real fast; the IDE lets you shape it precisely.

A practical rule of thumb:

  • CLI: use /plan, generate /diff, move quickly with low ceremony
  • IDE: use /IDE to refine logic and make thoughtful decisions
  • GitHub: commit, open a pull request with /delegate, collaborate asynchronously

Shipping on GitHub

When changes look good, commit and open a pull request through the 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

This is where the work becomes durable—reviewable by teammates, testable in CI, and ready for async iteration. The value compounds when Copilot is part of a flow that ends in shipping, not just single-surface suggestions.

One workflow, three moments

A useful mental model:

  • CLI: prove value quickly with minimal ceremony
  • IDE: shape and refine what you've built
  • GitHub: review, collaborate, and ship

Copilot CLI is powerful precisely because it fits into this workflow instead of trying to replace it. Used well, it helps you move from idea to concrete change faster: exploring options, scaffolding projects, diagnosing failures, and handling mechanical work directly in the terminal. When precision is needed, shift to the editor. When work is shareable, land it on GitHub as a pull request.

Copilot performs best when it aligns with how developers already build software: start in the CLI to get unstuck or accelerate, slow down in the IDE for decisions you can stand behind, and use GitHub to make the work permanent.