conductor-new-track

sickn33/antigravity-awesome-skills · updated Apr 8, 2026

MDX-style export adds YAML metadata + attribution linking explainx.ai and this canonical listing URL.

$npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill conductor-new-track
0 commentsdiscussion
summary

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

skill.md

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

  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
**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. Create directory structure:

    conductor/tracks/{trackId}/
    ├── spec.md
    ├── plan.md
    ├── metadata.json
    └── index.md
    
  2. 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
      }
    }
    
  3. 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
    
  4. Register in conductor/tracks.md:

    • Add row to tracks table
    • Format: | [ ] | {trackId} | {title} | {created} | {created} |
  5. 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:
1. Review spec.md and plan.md, make any edits
2. Run /conductor:implement {trackId} to start implementation
3. 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
how to use conductor-new-track

How to use conductor-new-track on Cursor

AI-first code editor with Composer

1

Prerequisites

Before installing skills in Cursor, ensure your development environment meets these requirements:

  • Cursor installed and configured on your development machine
  • Node.js version 16.0+ with npm package manager (verify with node --version)
  • Active project directory or workspace where you want to add conductor-new-track
2

Execute installation command

Execute the skills CLI command in your project's root directory to begin installation:

$npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill conductor-new-track

The skills CLI fetches conductor-new-track from GitHub repository sickn33/antigravity-awesome-skills and configures it for Cursor.

3

Select Cursor when prompted

The CLI will show a list of available agents. Use arrow keys to navigate and space to select Cursor:

◆ Which agents do you want to install to?
│ ── Universal (.agents/skills) ── always included ────
│ • Amp
│ • Antigravity
│ • Cline
│ • Codex
│ ●Cursor(selected)
│ • Cursor
│ • Windsurf
4

Verify installation

Confirm successful installation by checking the skill directory location:

.cursor/skills/conductor-new-track

Reload or restart Cursor to activate conductor-new-track. Access the skill through slash commands (e.g., /conductor-new-track) or your agent's skill management interface.

Security & Verification Notice

We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.

Skills execute code in your development environment. Always verify the publisher's identity, review recent commits, and test in isolated environments before production deployment.

List & Monetize Your Skill

Submit your Claude Code skill and start earning

GET_STARTED →

Use Cases

User Story & Requirements Generation

Create detailed user stories, acceptance criteria, and feature specs

Example

Generate user stories for 'password reset feature' with acceptance criteria, edge cases, and test scenarios

Reduce spec writing time by 50%, ensure comprehensive coverage

Competitive Analysis

Research competitors, compare features, identify gaps

Example

Analyze 5 competitor products, create feature comparison matrix, suggest differentiation opportunities

Complete competitive research in 2 hours instead of 2 days

Roadmap Prioritization

Evaluate features using frameworks (RICE, ICE, Kano) and create prioritized backlogs

Example

Score 20 feature ideas using RICE framework, generate prioritized roadmap with rationale

Make data-driven prioritization decisions faster

Stakeholder Communication

Draft PRDs, status updates, and stakeholder presentations

Example

Create executive summary of Q3 roadmap, monthly progress report, feature launch announcement

Save 3-5 hours/week on communication overhead

Implementation Guide

Prerequisites

  • Claude Desktop or compatible AI client
  • Access to product documentation and roadmap tools (Jira, Notion, etc.)
  • Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
  • Stakeholder contact information and communication channels

Time Estimate

30-60 minutes to see productivity improvements

Installation Steps

  1. 1.Install product management skill
  2. 2.Start with user story generation for known feature
  3. 3.Progress to competitive analysis: research 2-3 competitors
  4. 4.Use for roadmap prioritization: apply RICE/ICE scoring
  5. 5.Draft stakeholder communications and refine based on feedback
  6. 6.Build template library for recurring PM tasks
  7. 7.Share effective prompts with product team

Common Pitfalls

  • Not validating competitive research—verify facts before sharing
  • Accepting user stories without involving engineering team
  • Over-relying on frameworks without qualitative judgment
  • Not customizing outputs to company culture and communication style
  • Skipping stakeholder validation of generated requirements

Best Practices

✓ Do

  • +Validate research and competitive analysis with real data
  • +Collaborate with engineering when generating technical requirements
  • +Customize frameworks and templates to your company context
  • +Use skill for first drafts, refine with stakeholder input
  • +Document successful prompt patterns for PM tasks
  • +Combine AI efficiency with human judgment and intuition

✗ Don't

  • Don't publish competitive analysis without fact-checking
  • Don't finalize user stories without engineering review
  • Don't make prioritization decisions solely on AI scoring
  • Don't skip customer validation of generated requirements
  • Don't ignore company-specific context and culture

💡 Pro Tips

  • Provide context: company goals, constraints, customer feedback
  • Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
  • Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
  • Use skill for 70% generation + 30% customization to company needs

When to Use This

✓ Use When

Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.

✗ Avoid When

Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.

Learning Path

  1. 1Basic: user stories, feature specs, status updates
  2. 2Intermediate: competitive analysis, prioritization frameworks, PRDs
  3. 3Advanced: product strategy, go-to-market planning, OKR setting
  4. 4Expert: product vision, market positioning, business model innovation

Discussion

Product Hunt–style comments (not star reviews)
  • No comments yet — start the thread.
general reviews

Ratings

4.643 reviews
  • Valentina Nasser· Dec 24, 2024

    conductor-new-track is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.

  • Dhruvi Jain· Dec 12, 2024

    Solid pick for teams standardizing on skills: conductor-new-track is focused, and the summary matches what you get after install.

  • Arjun Garcia· Dec 12, 2024

    Useful defaults in conductor-new-track — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.

  • Ava Robinson· Dec 8, 2024

    We added conductor-new-track from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.

  • Zara Mensah· Nov 27, 2024

    Solid pick for teams standardizing on skills: conductor-new-track is focused, and the summary matches what you get after install.

  • Oshnikdeep· Nov 3, 2024

    We added conductor-new-track from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.

  • Arjun Liu· Nov 3, 2024

    Registry listing for conductor-new-track matched our evaluation — installs cleanly and behaves as described in the markdown.

  • Ganesh Mohane· Oct 22, 2024

    conductor-new-track fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.

  • Hana Park· Oct 22, 2024

    conductor-new-track reduced setup friction for our internal harness; good balance of opinion and flexibility.

  • Tariq Garcia· Oct 18, 2024

    conductor-new-track has been reliable in day-to-day use. Documentation quality is above average for community skills.

showing 1-10 of 43

1 / 5