Conductor Development Skill
conductor-development
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...
SKILL.md
Full skill instructions
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
