Skip to content

CLI-IDE-GitHub Context Ladder

A three-surface workflow that matches the right AI environment to each development phase — CLI for exploration, IDE for refinement, GitHub for durable collaboration — with context preservation across transitions.

The three-surface model

Development with AI assistants spans three surfaces. Each suits a different phase of work. GitHub's Copilot CLI guide states it plainly: "CLI proves value quickly, IDE refines precision, GitHub ships durably" (GitHub Blog).

graph LR
    A[CLI<br/>Exploration] -->|Diffs, plans| B[IDE<br/>Refinement]
    B -->|Commits, PRs| C[GitHub<br/>Collaboration]
    C -->|"--from-pr, @copilot"| B
    B -->|Terminal tab| A

The ladder is not strictly linear. You move between surfaces based on what the task demands, carrying context through structured artifacts at each transition.

CLI surface: exploration and scaffolding

The CLI is fast and low-ceremony, so it suits exploration. Nothing runs automatically — you inspect everything before you decide what to run (GitHub Blog).

Best suited for:

  • Scaffolding minimal projects from natural-language intent
  • Running tests at point of failure and diagnosing errors
  • Mechanical repo-wide changes (renames, migrations)
  • Exploring problem spaces before committing to a design

Copilot CLI provides a /diff command for syntax-highlighted inline review. It also delegates to four built-in agents — Explore, Task, Code Review, and Plan — based on the request (GitHub Changelog).

Claude Code CLI follows the Unix philosophy — pipeable, scriptable, and composable with other tools. Plan mode (--permission-mode plan) restricts the CLI to read-only operations, which helps you explore before you implement (Claude Code docs).

The CLI produces diffs and plans as intermediate artifacts — concrete outputs that bridge exploration to the next surface.

IDE surface: refinement and implementation

In the IDE, precision matters more than speed. This is where you "make decisions you'll defend in review" (GitHub Blog).

Best suited for:

  • Multi-file reasoning and semantic understanding
  • Visual diff review before committing
  • Edge case handling and API refinement
  • Inline suggestions and targeted code generation

VS Code Copilot agent mode runs multiple steps on its own — it breaks work into steps, edits files, runs commands, and corrects its own errors (VS Code docs).

Claude Code runs across VS Code, JetBrains, and Desktop. The same engine, CLAUDE.md files, and MCP servers work on every surface (Claude Code docs).

GitHub surface: durable collaboration

GitHub is where individual work becomes durable, through PRs, CI pipelines, and async review.

Best suited for:

  • Opening PRs that trigger CI validation
  • Asynchronous code review with teammates
  • Agent-driven iteration via @copilot or @claude comments
  • Long-running autonomous work (coding agent, GitHub Actions)

The Copilot coding agent works asynchronously via GitHub Actions: it plans work, writes code, runs tests, self-reviews, runs security scanning, and opens a PR (GitHub Docs).

Context preservation across surfaces

The ladder works only if context survives transitions. Several mechanisms keep it intact:

Instruction files

CLAUDE.md files work across all Claude Code surfaces (terminal, VS Code, JetBrains, Desktop). Project instructions in ./CLAUDE.md persist across transitions without manual effort. Auto memory records learnings (build commands, debug insights, preferences) across sessions on its own (Claude Code docs: Memory).

Copilot reads .github/copilot-instructions.md and custom agent files across the IDE and GitHub surfaces, which gives you similar cross-surface persistence.

Session handoff commands

Claude Code provides explicit handoff commands for surface transitions (Claude Code docs):

Structured artifacts

Diffs, commit messages, progress files, and PR descriptions serve as handoff artifacts between sessions. Progress files and feature list specs give multi-session work structured continuity (Anthropic: Effective Harnesses).

Lightweight identifiers

Rather than pre-load full objects, keep file paths, queries, and links that each surface can load on demand. This "lightweight identifier" approach keeps context portable without bloating token budgets (Anthropic: Context Engineering).

Choosing the right surface

Signal Surface Reason
"What would this look like?" CLI Low-ceremony exploration, no commitment
"This needs to work correctly" IDE Precision editing, visual feedback
"Others need to see and review this" GitHub Durable artifacts, async collaboration
"This is mechanical and well-scoped" GitHub (agent) Autonomous execution, no human typing needed
"I started remotely, need local tools" CLI via --teleport Resume with full filesystem access

When this backfires

The three-surface model assumes context transfers with little friction. In practice, three conditions undermine it:

  1. Context does not survive the transition. If a CLI exploration session produces no structured artifact — no diff, no notes, no commit — the IDE session starts cold. The ladder degrades to a series of isolated sessions.
  2. Async GitHub iteration stalls the local loop. Handing tight feedback to @copilot or a GitHub Actions agent adds latency that local iteration would avoid. Reserve the GitHub surface for work where async is an advantage, not a workaround.
  3. Tool lock-in within a surface. The model assumes Claude Code and Copilot CLI are interchangeable at the CLI layer. In practice, they differ on file access scope, memory mechanisms, and available tools. Switching mid-task without re-establishing context costs as much as switching surfaces.

Key Takeaways

  • Match the AI surface to the development phase: exploration (CLI), refinement (IDE), collaboration (GitHub)
  • Context preservation mechanisms — instruction files, session handoff commands, structured artifacts — are what make the ladder work without losing state
  • The ladder is bidirectional: GitHub-to-CLI handoffs (--from-pr, --teleport) are as important as CLI-to-GitHub progressions
  • Diffs and plans generated at the CLI surface serve as concrete handoff artifacts for IDE refinement
  • The workflow respects existing developer behavior — terminal, editor, PR review — rather than replacing it

Example

A developer is asked to add a rate-limiting middleware to an existing API service.

CLI step: exploration and scaffolding

# Explore the codebase before touching anything
$ gh copilot explain "how does the current request pipeline work in src/server/"

# Scaffold a skeleton middleware file
$ gh copilot suggest "add express rate-limit middleware to src/server/middleware/"
# Review the generated diff, then execute
$ gh copilot diff | less

The CLI produces a diff and a short plan. Nothing is committed yet — these artifacts are the handoff to the IDE.

IDE step: refinement and implementation

Open the scaffolded file in VS Code. Copilot agent mode or Claude Code fills in the edge cases (per-user and per-IP limits, configurable window, test coverage). The developer reviews inline suggestions, adjusts the API surface, and runs the test suite from the integrated terminal. CLAUDE.md carries the project conventions (import style, error patterns) into this session automatically.

When the implementation is solid, the developer commits and pushes.

GitHub step: durable collaboration

The push opens a PR. CI runs lint and tests. A teammate leaves a review comment: "the window should be configurable per-route." The developer adds an @copilot comment on the PR asking it to apply the per-route config change. Copilot iterates in a GitHub Actions worker, pushes a fixup commit, and re-runs CI. The reviewer approves and merges.

The context handoff chain: CLI diff → IDE commit → GitHub PR → @copilot comment → merged PR.

Established — multiple independent sources Last reviewed: 2026-05-27
Feedback