agile-epic

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Epic

Use this skill to transform an intake, roadmap, or large initiative into a structured epic with decomposed stories, a roadmap, and acceptance criteria.

Initial context received via slash: $ARGUMENTS

$ARGUMENTS

is filled (e.g., intake path, description, initiative name), use as starting point. If empty, ask which initiative will be structured.

使用此技能将intake、roadmap或大型项目转化为结构化的Epic，包含拆解后的stories、roadmap和acceptance criteria。

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

如果

$ARGUMENTS

已填写（例如intake路径、描述、项目名称），则以此为起点。如果为空，则询问需要结构化的项目名称。

Language

语言

Write the artifact in the user's language. Apply correct grammar and any required diacritics or script-specific characters. If the user's language is unclear, ask before generating output. Templates are in English — translate headers and content to match.

以用户使用的语言编写工件。使用正确的语法以及所需的变音符号或特定脚本字符。如果用户的语言不明确，在生成输出前先询问。模板为英文——请将标题和内容翻译为匹配的语言。

Project root

项目根目录

This skill writes artifacts at paths relative to the project root (the repo where the work happens), not the agent's current working directory.

If invoked from inside the project, use the relative paths shown in this skill.
If invoked from another directory (e.g., a sibling repo, or when the project lives elsewhere), prepend
```
<project-root>/
```
to every artifact path.
When the project root is ambiguous, confirm with the user via the harness question tool before writing.

此技能会在项目根目录（即开展工作的仓库）的相对路径下编写工件，而非Agent当前的工作目录。

如果从项目内部调用，请使用本技能中所示的相对路径。
如果从其他目录调用（例如同级仓库，或项目位于其他位置），请在每个工件路径前添加
```
<project-root>/
```
。
当项目根目录不明确时，请先通过harness问题工具与用户确认，再进行编写。

Prompting

提示方式

Follow the project-wide convention in

CLAUDE.md

AGENTS.md

("Skill Prompting Conventions"). Use the harness's structured-question tool —

AskUserQuestion

(Claude Code),

ask_user_question

(Codex), or

question

(OpenCode) — for the decision points below. Use free-form text only where a path/name/value cannot be enumerated.

Decision point	Why structured	Suggested options
Save path when user-passed path conflicts with convention	Hard-to-undo write	Use convention · Honor user path · Ask
Roadmap diagram type	Affects template fit	Mermaid flowchart · Mermaid gantt
Which story to detail first via /agile-story	Branches the next skill	first by dependency · pick

Free-form prompts (no structured tool):

Story names (kebab-case)
Epic title and outcome wording

No-pause mode: if the user has explicitly disabled mid-skill clarification, convert every structured prompt into an entry under Open questions (or equivalent) and proceed without blocking.

遵循

CLAUDE.md

AGENTS.md

中的项目级约定（"Skill Prompting Conventions"）。对于以下决策点，使用harness的结构化问题工具——Claude Code使用

AskUserQuestion

，Codex使用

ask_user_question

，OpenCode使用

question

。仅当路径/名称/值无法枚举时，才使用自由格式文本。

决策点	使用结构化方式的原因	建议选项
用户传入的路径与约定冲突时的保存路径	写入操作难以撤销	遵循约定 · 尊重用户路径 · 询问用户
Roadmap图表类型	影响模板适配性	Mermaid流程图 · Mermaid甘特图
通过/agile-story优先细化哪个story	决定后续技能分支	按依赖顺序优先 · 手动选择

自由格式提示（不使用结构化工具）：

Story名称（短横线分隔格式，kebab-case）
Epic标题和成果描述

无暂停模式：如果用户明确禁用技能执行中的澄清环节，请将所有结构化提示转换为"开放式问题"（或等效部分）下的条目，无需等待用户回复即可继续执行。

Objective

目标

