// Context-driven development methodology. Understands projects set up with Conductor (via Gemini CLI or Claude Code). Use when working with conductor/ directories, tracks, specs, plans, or when user mentions context-driven development.
| name | conductor |
| description | Context-driven development methodology. Understands projects set up with Conductor (via Gemini CLI or Claude Code). Use when working with conductor/ directories, tracks, specs, plans, or when user mentions context-driven development. |
| license | Apache-2.0 |
| compatibility | Works with Claude Code, Gemini CLI, and any Agent Skills compatible CLI |
| metadata | {"version":"0.1.0","author":"Gemini CLI Extensions","repository":"https://github.com/gemini-cli-extensions/conductor","keywords":["context-driven-development","specs","plans","tracks","tdd","workflow"]} |
Measure twice, code once.
Conductor enables context-driven development by:
Interoperability: This skill understands conductor projects created by either:
/conductor:setup, /conductor:newTrack, etc.)/conductor-setup, /conductor-newtrack, etc.)Both tools use the same conductor/ directory structure.
Automatically engage when:
conductor/ directoryconductor/tracks.md, conductor/product.md existUsers can invoke these commands directly:
| Command | Description |
|---|---|
/conductor-setup | Initialize project with product.md, tech-stack.md, workflow.md |
/conductor-newtrack [desc] | Create new feature/bug track with spec and plan |
/conductor-implement [id] | Execute tasks from track's plan |
/conductor-status | Display progress overview |
/conductor-revert | Git-aware revert of work |
When you see this structure, the project uses Conductor:
conductor/
âââ product.md # Product vision, users, goals
âââ product-guidelines.md # Brand/style guidelines (optional)
âââ tech-stack.md # Technology choices
âââ workflow.md # Development standards (TDD, commits, coverage)
âââ tracks.md # Master track list with status markers
âââ setup_state.json # Setup progress tracking
âââ code_styleguides/ # Language-specific style guides
âââ tracks/
âââ <track_id>/ # Format: shortname_YYYYMMDD
âââ metadata.json # Track type, status, dates
âââ spec.md # Requirements and acceptance criteria
âââ plan.md # Phased task list with status
Throughout conductor files:
[ ] - Pending/New[~] - In Progress[x] - Completed (often followed by 7-char commit SHA)When working in a Conductor project:
conductor/product.md - Understand what we're building and for whomconductor/tech-stack.md - Know the technologies and constraintsconductor/workflow.md - Follow the development methodology (usually TDD)conductor/tracks.md - See all work items and their statusspec.md and plan.mdWhen implementing tasks, follow conductor/workflow.md which typically specifies:
feat:, fix:, test:, etc.)[~] when starting, [x] when done + commit SHAProjects set up with Gemini CLI's Conductor extension use identical structure. The only differences are command syntax:
| Gemini CLI | Claude Code |
|---|---|
/conductor:setup | /conductor-setup |
/conductor:newTrack | /conductor-newtrack |
/conductor:implement | /conductor-implement |
/conductor:status | /conductor-status |
/conductor:revert | /conductor-revert |
Files, workflows, and state management are fully compatible.
When you see conductor/tracks.md with content like:
## [~] Track: Add user authentication
*Link: [conductor/tracks/auth_20241215/](conductor/tracks/auth_20241215/)*
You know:
conductor/tracks/auth_20241215/conductor/workflow.mdFor detailed workflow documentation, see references/workflows.md.