mcpField
A
agile-epic

agile-epic

github.com/djalmajr开发4127 次安装5 周前更新
代码仓库

关于 agile-epic

将需求收集、路线图或大型计划整理为 Epic，并拆分为可独立执行的故事。它明确依赖关系、验收标准、风险及交付路线图。

主要功能

  1. 01将计划拆分为故事
  2. 02梳理依赖关系与交付顺序
  3. 03定义验收标准和风险
  4. 04生成 Epic 与故事文件
  5. 05规划并行工作轨道

适用场景

  1. 01需求收集后梳理大型计划
  2. 02安排存在依赖的故事顺序
  3. 03规划交付阶段和验证里程碑
  4. 04为多名开发者准备并行轨道

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/djalmajr/skills --skill agile-epic

安装后在 Claude Code 中输入/agile-epic确认已加载。

附带文件templates/epic.md

详细介绍

Epic

使用此技能，可将需求收集、路线图或大型计划转化为结构化 Epic，并拆解为故事、路线图和验收标准。

通过斜杠命令收到的初始上下文：$ARGUMENTS

如果 $ARGUMENTS 不为空（例如需求收集文件路径、描述或计划名称），请以此为起点。 如果为空，请询问要构建哪个计划的结构。

语言

使用用户的语言撰写文档。遵循正确的语法，并使用任何必需的变音符号或特定文字字符。如果不确定用户使用哪种语言，请先询问，再生成输出。模板为英文，请翻译标题和内容以保持一致。

项目根目录

此技能会在相对于项目根目录（工作所在的仓库）的路径下写入文档，而不是相对于 Agent 当前的工作目录。

  • 如果从项目内部调用，请使用此技能中显示的相对路径。
  • 如果从其他目录调用（例如相邻仓库，或项目位于其他位置），请在每个文档路径前添加 <project-root>/。
  • 如果项目根目录不明确，请通过 harness 的提问工具向用户确认，再进行写入。

提问

遵循项目范围内的 CLAUDE.md / AGENTS.md 约定（“Skill Prompting Conventions”）。在以下决策点使用 harness 的结构化提问工具——AskUserQuestion（Claude Code）、ask_user_question（Codex）或 question（OpenCode）。

决策点使用结构化提问的原因建议选项
用户提供的路径与约定冲突时的保存路径写入后难以撤销使用约定 · 遵循用户路径 · 询问
路线图图表类型会影响模板适配Mermaid 流程图 · Mermaid 甘特图
通过 /agile-story 优先详细描述哪个故事会影响后续技能按依赖关系排序 · 选择

自由文本提示（不使用结构化工具）：

  • 故事名称（kebab-case）
  • Epic 标题和成果措辞

无暂停模式：如果用户明确禁用了技能执行过程中的澄清，请将每个结构化提问转换为“待解决问题”（或同类部分）中的条目，并继续执行，不要暂停。

目标

  • 将大型计划拆解为适量且可执行的故事
  • 构建包含依赖关系和顺序的故事待办列表
  • 定义 Epic 路线图（阶段、解除阻碍的事项、中间验证）
  • 确保每个故事都可以单独规划和执行
  • 生成指导执行的文档，但不取代各个任务计划

适用场景

  • /agile-intake 或 /agile-roadmap 识别出大型计划之后
  • 计划需要多个相互协调的故事时
  • 交付之间存在依赖关系，需要安排顺序时
  • 需要路线图来指导交付顺序时
  • 中大型工作需要比简单的 /agile-story 更丰富的结构时

不适用场景

  • 工作范围较小且局部——直接使用 /agile-story
  • 问题尚未记录——先使用 /agile-intake
  • 需要战略方向——先使用 /agile-roadmap
  • 需要验证现有文档——使用 /agile-refinement

流程

1. 分析上下文