Decompose large initiatives into proportional, executable stories
Structure a story backlog with dependencies and order
Define an epic roadmap (phases, unblocks, intermediate validations)
Ensure each story can be planned and executed separately
Produce artifacts that guide execution without replacing individual task plans

将大型项目拆解为比例合理、可执行的stories
构建包含依赖关系和执行顺序的story待办事项列表
定义Epic roadmap（阶段、解锁条件、中间验证环节）
确保每个story可单独规划和执行
生成指导执行的工件，但不替代单个任务计划

When to use

使用场景

After an
```
/agile-intake
```
or
```
/agile-roadmap
```
identified a large initiative
When the initiative requires multiple coordinated stories
When there are dependencies between deliveries that need sequencing
When a roadmap is needed to guide the delivery order
For medium-to-large work that needs richer structure than a simple
```
/agile-story
```

在
```
/agile-intake
```
或
```
/agile-roadmap
```
识别出大型项目后使用
当项目需要多个协同的stories时
当交付之间存在需要排序的依赖关系时
当需要roadmap指导交付顺序时
对于需要比简单
```
/agile-story
```
更丰富结构的中大型工作

When NOT to use

不适用场景

The work is small and localized — use
```
/agile-story
```
directly
The problem hasn't been captured yet — use
```
/agile-intake
```
first
You need strategic direction — use
```
/agile-roadmap
```
first
You need to validate existing artifacts — use
```
/agile-refinement
```

工作范围小且集中——直接使用
```
/agile-story
```
问题尚未明确——先使用
```
/agile-intake
```
需要战略方向——先使用
```
/agile-roadmap
```
需要验证现有工件——使用
```
/agile-refinement
```

Process

流程

1. Analyze context

1. 分析上下文

Read the intake, roadmap, or provided material. Identify:

Macro problem and objective
Which areas are impacted
Constraints and premises
Estimated scope and complexity
Existing prototypes under
```
planning/<initiative>/proto/
```
, when UI/product flows matter
Existing business rules under
```
planning/<initiative>/business/*.md
```
, when domain behavior matters

If the initiative is UI-heavy and prototypes are an agreed gate, do not finalize epics until the relevant prototype routes/screens exist or the user explicitly waives the gate.

读取intake、roadmap或提供的材料，识别：

宏观问题与目标
受影响的领域
约束条件与前提假设
预估范围与复杂度
当UI/产品流程重要时，
```
planning/<initiative>/proto/
```
下的现有原型
当领域行为重要时，
```
planning/<initiative>/business/*.md
```
下的现有业务规则

如果项目以UI为主且原型是约定的必经环节，则在相关原型路由/页面存在或用户明确豁免该环节前，不要最终确定Epic。

2. Decompose into stories

2. 拆解为stories

Break by vertical value slice, not by technical layer:

Each story must deliver something observable
Prefer independent stories when possible
Identify dependencies between stories (what unblocks what)

For each story, define:

Name and objective (1 line)
Estimated scope (small, medium, or large)
Dependencies (which stories it depends on)
Prototype routes/screens involved, when applicable
Business rule IDs/files involved, when applicable
Summarized acceptance criteria

按垂直价值切片拆分，而非按技术层拆分：

每个story必须交付可观察的成果
尽可能优先选择独立的stories
识别stories之间的依赖关系（哪些story会解锁其他story）

为每个story定义：

名称与目标（1行）
预估范围（小、中、大）
依赖关系（依赖哪些stories）
涉及的原型路由/页面（如适用）
涉及的业务规则ID/文件（如适用）
总结性的acceptance criteria

3. Structure the epic overview

3. 构建Epic概览

Fill in the required sections:

Context: problem, AS-IS, TO-BE, out of scope
Story backlog: list with objective, size, and dependency of each
Roadmap: phases/sprints, what unblocks what, intermediate validations
Risks: what could go wrong and how to mitigate
Epic acceptance criteria: how to know the initiative is complete

填写所需部分：

