| name | conductor |
| description | Context-driven development with spec-driven workflows, TDD-based task execution, track management, and phase checkpointing |
Conductor
Overview
Conductor is a context-driven development framework that treats context as a managed artifact alongside code. It follows the "measure twice, code once" philosophy through spec-driven workflows.
Quick Start
Setup your project:
/conductor-setupCreate a new track:
/conductor-newtrack "Add user authentication"Implement the track:
/conductor-implement
Core Concepts
Tracks
A track is a high-level unit of work (feature, bug fix, chore) that contains:
spec.md- Requirements and specificationsplan.md- Implementation tasks organized in phasesmetadata.json- Track status and metadata
Workflow
Conductor follows a Test-Driven Development (TDD) workflow:
- Write tests first
- Implement features to pass tests
- Commit changes after each task
- Use git notes for task summaries
Project Context
The conductor/ directory contains:
product.md- Project goals, users, featuresproduct-guidelines.md- Brand, voice, visual identitytech-stack.md- Languages, frameworks, databasesworkflow.md- Development methodology (TDD)tracks.md- Master list of all tracks
Commands
/conductor-setup
Initializes the Conductor environment for your project. Creates the conductor/ directory and guides you through:
- Project discovery (greenfield vs brownfield)
- Product definition (goals, users, features)
- Technology stack selection
- Code style guide selection
- Workflow customization
/conductor-newtrack
Creates a new track with spec and plan documents.
Usage:
/conductor-newtrack "Add user authentication"
The command will:
- Ask for track description (if not provided)
- Generate spec.md through interactive questions
- Create plan.md with phased tasks
- Create track directory with all artifacts
/conductor-implement
Executes the current track tasks following the workflow.md protocol.
Usage:
/conductor-implement
The command will:
- Select the current track
- Execute tasks in order
- Follow TDD workflow (tests first)
- Commit after each task
- Attach git notes for summaries
/conductor-status
Displays the current track status and progress.
Usage:
/conductor-status
/conductor-revert
Reverts tracks, phases, or tasks using git history.
Usage:
/conductor-revert
File Structure
conductor/
├── product.md # Project goals, users, features
├── product-guidelines.md # Brand, voice, visual identity
├── tech-stack.md # Languages, frameworks, databases
├── workflow.md # Development methodology (TDD)
├── tracks.md # Master list of all tracks
├── setup_state.json # Setup progress tracking
├── code_styleguides/ # Language-specific style guides
└── tracks/
└── <track_id>/
├── spec.md # Requirements
├── plan.md # Implementation tasks
└── metadata.json # Track status
Templates
This skill includes templates for:
workflow.md- TDD workflow templatecode_styleguides/- Language-specific style guides
See the templates/ directory in this skill for more details.
Best Practices
- Always use /conductor-setup first - Initializes your project properly
- Create one track at a time - Focus on completing tracks before starting new ones
- Follow the workflow - The TDD workflow ensures code quality
- Review specs before implementing - Good specs lead to good implementations
- Commit frequently - Small commits make reverts easier
Migration from Gemini CLI
If you're migrating from the Gemini CLI Conductor extension:
- Your existing
conductor/directory is fully compatible - The commands work identically (just with different names)
- All artifacts (specs, plans, tracks) remain the same
Support
For issues or questions about Conductor, refer to:
- Project documentation in this skill
- The original Conductor extension documentation