Conductor New Track

新轨道

创建新轨道（功能、bug 修复、维护任务或重构），包含详细的规格说明和分阶段实施计划。

何时使用此技能

• 处理新轨道任务或工作流时
• 需要新轨道相关的指导、最佳实践或检查清单时

何时不使用此技能

• 任务与新轨道无关
• 需要此范围之外的其他领域或工具

指令

• 明确目标、约束和所需输入。
• 应用相关最佳实践并验证结果。
• 提供可执行的步骤和验证方法。
• 如需详细示例，打开 resources/implementation-playbook.md。

预检查

1. 验证 Conductor 已初始化：

   • 检查 conductor/product.md 是否存在
   • 检查 conductor/tech-stack.md 是否存在
   • 检查 conductor/workflow.md 是否存在
   • 若缺失：显示错误并建议先运行 /conductor:setup

2. 加载上下文文件：

   • 读取 conductor/product.md 获取产品上下文
   • 读取 conductor/tech-stack.md 获取技术上下文
   • 读取 conductor/workflow.md 获取 TDD/提交偏好

轨道分类

根据描述确定轨道类型，或询问用户：

这是什么类型的轨道？

1. Feature - 新功能
2. Bug - 修复现有问题
3. Chore - 维护、依赖、配置
4. Refactor - 不改变行为的代码改进

交互式规格收集

关键规则：

• 每轮只问一个问题
• 等待用户回复后再继续
• 根据轨道类型定制问题
• 最多 6 个问题

功能轨道

Q1: 功能摘要

用 1-2 句话描述该功能。
[若已提供参数，确认："您想要：{参数}。是否正确？"]

Q2: 用户故事

谁受益？如何受益？

格式：作为 [用户类型]，我想要 [操作]，以便 [收益]。

Q3: 验收标准

该功能完成时必须满足什么条件？

列出 3-5 条验收标准（每行一条）：

Q4: 依赖项

这是否依赖任何现有代码、API 或其他轨道？

1. 无依赖
2. 依赖现有代码（请说明）
3. 依赖未完成的轨道（请说明）

Q5: 范围边界

此轨道明确排除哪些内容？
（有助于防止范围蔓延）

Q6: 技术考量（可选）

是否有特定的技术方案或约束？
（按回车跳过）

Bug 轨道

Q1: Bug 摘要

什么坏了？
[若已提供参数，确认]

Q2: 复现步骤

如何复现此 bug？
列出步骤：

Q3: 预期行为 vs 实际行为

应该发生什么 vs 实际发生了什么？

Q4: 受影响区域

系统的哪些部分受到影响？

Q5: 根因假设（可选）

对原因有何假设？
（按回车跳过）

维护/重构轨道

Q1: 任务摘要

需要做什么？
[若已提供参数，确认]

Q2: 动机

为什么需要这项工作？

Q3: 成功标准

如何判断已完成？

Q4: 风险评估

可能出什么问题？有风险的变更吗？

轨道 ID 生成

按格式生成轨道 ID：{简称}_{YYYYMMDD}

• 从功能/bug 摘要提取简称（2-3 个单词，小写，连字符连接）
• 使用当前日期
• 示例：user-auth_20250115、nav-bug_20250115

验证唯一性：

• 检查 conductor/tracks.md 中是否存在相同 ID
• 若冲突，追加计数器：user-auth_20250115_2

规格说明生成

创建 conductor/tracks/{trackId}/spec.md：

# 规格说明：{轨道标题}

**轨道 ID：** {trackId}
**类型：** {Feature|Bug|Chore|Refactor}
**创建日期：** {YYYY-MM-DD}
**状态：** 草稿

## 摘要

{1-2 句摘要}

## 背景

{product.md 中与此轨道相关的产品上下文}

## 用户故事（功能类）

作为 {用户}，我想要 {操作}，以便 {收益}。

## 问题描述（Bug 类）

{Bug 描述，复现步骤}

## 验收标准

