epic-tracker

Epic Tracker

在外部跟踪系统中管理交付生命周期。规划 Epic、跟踪 Story 并报告 Bug——所有工件都保存在 Linear 或 GitHub 中，它们是唯一可信的数据来源。

触发条件

• 功能来源（“根据这份功能设计文档创建”“根据这份功能 PRD 创建”“将这份功能设计文档转换为问题”“跟踪此功能”）→ feature.md
• 规划 / 分解（“创建路线图”“规划路线图”“组织 Epic”“根据 PRD 制定路线图”“分解”“拆解路线图”“将此 Epic 拆分为 Story”“根据路线图创建 Epic”）→ decompose.md
• Epic（“创建 Epic”“新建 Epic”“编辑 Epic”）→ epic.md
• Story（“创建 Story”“新建 Story”“添加 Story”“编辑 Story”“更新 Story”“更改 Story”“创建任务”“创建杂项任务”）→ story.md
• Bug（“创建 Bug”“报告 Bug”“Bug 报告”“编辑 Bug”）→ bug.md
• 状态 / 概览（“标记为已完成”“取消此项”“不予修复”“列出 Epic”“正在进行什么”“更新状态”）→ sync.md
• 更改父级（“将此项移到 Epic X”“更改此 Story 的父级”“更改父 Epic”）→ sync.md
• 依赖关系（“将此项设为依赖于 X”“解除此项的阻塞”“此项依赖于 X”）→ sync.md

工作流

flowchart TD
    DE[decompose] -->|plan| CR[create ref]
    FE[feature] -->|size| CR
    UR[user request] --> CR
    CR --> out[the tracker]

每个工件都遵循相同的流程：创建引用会起草工件并将其发送到跟踪系统。decompose 根据项目 PRD 推导计划，在聊天中将计划显示为草稿，并在用户批准后创建 Epic。当用户要求提供路线图文件时，它会在获得批准后写入 docs/product/ROADMAP.md；如果用户只要求路线图，则只提供路线图，不创建任何内容。feature 会将功能 PRD 或功能设计文档细化为 Epic 或独立 Story，在聊天中将其显示为草稿，并在用户批准后创建，且不会编写路线图。用户的请求会直接进入创建引用，不进行推导。执行跟踪系统操作必须配置跟踪系统；如果缺少访问权限，请报告此情况，不要配置集成。