阅读需求收集、路线图或所提供的材料。识别以下内容：

  • 宏观问题和目标
  • 受影响的领域
  • 约束和前提
  • 预估范围和复杂度
  • 当 UI / 产品流程相关时，检查 planning/<initiative>/proto/ 下的现有原型
  • 当领域行为相关时，检查 planning/<initiative>/business/*.md 下的现有业务规则

如果计划涉及大量 UI，且原型已约定为前置关卡，则在相关原型路线或屏幕完成，或用户明确豁免该关卡之前，不要敲定 Epic。

2. 拆分为故事

按纵向价值切片拆分，而不是按技术层拆分：

  • 每个故事都必须交付可观察到的成果
  • 尽可能优先拆分为彼此独立的故事
  • 明确故事之间的依赖关系（什么会解除什么的阻塞）

为每个故事定义：

  • 名称和目标（1 行）
  • 预估范围（小、中或大）
  • 依赖项（依赖哪些故事）
  • 涉及的原型路由/屏幕（如适用）
  • 涉及的业务规则 ID/文件（如适用）
  • 汇总后的验收标准
3. 组织 Epic 概览

填写必需的章节：

  • 背景： 问题、现状、目标状态、不在范围内的内容
  • 故事待办列表： 列出每个故事的目标、规模和依赖项
  • 路线图： 阶段/冲刺、解除阻塞的关系、中间验证
  • 风险： 可能出现的问题及缓解方法
  • Epic 验收标准： 如何判断此项计划已完成
4. 定义路线图
  • 按阶段/冲刺对故事分组
  • 展示哪些工作可以并行开展
  • 标出关键路径
  • 包含中间验证（里程碑）
5. 考虑协作工作

团队有 2 名或更多开发者时：

  • 确定并行工作轨道，以便开发者同时开展工作
  • 定义轨道之间的接口契约（类型、架构、API），尽量减少阻塞
  • 尽可能为轨道分配故事
  • 使用 Mermaid gantt 图展示各轨道上的并行工作
6. 生成文件

Epic 会生成多个文件：

planning/<initiative>/epics/NN-<epic-name>/
├── 00-overview.md         (the epic overview: context, backlog, roadmap, risks)
├── 01-story-name.md       (first story: context + tasks inline)
├── 02-story-name.md       (second story: context + tasks inline)
└── ...
  • 00-overview.md 包含 Epic 级别的背景、故事待办列表摘要、路线图、风险和验收标准。
  • 每个 NN-story-name.md 包含故事背景、验收标准、文件、任务和验证——全部放在一个文件中。

NN 是补零后的顺序编号。每个 Epic 都有自己的文件夹，位于 epics/ 下。

保存位置

  • Epic 文件夹：planning/<initiative>/epics/NN-<epic-name>/
  • 如果 planning/ 下没有对应计划的文件夹，请向用户询问名称
  • 路径冲突关卡： 如果用户提供的保存路径不符合上述约定（例如，使用 planning/<initiative>/<epic-name>/ 而不是 epics/NN-<epic-name>/ 这种结构），请在写入前指出冲突。只有在用户明确确认后才使用用户提供的路径；否则采用约定路径并告知用户原因。使用运行环境的提问工具（参见 ## Prompting）来消除歧义。

路线图图表

选择适合这项工作的 Mermaid 类型：

  • flowchart —— 首选用于展示存在依赖关系但没有固定日程的推进路线图（单人开发或长期计划的常见情况）。
  • gantt —— 仅在存在实际团队排期时使用（具体开始日期、各轨道的人员容量）。对于单人开发或没有截止日期的工作，甘特图会造成虚假的精确感；应改用流程图。

交叉引用

始终在 00-overview.md 顶部包含：

**Origin:** `planning/<initiative>/intake.md`

每个故事文件都包含：

**Origin:** `planning/<initiative>/epics/NN-<epic-name>/00-overview.md`

如果可用，也包含：

**Prototype refs:** `planning/<initiative>/proto` route/screen IDs
**Business rules:** `planning/<initiative>/business/*.md` rule IDs

后续步骤

在 Epic 末尾提供以下选项：

  • “要我用 /agile-story 为故事 1 创建执行计划吗？”
  • “要我用 /agile-refinement 验证这些产物吗？”

询问用户希望先详细规划哪个故事。

参考模板

使用此技能中的 templates/epic.md 作为概览产物的基础。

规则

  • Epic 现在直接负责拆分——拆分不再需要单独的细化步骤。/agile-refinement 仅用于验证/检查。
  • 按行为/交付（纵向切片）拆分，而不是按技术层拆分。
  • 待办列表中的每个故事都必须有明确的目标，并且能够单独执行。
  • 路线图必须展示依赖关系，而不只是时间顺序。
  • Epic 验收标准必须可验证。
  • 随着 Epic 的推进，更新故事状态。
  • 每个故事文件都必须包含足够的背景，使其能够独立规划和执行。

00-overview.md 的必需章节

  1. 上下文（问题、现状、目标状态、范围外内容）
  2. 可追溯性（原型路由/界面和业务规则 ID/文件）
  3. 故事待办列表（包含目标、规模、依赖关系、状态的列表）
  4. 路线图（阶段、并行性、关键路径）
  5. Epic 验收标准
  6. 风险

NN-story-name.md 的必需章节

  1. 上下文（问题、目标、价值、约束）
  2. 可追溯性（原型路由/界面和业务规则 ID/文件）
  3. 文件（确切路径、操作、原因）
  4. 详情（现状、目标状态、范围、验收标准、依赖关系）
  5. 任务（按垂直阶段划分的可验证检查清单）
  6. 验证（命令、验证项、证据）

与工作流的关系

flowchart LR
    A["/agile-intake"] --> B["/agile-roadmap"]
    B --> C["/agile-epic"]
    C --> D["/agile-story"]
    D --> E[execution]
    E --> F["/agile-status"]
    F --> G["/agile-retro"]

此技能在需求收集/路线图之后、任务级执行之前发挥作用。要验证产物，请使用 /agile-refinement。要制定执行计划，请使用 /agile-story。

评论

支持 Markdown