New Track

Create a new track (feature, bug fix, chore, or refactor) with a detailed specification and phased implementation plan.

Use this skill when

• Working on new track tasks or workflows
• Needing guidance, best practices, or checklists for new track

Do not use this skill when

• The task is unrelated to new track
• You need a different domain or tool outside this scope

Instructions

• Clarify goals, constraints, and required inputs.
• Apply relevant best practices and validate outcomes.
• Provide actionable steps and verification.

Pre-flight Checks

1. Verify Conductor is initialized:

   • Check conductor/product.md exists
   • Check conductor/tech-stack.md exists
   • Check conductor/workflow.md exists
   • If missing: Display error and suggest running /conductor:setup first

2. Load context files:

   • Read conductor/product.md for product context
   • Read conductor/tech-stack.md for technical context
   • Read conductor/workflow.md for TDD/commit preferences

Track Classification

Determine track type based on description or ask user:

What type of track is this?

1. Feature - New functionality
2. Bug - Fix for existing issue
3. Chore - Maintenance, dependencies, config
4. Refactor - Code improvement without behavior change

Interactive Specification Gathering

CRITICAL RULES:

• Ask ONE question per turn
• Wait for user response before proceeding
• Tailor questions based on track type
• Maximum 6 questions total

For Feature Tracks

Q1: Feature Summary

Describe the feature in 1-2 sentences.
[If argument provided, confirm: "You want to: {argument}. Is this correct?"]

Q2: User Story

Who benefits and how?

Format: As a [user type], I want to [action] so that [benefit].

Q3: Acceptance Criteria

What must be true for this feature to be complete?

List 3-5 acceptance criteria (one per line):

Q4: Dependencies

Does this depend on any existing code, APIs, or other tracks?

1. No dependencies
2. Depends on existing code (specify)
3. Depends on incomplete track (specify)

Q5: Scope Boundaries

What is explicitly OUT of scope for this track?
(Helps prevent scope creep)

Q6: Technical Considerations (optional)

Any specific technical approach or constraints?
(Press enter to skip)

For Bug Tracks

Q1: Bug Summary

What is broken?
[If argument provided, confirm]

Q2: Steps to Reproduce

How can this bug be reproduced?
List steps:

Q3: Expected vs Actual Behavior

What should happen vs what actually happens?

Q4: Affected Areas

What parts of the system are affected?

Q5: Root Cause Hypothesis (optional)

Any hypothesis about the cause?
(Press enter to skip)

For Chore/Refactor Tracks

Q1: Task Summary

What needs to be done?
[If argument provided, confirm]

Q2: Motivation

Why is this work needed?

Q3: Success Criteria

How will we know this is complete?

Q4: Risk Assessment

What could go wrong? Any risky changes?

Track ID Generation

Generate track ID in format: {shortname}_{YYYYMMDD}

• Extract shortname from feature/bug summary (2-3 words, lowercase, hyphenated)
• Use current date
• Example: user-auth_20250115, nav-bug_20250115

Validate uniqueness:

• Check conductor/tracks.md for existing IDs
• If collision, append counter: user-auth_20250115_2

Specification Generation

Create conductor/tracks/{trackId}/spec.md:

# Specification: {Track Title}

**Track ID:** {trackId}
**Type:** {Feature|Bug|Chore|Refactor}
**Created:** {YYYY-MM-DD}
**Status:** Draft

## Summary

{1-2 sentence summary}

## Context

{Product context from product.md relevant to this track}

## User Story (for features)

As a {user}, I want to {action} so that {benefit}.

## Problem Description (for bugs)

{Bug description, steps to reproduce}

## Acceptance Criteria

- [ ] {Criterion 1}
- [ ] {Criterion 2}
- [ ] {Criterion 3}

## Dependencies

{List dependencies or "None"}

## Out of Scope

{Explicit exclusions}

## Technical Notes

{Technical considerations or "None specified"}

---

_Generated by Conductor. Review and edit as needed._

User Review of Spec

Display the generated spec and ask:

Here is the specification I've generated:

{spec content}

Is this specification correct?
1. Yes, proceed to plan generation
2. No, let me edit (opens for inline edits)

…