Conductor for Gemini CLI: Context-Driven Development That Scales
How Conductor turns AI coding into specs, plans, and repeatable execution.
The biggest reason agentic coding fails in real projects isn’t model intelligence. It’s missing context.
Most teams have the information the agent needs—architecture decisions, style conventions, test strategy, product goals—but it’s scattered across tribal knowledge and ephemeral chat. That makes work inconsistent and makes onboarding (humans or agents) expensive.
Google’s Conductor extension for Gemini CLI is a direct response to that problem: it treats “project context” as a first-class artifact that lives in the repo, not in a one-off conversation.
https://developers.googleblog.com/conductor-introducing-context-driven-development-for-gemini-cli/
The Core Idea
From first principles, a team ships reliable software when three things are stable:
- Shared intent (what are we building and why)
- Shared constraints (tech stack, style, security, workflow)
- Shared verification (how we know it works)
Conductor’s insight is that agents perform best when those are written down in durable form, and updated over time.
Instead of asking a model to “remember” your preferences, Conductor makes the repository itself the memory.
What Conductor Is
Conductor is a Gemini CLI extension that runs a structured workflow for larger tasks than “edit this file.”
The workflow is intentionally staged:
- Establish project context
- Create a spec and a plan for a unit of work (“track”)
- Implement the plan while tracking progress in the repo
Google describes this as “context-driven development,” emphasizing formal specs and plans stored as Markdown files alongside your code.
https://developers.googleblog.com/conductor-introducing-context-driven-development-for-gemini-cli/
The extension itself is open source and available as a Gemini CLI extension.
https://github.com/gemini-cli-extensions/conductor
Why This Works (And Why It’s Different Than Chat)
Chat-based agent workflows fail for predictable reasons:
- The “spec” is ambiguous and buried in scrollback.
- Constraints get forgotten mid-implementation.
- The agent optimizes for “looks done,” not “provably correct.”
- Different developers get different outputs because they prompt differently.
Conductor fixes this by making the plan explicit and reviewable before code is written. That’s not process for process’s sake—it's a control surface.
When you can review the plan, you can catch the two most expensive classes of mistakes early:
- building the wrong thing
- building the right thing the wrong way
Conductor’s Building Blocks
Conductor introduces a few durable artifacts (stored in the repo) so the project has a persistent “source of truth.”
Project context
The setup flow helps you define:
- product context and goals
- tech stack and architectural preferences
- workflow preferences (e.g., how to test, how to structure commits)
Google’s write-up frames this as a way to keep the human “in the driver’s seat” by formalizing intent instead of relying on chat memory.
https://developers.googleblog.com/conductor-introducing-context-driven-development-for-gemini-cli/
Tracks
A track is Conductor’s unit of work. It includes:
- a spec (requirements)
- a plan (phases / tasks)
- status updates as work progresses
The open-source repository documents this “Context → Spec & Plan → Implement” lifecycle.
https://github.com/gemini-cli-extensions/conductor
When You Should Use It
Conductor makes the most sense when:
- you’re working in an established codebase (brownfield)
- the work spans multiple files or systems
- you need consistent outputs across a team
- you care about repeatability and reviewability
For tiny changes, raw CLI prompting is faster. For anything that looks like a feature, a refactor, or a migration, structure pays for itself.
What OutcomeDev Takes From This
We think Conductor is directionally correct because it matches a deeper truth: agents are powerful, but uncontrolled agents create uncontrolled codebases.
The way out is not “better prompting.” It’s better artifacts:
- specs that survive the session
- plans that can be reviewed
- verification that produces evidence
That’s the same philosophy OutcomeDev is built around: tight intent, explicit constraints, and proof.
Sources
- Google Developers Blog: Conductor for Gemini CLI — https://developers.googleblog.com/conductor-introducing-context-driven-development-for-gemini-cli/
- Conductor extension repository — https://github.com/gemini-cli-extensions/conductor