conductor-new-track

Create a new track with specification and phased implementation plan

View Source
name:conductor-new-trackdescription:Create a new track with specification and phased implementation planmetadata: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.

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.

  • If detailed examples are required, open resources/implementation-playbook.md.
  • Pre-flight Checks

  • 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

  • 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?

  • Feature - New functionality

  • Bug - Fix for existing issue

  • Chore - Maintenance, dependencies, config

  • 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?

  • No dependencies

  • Depends on existing code (specify)

  • 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?

  • Yes, proceed to plan generation

  • No, let me edit (opens for inline edits)

  • 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
    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?

  • Yes, create the track

  • No, let me edit (opens for inline edits)

  • Add more phases/tasks

  • Start over
  • Track Creation

    After plan approval:

  • Create directory structure:
  • conductor/tracks/{trackId}/
    ├── spec.md
    ├── plan.md
    ├── metadata.json
    └── index.md

  • Create metadata.json:
  • {
    "id": "{trackId}",
    "title": "{Track Title}",
    "type": "feature|bug|chore|refactor",
    "status": "pending",
    "created": "ISO_TIMESTAMP",
    "updated": "ISO_TIMESTAMP",
    "phases": {
    "total": N,
    "completed": 0
    },
    "tasks": {
    "total": M,
    "completed": 0
    }
    }

  • Create index.md:
  • # Track: {Track Title}

    ID: {trackId}
    Status: Pending

    ## Documents

    - Specification
    - Implementation Plan

    ## Progress

    - Phases: 0/{N} complete
    - Tasks: 0/{M} complete

    ## Quick Links

    - Back to Tracks
    - Product Context

  • Register in conductor/tracks.md:

  • - Add row to tracks table
    - Format: | [ ] | {trackId} | {title} | {created} | {created} |

  • Update conductor/index.md:

  • - Add track to "Active Tracks" section

    Completion Message

    Track created successfully!

    Track ID: {trackId}
    Location: conductor/tracks/{trackId}/

    Files created:

  • spec.md - Requirements specification

  • plan.md - Phased implementation plan

  • metadata.json - Track metadata

  • index.md - Track navigation
  • Next steps:

  • Review spec.md and plan.md, make any edits

  • Run /conductor:implement {trackId} to start implementation

  • Run /conductor:status to see project progress
  • Error Handling

  • If directory creation fails: Halt and report, do not register in tracks.md

  • If any file write fails: Clean up partial track, report error

  • If tracks.md update fails: Warn user to manually register track