/new-track

description: "Create a new track with specification and phased implementation plan"
argument-hint: "<feature|bug|chore|refactor> <name>"

New Track

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

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)
3. Start over with different inputs

Plan Generation

After spec approval, generate `conductor/tracks/{trackId}/plan.md`:

Plan Structure

# Implementation Plan: {Track Title}

**Track ID:** {trackId}
**Spec:** [spec.md](./spec.md)
**Created:** {YYYY-MM-DD}
**Status:** [ ] Not Started

## Overview

{Brief summary of implementation approach}

## Phase 1: {Phase Name}

{Phase description}

### Tasks

- [ ] Task 1.1: {Description}
- [ ] Task 1.2: {Description}
- [ ] Task 1.3: {Description}

### Verification

- [ ] {Verification step for phase 1}

## Phase 2: {Phase Name}

{Phase description}

### Tasks

- [ ] Task 2.1: {Description}
- [ ] Task 2.2: {Description}

### Verification

- [ ] {Verification step for phase 2}

## Phase 3: {Phase Name} (if needed)

...

## Final Verification

- [ ] All acceptance criteria met
- [ ] Tests passing
- [ ] Documentation updated (if applicable)
- [ ] Ready for review

---

_Generated by Conductor. Tasks will be marked [~] in progress and [x] complete._

Phase Guidelines

• Group related tasks into logical phases
• Each phase should be independently verifiable
• Include verification task after each phase
• TDD tracks: Include test writing tasks before implementation tasks
• Typical structure:

1. **Setup/Foundation** - Initial scaffolding, interfaces 2. **Core Implementation** - Main functionality 3. **Integration** - Connect with existing system 4. **Polish** - Error handling, edge cases, docs

User Review of Plan

Display the generated plan and ask:

Here is the implementation plan:

{plan content}

Is this plan correct?
1. Yes, create the track
2. No, let me edit (opens for inline edits)
3. Add more phases/tasks
4. Start over

Track Creation

After plan approval:

1.