- [ ] {标准 1}
- [ ] {标准 2}
- [ ] {标准 3}

## 依赖项

{列出依赖项或"无"}

## 范围外

{明确排除的内容}

## 技术备注

{技术考量或"未指定"}

---

_由 Conductor 生成。请根据需要审核和编辑。_

用户审核规格

显示生成的规格并询问：

这是我生成的规格说明：

{规格内容}

此规格说明是否正确？
1. 是，继续生成计划
2. 否，让我编辑（打开内联编辑）
3. 用不同输入重新开始

计划生成

规格批准后，生成 conductor/tracks/{trackId}/plan.md：

计划结构

# 实施计划：{轨道标题}

**轨道 ID：** {trackId}
**规格：** spec.md
**创建日期：** {YYYY-MM-DD}
**状态：** [ ] 未开始

## 概述

{实施方案简要摘要}

## 阶段 1：{阶段名称}

{阶段描述}

### 任务

- [ ] 任务 1.1：{描述}
- [ ] 任务 1.2：{描述}
- [ ] 任务 1.3：{描述}

### 验证

- [ ] {阶段 1 的验证步骤}

## 阶段 2：{阶段名称}

{阶段描述}

### 任务

- [ ] 任务 2.1：{描述}
- [ ] 任务 2.2：{描述}

### 验证

- [ ] {阶段 2 的验证步骤}

## 阶段 3：{阶段名称}（如需要）

...

## 最终验证

- [ ] 所有验收标准已满足
- [ ] 测试通过
- [ ] 文档已更新（如适用）
- [ ] 准备好审核

---

_由 Conductor 生成。任务将标记为 [~] 进行中和 [x] 已完成。_

阶段指南

• 将相关任务分组到逻辑阶段
• 每个阶段应可独立验证
• 每个阶段后包含验证任务
• TDD 轨道：在实现任务前包含测试编写任务
• 典型结构：
  1. 搭建/基础 - 初始脚手架、接口
  2. 核心实现 - 主要功能
  3. 集成 - 与现有系统连接
  4. 完善 - 错误处理、边界情况、文档

用户审核计划

显示生成的计划并询问：

这是实施计划：

{计划内容}

此计划是否正确？
1. 是，创建轨道
2. 否，让我编辑（打开内联编辑）
3. 添加更多阶段/任务
4. 重新开始

轨道创建

计划批准后：

1. 创建目录结构：

   conductor/tracks/{trackId}/
   ├── spec.md
   ├── plan.md
   ├── metadata.json
   └── index.md
   

2. 创建 metadata.json：

   {
     "id": "{trackId}",
     "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. 创建 index.md：

   # 轨道：{轨道标题}
   
   **ID：** {trackId}
   **状态：** 待处理
   
   ## 文档
   
   - 规格说明
   - 实施计划
   
   ## 进度
   
   - 阶段：0/{N} 已完成
   - 任务：0/{M} 已完成
   
   ## 快速链接
   
   - 返回轨道列表
   - 产品上下文
   

4. 在 conductor/tracks.md 中注册：

   • 在轨道表格中添加行
   • 格式：| [ ] | {trackId} | {标题} | {创建日期} | {创建日期} |

5. 更新 conductor/index.md：

   • 在"活跃轨道"部分添加轨道

完成消息

轨道创建成功！

轨道 ID：{trackId}
位置：conductor/tracks/{trackId}/

已创建文件：
- spec.md - 需求规格说明
- plan.md - 分阶段实施计划
- metadata.json - 轨道元数据
- index.md - 轨道导航

下一步：
1. 审核 spec.md 和 plan.md，进行任何编辑
2. 运行 /conductor:implement {trackId} 开始实施
3. 运行 /conductor:status 查看项目进度

错误处理

• 若目录创建失败：停止并报告，不在 tracks.md 中注册
• 若任何文件写入失败：清理部分轨道，报告错误
• 若 tracks.md 更新失败：警告用户手动注册轨道