conductor-new-track
Create a new track with specification and phased implementation plan
它会碰到什么
这一栏是扫描器报的事实,不是结论。命中多不等于有毒(安全工具、规则库、示例脚本本来就会包含危险写法),命中少也不等于干净。它和你手上的凭据、文件、网络有什么关系,需要你自己看。
技能内容
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
- Load context files:
- Read
conductor/product.mdfor product context - Read
conductor/tech-stack.mdfor technical context - Read
conductor/workflow.mdfor 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.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
**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:
- Setup/Foundation - Initial scaffolding, interfaces
- Core Implementation - Main functionality
- Integration - Connect with existing system
- 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:
- 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:
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
想直接用这个技能?
本站把开放许可(MIT / Apache 等)的技能按仓库打包整理到网盘,点一下转存到你自己的网盘,不用一个个从 GitHub 拉。许可未声明的技能只给原始仓库链接,不打包。
它属于哪个仓库
plugins/agentic-awesome-skills/skills/conductor-new-track/SKILL.md同一个仓库里的其他技能
同名技能的其他版本
有 3 个不同仓库或目录里都有叫 conductor-new-track 的技能。它们内容并不相同,别混用:
- sickn33/agentic-awesome-skills — Create a new track with specification and phased implementation plan
- sickn33/agentic-awesome-skills — Create a new track with specification and phased implementation plan