上下文：问题现状、当前状态、目标状态、范围外内容
Story待办事项列表：包含每个story的目标、规模和依赖关系的列表
Roadmap：阶段/迭代、解锁条件、中间验证环节
风险：可能出现的问题及缓解措施
Epic验收标准：如何判断项目已完成

4. Define roadmap

4. 定义Roadmap

Group stories by phase/sprint
Show what can run in parallel
Highlight the critical path
Include intermediate validations (milestones)

按阶段/迭代分组stories
展示可并行执行的内容
突出关键路径
包含中间验证环节（里程碑）

5. Consider collaborative work

5. 考虑协作工作

When the team has 2+ developers:

Identify parallel tracks or lanes so devs can work simultaneously
Define interface contracts between tracks (types, schemas, APIs) to minimize blocking
Assign stories to tracks when possible
Use Mermaid
```
gantt
```
diagrams to visualize parallel work across tracks

当团队有2名及以上开发者时：

识别并行任务流，以便开发者可同时工作
定义任务流之间的接口契约（类型、schema、API），以减少阻塞
尽可能将stories分配到不同任务流
使用Mermaid
```
gantt
```
图表可视化跨任务流的并行工作

6. Generate files

6. 生成文件

The epic produces multiple files:

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
```
contains the epic-level context, story backlog summary, roadmap, risks, and acceptance criteria.
Each
```
NN-story-name.md
```
contains the story context, acceptance criteria, files, tasks, and verification — all in one file.

NN is a zero-padded sequential number. Each epic gets its own folder under
epics/
.

Epic会生成多个文件：

planning/<initiative>/epics/NN-<epic-name>/
├── 00-overview.md         (Epic概览：上下文、待办事项、roadmap、风险)
├── 01-story-name.md       (第一个story：上下文+内嵌任务)
├── 02-story-name.md       (第二个story：上下文+内嵌任务)
└── ...

```
00-overview.md
```
包含Epic级别的上下文、story待办事项摘要、roadmap、风险和验收标准。
每个
```
NN-story-name.md
```
包含story上下文、acceptance criteria、文件、任务和验证——所有内容整合在一个文件中。

NN是带前导零的连续编号。每个Epic在
epics/
下拥有独立的文件夹。

Where to save

保存位置

Epic folder:

planning/<initiative>/epics/NN-<epic-name>/

If the initiative doesn't have a folder in
```
planning/
```
, ask the user for the name
Path-conflict gate: if the user passes a save path that does not match the convention above (e.g.,
```
planning/<initiative>/<epic-name>/
```
instead of the
```
epics/NN-<epic-name>/
```
shape), surface the conflict before writing. Honor the user's path only after explicit confirmation; otherwise apply the convention and tell the user why. Use the harness's question tool (see
```
## Prompting
```
) to disambiguate.

Epic文件夹：

planning/<initiative>/epics/NN-<epic-name>/

如果
```
planning/
```
下没有该项目的文件夹，请询问用户名称
路径冲突检查：如果用户传入的保存路径不符合上述约定（例如
```
planning/<initiative>/<epic-name>/
```
而非
```
epics/NN-<epic-name>/
```
格式），请在写入前提示冲突。仅在用户明确确认后才遵循用户路径；否则应用约定并告知用户原因。使用harness的问题工具（参见
```
## 提示方式
```
）消除歧义。

Roadmap diagram

Roadmap图表

Pick the Mermaid type that fits the work:

flowchart
— preferred for trajectory roadmaps with dependencies but no fixed schedule (the common case for solo dev or long-running initiatives).
gantt
— use only when real team scheduling exists (concrete start dates, capacity per track). For solo dev or no-deadline work, gantt produces fake precision; pick flowchart instead.

选择适合工作内容的Mermaid类型：

flowchart
—— 优先用于有依赖关系但无固定时间表的轨迹式roadmap（独立开发者或长期项目的常见场景）。
gantt
—— 仅当存在真实团队排期（具体开始日期、每个任务流的容量）时使用。对于独立开发者或无截止日期的工作，甘特图会产生虚假的精确性；请选择流程图替代。

Cross-reference

交叉引用

Always include at the top of

00-overview.md

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

Each story file includes:

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

When available, also include:

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

请始终在

00-overview.md

顶部包含：

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

每个story文件包含：

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

如果可用，还需包含：

**Prototype refs:** `planning/<initiative>/proto` 路由/页面ID
**Business rules:** `planning/<initiative>/business/*.md` 规则ID

Chaining

技能衔接

At the end of the epic, offer:

"Do you want me to create the execution plan for Story 1 with
```
/agile-story
```
?"
"Do you want me to validate the artifacts with
```
/agile-refinement
```
?"

Ask the user which story they want to detail first.

在Epic处理完成后，向用户提供以下选项：

"是否需要我使用
```
/agile-story
```
为Story 1创建执行计划？"
"是否需要我使用
```
/agile-refinement
```
验证这些工件？"

询问用户优先细化哪个story。

Reference template

参考模板

Use

templates/epic.md

from this skill as base for the overview artifact.

使用本技能中的

templates/epic.md

作为概览工件的基础模板。

Rules

规则

The epic now handles decomposition directly — there is no separate refinement step for decomposing. Use
```
/agile-refinement
```
only for validation/lint.
Break by behavior/delivery (vertical slices), not by technical layer.
Each story in the backlog must have a clear objective and be executable separately.
The roadmap must show dependencies, not just chronological order.
Epic acceptance criteria must be verifiable.
Update story statuses as the epic progresses.
Each story file must contain enough context to be planned and executed independently.

Epic现在直接处理拆解工作——没有单独的拆解细化步骤。仅在验证/检查时使用
```
/agile-refinement
```
。
按行为/交付（垂直切片）拆分，而非按技术层拆分。
待办事项列表中的每个story必须有明确的目标且可单独执行。
Roadmap必须展示依赖关系，而非仅按时间顺序排列。
Epic验收标准必须可验证。
随着Epic推进，更新story状态。
每个story文件必须包含足够的上下文，以便单独规划和执行。

Required sections for 00-overview.md

00-overview.md必填部分

Context (problem, AS-IS, TO-BE, out of scope)
Traceability (prototype routes/screens and business rule IDs/files)
Story backlog (list with objective, size, dependency, status)
Roadmap (phases, parallelism, critical path)
Epic acceptance criteria
Risks

上下文（问题、当前状态、目标状态、范围外内容）
可追溯性（原型路由/页面和业务规则ID/文件）
Story待办事项列表（包含目标、规模、依赖关系、状态的列表）
Roadmap（阶段、并行性、关键路径）
Epic验收标准
风险

Required sections for NN-story-name.md

NN-story-name.md必填部分

Context (problem, objective, value, constraints)
Traceability (prototype routes/screens and business rule IDs/files)
Files (exact paths, action, reason)
Detail (AS-IS, TO-BE, scope, acceptance criteria, dependencies)
Tasks (verifiable checklist in vertical phases)
Verification (commands, validations, evidence)

上下文（问题、目标、价值、约束条件）
可追溯性（原型路由/页面和业务规则ID/文件）
文件（精确路径、操作、原因）
细节（当前状态、目标状态、范围、acceptance criteria、依赖关系）
任务（垂直阶段的可验证检查清单）
验证（命令、验证步骤、证据）

Relationship with the flow

与工作流的关系

mermaid

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"]

This skill acts after intake/roadmap and before task-level execution. For validating artifacts, use

/agile-refinement

. For execution plans, use

/agile-story

mermaid

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"]

此技能在intake/roadmap之后、任务级执行之前使用。如需验证工件，请使用

/agile-refinement

。如需执行计划，请使用

/agile-story

。