conductor-new-track
Create a new track with specification and phased implementation plan
Documentation
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.mdexists - Check
conductor/tech-stack.mdexists - Check
conductor/workflow.mdexists - If missing: Display error and suggest running
/conductor:setupfirst
- Check
-
Load context files:
- Read
conductor/product.mdfor product context - Read
conductor/tech-stack.mdfor technical context - Read
conductor/workflow.mdfor TDD/commit preferences
- Read
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.mdfor 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}
### Ta
Quick Info
- Source
- antigravity
- Category
- Document Processing
- Repository
- View Repo
- Scraped At
- Jan 29, 2026
Tags
Related Skills
ab-test-setup
Structured guide for setting up A/B tests with mandatory gates for hypothesis, metrics, and execution readiness.
airflow-dag-patterns
Build production Apache Airflow DAGs with best practices for operators, sensors, testing, and deployment. Use when creating data pipelines, orchestrating workflows, or scheduling batch jobs.
algorithmic-art
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.