| name | conductor-development |
| description | Context-Driven Development skill for projects using Conductor. Use this skill when you detect a `conductor/` directory in the project, when working on tasks defined in a `plan.md` file, or when the user asks about tracks, specs, or plans. Automatically applies TDD workflow, tracks task completion, and follows the spec-driven methodology. |
Conductor Development Skill
This skill enables Claude to work effectively on projects managed by the Conductor framework - a spec-driven, structured development methodology.
When This Skill Activates
Claude should automatically apply this skill when:
- A
conductor/directory exists in the project root - The user mentions "tracks", "conductor", "spec", or "plan" in the context of development
- Files like
conductor/tracks.md,conductor/workflow.md, orconductor/product.mdare present - The user runs any
/conductor:*command
Core Principles
- The Plan is the Source of Truth: All work must be tracked in
plan.md - Spec-Driven Development: Understand the spec before implementing
- Test-Driven Development: Write tests before implementation (Red-Green-Refactor)
- High Code Coverage: Target >80% code coverage for all modules
- Track Progress: Update task status markers (
[ ]→[~]→[x])
Project Structure Understanding
When working on a Conductor project, familiarize yourself with:
conductor/
├── product.md # Product vision and goals
├── product-guidelines.md # Brand voice and communication style
├── tech-stack.md # Technology choices and constraints
├── workflow.md # Development methodology and procedures
├── tracks.md # Master list of all tracks
├── code_styleguides/ # Language-specific style guides
│ ├── general.md
│ ├── python.md
│ └── [others]
└── tracks/ # Individual track folders
└── <track_id>/
├── spec.md # Feature specification
├── plan.md # Implementation plan with tasks
└── metadata.json # Track metadata
Task Execution Protocol
When implementing a task from a Conductor plan:
1. Select and Mark Task
- Find the next pending task (marked
[ ]) in the track'splan.md - Update its status to in-progress:
[~]
2. Follow TDD Workflow
- Red Phase: Write failing tests that define expected behavior
- Green Phase: Write minimal code to make tests pass
- Refactor: Improve code while keeping tests green
3. Complete the Task
- Verify test coverage (>80%)
- Follow code style guidelines from
conductor/code_styleguides/ - Commit with semantic message (e.g.,
feat(auth): Add login form) - Mark task complete:
[x]and append commit SHA - Commit the plan update:
conductor(plan): Mark task 'X' as complete
4. Phase Completion
When completing a phase:
- Run full test suite
- Provide manual verification steps to user
- Create checkpoint commit with verification report
- Update
plan.mdwith checkpoint SHA
Status Markers
[ ]- Pending (not started)[~]- In Progress (currently working)[x]- Completed (done with commit SHA)
Available Commands
Remind users of available Conductor commands:
/conductor:setup- Initialize Conductor in a project/conductor:new-track- Create a new feature/bug track/conductor:implement- Execute tasks from the current track/conductor:status- Show project progress/conductor:revert- Git-aware revert of tracks/phases/tasks
Context Loading
Before starting any implementation work, always load:
conductor/workflow.md- For task lifecycle proceduresconductor/tech-stack.md- For technology constraints- The active track's
spec.md- For requirements - The active track's
plan.md- For current task status
Git Integration
Conductor tracks work through Git:
- Each task completion = one code commit + one plan commit
- Phase checkpoints create special commits with git notes
- SHAs are recorded in
plan.mdfor traceability - Use semantic commit messages following the project's conventions
Error Handling
If something goes wrong:
- Do not proceed without user confirmation
- Announce the failure clearly
- Suggest recovery options (e.g.,
/conductor:revert) - Wait for user instructions
Quality Gates
Before marking any task complete, verify:
- All tests pass
- Code coverage meets requirements (>80%)
- Code follows project's style guidelines
- Public functions are documented
- No linting errors
- No security vulnerabilities introduced