ln-210-epic-coordinator

路径： 文件路径（references/、../ln-*）均相对于此技能目录。

Epic 协调器

类型： L2 领域协调器
类别： 2XX 规划

通用 Epic 管理协调器，通过范围分解处理 Epic 的创建和重新规划。

用途

协调基于范围分解的 Epic 创建（CREATE）和重新规划（REPLAN）。在预览获得批准之前，发现与研究保持只读；执行始终在 ln-210 内联进行。

何时使用此技能

在以下情况下应使用此技能：

• 开始需要分解为多个逻辑领域的新范围／计划（CREATE 模式）
• 将大型架构需求拆分为多个 Epic
• 在范围／需求变更时更新现有 Epic（REPLAN 模式）
• 在计划内重新平衡 Epic 范围
• 向现有计划结构添加新 Epic
• 项目规划的第一步（范围 → Epic → Story → Task）
• 为每个领域定义清晰的范围边界和成功标准

输出： 3-7 个跟踪器 Epic（逻辑领域／模块；通过已配置的提供方传输）

运行时契约

必须读取： 加载 references/coordinator_runtime_contract.md、references/epic_planning_runtime_contract.md、references/epic_plan_summary_contract.md
必须读取： 当项目包含 docs/hypotheses/、docs/goals/ 或可能改变 Epic 边界的基准运行清单时，加载 references/researchgraph_mcp_usage.md

运行时系列：epic-planning-runtime

标识符：

• 范围标识符

阶段：

1. PHASE_0_CONFIG
2. PHASE_1_DISCOVERY
3. PHASE_2_RESEARCH
4. PHASE_3_PLAN
5. PHASE_4_MODE_DETECTION
6. PHASE_5_PREVIEW
7. PHASE_6_DELEGATE
8. PHASE_7_FINALIZE
9. PHASE_8_SELF_CHECK

决策处理：

• 预览／确认对应运行时状态 PAUSED + pending_decision
• ln-210 在作为 ln-200 的下游协调器使用时，会写入最终的 epic-plan 摘要

协调器产物流程：

• 执行始终在 ln-210 内联进行
• PHASE_7_FINALIZE 通过 node references/scripts/epic-planning-runtime/cli.mjs record-plan-summary 写入协调器摘要
• 托管的父级流程会将产物存储在 .hex-skills/runtime-artifacts/runs/{parent_run_id}/epic-plan/{identifier}.json

工作器调用（必须）

阶段	工作器	上下文
6	无	CREATE／REPLAN 执行在 ln-210 内联进行；不会委派下游 Skill 工作器

下游契约： ln-210 本身是 ln-200 的工作器，并会在内联 Epic 创建／重新规划执行完成后写入机器可读的 epic-plan 输出。

TodoWrite 格式（必需）

- Phase 1: Discover scope and project context (pending)
- Phase 2: Research only what changes Epic boundaries (pending)
- Phase 3: Build ideal Epic plan (pending)
- Phase 4: Detect mode and validate Infra Epic need (pending)
- Phase 5: Preview and confirm plan (pending)
- Phase 6: Execute create/replan flow (pending)
- Phase 7: Finalize epic-plan summary (pending)
- Phase 8: Self-check (pending)

核心概念

优先分解模式

核心原则： 始终先分析范围并制定理想的 Epic 计划，然后再检查现有 Epic 以确定模式：

• 没有现有 Epic → CREATE 模式（生成并创建所有 Epic）
• 存在现有 Epic → REPLAN 模式（比较并确定操作：KEEP／UPDATE／OBSOLETE／CREATE）

原因： 确保根据当前范围需求进行一致的 Epic 分解，不受现有 Epic 结构（可能已过时或不理想）影响。

Epic 0 专用于基础设施

必须读取： 加载 references/numbering_conventions.md，了解 Epic 0 规则、使用时机和跟踪器编号。

---

输入

输入	必需	来源	描述
scopeDoc	是	参数、项目文档、用户	用于 Epic 分解的范围文档

解析： Epic 解析链（适配版本：范围文档发现）。
回退： 如果未找到范围文档 → AskUserQuestion：“应将什么内容分解为 Epic？”

工作流

阶段 0：工具配置

必须读取： 加载 references/environment_state_contract.md、references/storage_mode_detection.md、references/input_resolution_pattern.md

提取：task_provider = Task Management → Provider

阶段 1：探索

目标： 收集塑造 Epic 边界所需的最少上下文，且不进行任何预览或更改。

步骤 0：解析 scopeDoc（根据 input_resolution_pattern.md，针对范围进行调整）：

• 如果提供了参数（范围描述或文档路径）→ 使用参数
• 否则，如果 docs/project/requirements.md 存在 → 将其用作范围来源
• 否则，如果 docs/requirements.md 存在 → 将其用作范围来源
• 否则 → AskUserQuestion：“需要将什么内容拆分为 Epics？”

步骤 1：加载配置

自动从 docs/tasks/kanban_board.md 中发现 Team ID 和下一个 Epic 编号：

• Team ID： 读取 Tracker Configuration 表 → 回退方案：直接询问用户
• 下一个 Epic 编号： 读取 Next Epic Number 字段 → 回退方案：直接询问用户

必须读取： 加载 CLAUDE.md — “Configuration Auto-Discovery”和“Tracker Integration”章节。

阶段 2：调研

目标： 仅调研会影响 Epic 边界、是否需要 Infra Epic 或批次预览质量的内容。

步骤 1：项目调研

目标： 在向用户提问之前，调研项目文档和前端代码，以了解上下文。

流程：

0. Researchgraph 预检（如果存在）：

   • 如果存在 docs/hypotheses/、docs/goals/ 或 benchmark/runs/*/manifest.yaml，请先以只读方式运行 verify_index。
   • 仅当目标／假设可能影响 Epic 边界、验证范围或推广／泛化工作时，才使用 inspect_goal、trace_goal_tree、find_hypotheses 或 audit_goal_alignment。
   • 将图谱中的 STALE 债务视为规划背景，不要仅凭这一点将其作为 Epic 阻碍。

1. 文档扫描：

   • 使用 Glob 查找：docs/requirements.md、docs/architecture.md、docs/tech_stack.md
   • 使用 Read 加载找到的文档

2. 前端代码扫描（如适用）：

   • 使用 Glob 查找：**/*.html、src/**/*.html、public/**/*.html、templates/**/*.html
   • 使用 Read 加载 HTML 文件
   • 从以下内容中提取功能领域：
     • 导航菜单： <nav>、<a href> 链接可揭示功能区域
     • 表单： 输入字段可揭示数据模型（用户注册、登录、结账）
     • 页面标题： <h1>、<title> 标签可揭示功能名称
     • 路由模式： URL 结构可揭示领域边界

   HTML 提取示例：

   <nav>
     <a href="/products">Products</a>
     <a href="/cart">Shopping Cart</a>
     <a href="/checkout">Checkout</a>
   </nav>
   
   

3. 从文档和 HTML 中提取关键信息：

   • 业务目标： 项目旨在实现什么？（来自 requirements.md）
   • 用户角色： 谁会使用该系统？（来自 requirements.md）
   • 主要功能领域： 主要模块／区域有哪些？（来自 requirements.md、architecture.md、HTML 导航）
   • 技术栈： 提到了哪些技术？（来自 tech_stack.md、architecture.md、HTML meta/script 标签）
   • 基础设施需求： 是否提及日志记录、监控、部署、CI/CD、安全或性能优化？

4. 整合发现：

   • 合并来自文档和 HTML 的领域（去重并整合相似项）
   • 示例：“用户认证”（来自文档）+“登录”（来自 HTML）→“用户管理”

回退方案： 如果文档和 HTML 均缺失 → 跳转到范围提问；不要臆造需要大量调研的细节

步骤 2：基础设施 Epic 决策

目标： 确定是否应提出基础设施 Epic（Epic 0）。

提出基础设施 Epic 的标准：

✅ 如果满足以下任一条件，则提出基础设施 Epic（Epic 0）：

1. 新项目（未找到 docs/infrastructure.md，且 kanban_board.md 的 Epic Story Counters 中没有 Epic“基础设施”）
2. 多技术栈（requirements.md 或 tech_stack.md 提及前端和后端使用不同技术栈，例如 React + Python）
3. requirements.md、architecture.md 中提及基础设施需求：
   • 日志记录、错误处理
   • 监控、告警
   • 托管、部署、CI/CD
   • 安全（身份验证、授权、加密、密钥管理）
   • 性能优化（缓存、速率限制、数据库优化）

❌ 以下情况不要提出：

1. 现有项目（已找到 docs/infrastructure.md）
2. Epic Story Counters 显示已有标题中包含“基础设施”的 Epic
3. 用户在之前的交互中明确拒绝

决策： 保存 YES/NO 决策，供阶段 2 使用

发现与调研的输出：

• 团队 ID、下一个 Epic 编号
• 项目上下文（业务目标、来自文档和 HTML 的领域、技术栈、基础设施需求）——如有
• 基础设施 Epic 决策（YES/NO）

阶段 2：范围分析与 Epic 规划

**目标：**识别逻辑领域并内联构建 Epic 结构。

流程：

步骤 1：自动识别领域

使用阶段 1 步骤 2 的研究背景：

• 如果找到项目文档 → 从 requirements.md、architecture.md 中提取领域（模块名称、功能区域）
• 如果找到 HTML → 从导航、表单、页面结构中提取领域
• 合并并去重领域
• 示例："用户身份验证" + "个人资料管理" → "用户管理"

**回退方案：**如果没有文档/HTML → 向用户询问基本问题（范围、目标、功能区域）

步骤 2：构建 Epic 列表（内联）

如果需要基础设施（来自阶段 1 步骤 3）：

• Epic 0：基础设施与运维 — 按照 numbering_conventions.md §Epic 0 Content Template
• **Epic 1-N：**业务领域（来自步骤 1）

否则：

• **Epic 1-N：**仅业务领域

步骤 3：确定 Epic 数量

• 基础设施 Epic（如适用）：+1 个 Epic
• 简单计划（1-3 个领域）：总计 3-4 个 Epic
• 中等计划（4-6 个领域）：总计 5-7 个 Epic
• 复杂计划（7 个以上领域）：总计 7-10 个 Epic（少见）
• 每个计划最多 10 个 Epic（强制执行）

步骤 4：展示提议的 Epic 结构（用户控制点 1）

显示已识别的 Epic 及其计划内索引：

📋 Proposed Epic Structure:

Epic 0: Infrastructure & Operations
Epic 1: User Management
Epic 2: Product Catalog
Epic 3: Shopping Cart
Epic 4: Payment Processing
Epic 5: Order Management

Total: 6 Epics
Type "confirm" to proceed, or modify the list

步骤 5：用户确认

• 用户输入 "confirm" → 进入阶段 3
• 用户修改 → 更新领域列表并再次显示

**输出：**已批准的 Epic 列表（Epic 0-N 或 Epic 1-N），供下一阶段使用

**只读准备规则：**可预先收集领域提取、HTML 扫描和基础设施 Epic 检测结果。预览获得确认前，不要开始创建/重新规划。

Epic 质量关卡

**背景：**在创建 Epic 前进行结构化质量检查，可确保范围清晰，并避免在 Story 分解期间返工。

对每个提议的 Epic 验证 5 项标准：

#	标准	通过	未通过
1	范围清晰度	明确的范围内/范围外边界	含糊或与其他 Epic 重叠
2	成功标准	可衡量（"<200ms"、">98%"）	含糊（"快速"、"可靠"）
3	风险文档	已识别依赖项/阻碍因素	风险部分为空或内容笼统
4	平衡性	各 Epic 范围规模相近（±30%）	一个 Epic 占 80% 的工作量
5	独立性	Epic 之间无循环依赖	Epic 互相阻碍

质量分数 = 通过项数量（0-5）

• 5/5：继续创建
• 3-4/5：显示警告，由用户决定
• <3/5：创建前重新规划 Epic 结构

---

阶段 3：检查现有 Epic

**目标：**确定 CREATE 还是 REPLAN 模式。

查询 kanban_board.md 和任务提供方，查找现有 Epic：

1. 读取 kanban_board.md 中的 Epic Story Counters 表
2. **如果 task_provider == "linear"：**执行 list_projects(team=teamId) 进行交叉核对
   **否则如果 task_provider == "github"：**执行 gh issue list -R {REPO} --label epic --state all --json number,title 进行交叉核对
   **否则：**执行 Glob("docs/tasks/epics/*/epic.md") 列出基于文件的 Epic
3. 统计现有 Epic 行数（不包括标题行）

决策点：

• 数量 = 0 → 没有现有 Epic → 进入阶段 4+5a（CREATE MODE）
• 数量 ≥ 1 → 找到现有 Epic → 进入阶段 5b（REPLAN MODE）

---

阶段 4：Epic 准备（仅限 CREATE 模式）

触发条件： 阶段 3 确定数量 = 0（CREATE 模式）

目标： 在批量预览前准备好所有 Epic 文档。

步骤 1：自动提取所有领域的信息

对于每个领域（来自阶段 2），从项目文档中提取以下 5 个关键问题的答案：

1. Q1：业务目标 - 此 Epic/领域为何重要

   • 来源： requirements.md（领域目标部分）
   • 提取方式：“[领域]模块旨在……”或“目标：[目标]”
   • 备用来源： architecture.md（模块用途）

2. Q2：范围内的关键功能 - 3-5 个能力要点

   • 来源： requirements.md（此领域的功能需求）
   • 提取方式： 领域标题下的项目符号列表、功能描述
   • 备用来源： architecture.md（组件职责）

3. Q3：范围外内容 - 防止范围蔓延

   • 来源： requirements.md（明确排除的功能部分）
   • 提取方式：“不在范围内：”“未来版本：”“[领域]的范围外内容：”
   • 备用来源： 根据 requirements.md 推断（领域中未提及的功能）

4. Q4：成功标准 - 可衡量的结果

   • 来源： requirements.md（此领域的验收标准、指标、KPI）
   • 提取方式： 性能目标、用户指标、质量门槛
   • 备用来源： 根据领域类型使用通用标准（例如，后端的“<200ms API 响应”）

5. Q5：已知风险（可选）- 阻碍因素、依赖项

   • 来源： architecture.md（技术约束、依赖项部分）
   • 提取方式：“风险：”“依赖项：”“约束：”
   • 备用来源： 如属关键事项则询问用户，否则填写“将在 Story 规划期间确定”

如果信息提取不完整：

• 向用户展示已提取的信息
• 一次性询问所有领域中缺失的信息（批量提问，而非逐个领域提问）
• 示例：“对于 Epic 1（用户管理），我未能找到成功标准。对于 Epic 2（支付），我未能找到风险。请提供……”

步骤 2：生成所有 Epic 文档

对于每个领域，使用 epic_template_universal.md 生成完整的 Epic 文档：

Epic 编号：

• 如果存在基础设施 Epic（来自阶段 1 步骤 3）→ Epic 0（基础设施），Epic 1-N（业务领域）
• 否则 → Epic 1-N（仅业务领域）

Tracker 标题（将在阶段 5a 创建）：

• 使用 kanban_board.md 中的下一个 Epic 编号，按顺序编号
• 格式：“Epic {Next Epic Number}: {Domain Title}”
• 示例：Next = 11 → “Epic 11: Infrastructure & Operations”

章节： 目标、范围内/外、成功标准、依赖项、风险与缓解措施、架构影响、阶段

在所有章节中使用步骤 1 提取的信息

输出： 所有 Epic 文档均已就绪（Epic 0-N），并在项目计划内编好序号

---

阶段 5a：创建 Epic（CREATE 模式）

触发条件： 阶段 4 已完成准备

目标： 显示预览、获取确认，并通过已配置的跟踪器提供商创建所有 Epic。

步骤 1：显示批量预览（用户控制点 2）

显示所有已生成的 Epic，并使用项目计划内的索引：

📋 Epic Batch Preview (6 Epics to create)

═══════════════════════════════════════════════
Epic 0: Infrastructure & Operations
═══════════════════════════════════════════════
Goal: Establish foundational infrastructure, deployment pipeline, and operational capabilities to support all business Epics

Scope In:
- Logging and error handling framework
- Monitoring and alerting system
- CI/CD pipeline (GitHub Actions)
- Security baseline (secrets management, encryption)
- Performance optimization (caching, rate limiting)

Scope Out:
- Application-specific business logic
- User-facing features
- Domain-specific integrations

Success Criteria:
- All deployments automated via CI/CD (<10 min deployment time)
- System uptime ≥99.9%
- API response time <200ms (p95)
- Security audit passed

═══════════════════════════════════════════════
Epic 1: User Management
═══════════════════════════════════════════════
Goal: Enable users to register, authenticate, and manage their accounts securely

Scope In:
- User registration with email verification
- Login/logout with JWT authentication
- Password reset flow
- Profile management

Scope Out:
- Social login (OAuth) - planned for Epic 5
- Multi-factor authentication - future version
- User roles and permissions - part of Epic 3

Success Criteria:
- User registration <2 seconds
- Login success rate >98%
- Password reset completion rate >90%

[... all other Epics ...]

───────────────────────────────────────────────
Total: 6 Epics (Epic 0: Infrastructure, Epic 1-5: Business domains)
Type "confirm" to create all Epics via the configured tracker provider

步骤 2：用户确认

• 用户输入“confirm” → 继续执行步骤 3
• 用户提供反馈 → 在阶段 4 调整文档，重新生成预览并重复

停止条件（预览循环）

条件	操作
用户确认（输入 "confirm" 或批准）	STOP — 继续创建
用户反馈循环 >= 3	STOP — 询问："已进行 3 轮修改。使用当前版本继续，还是放弃？"
Epic 质量门评分在 2 次返工后仍 < 3/5	STOP — 升级处理："无法达到质量门槛。请检查范围。"

第 3 步：创建所有 Epic

按顺序为每个 Epic 创建（确保编号一致）：

1. 获取下一个 Epic 编号：

   • 从 kanban_board.md 读取当前的 Next Epic Number
   • 示例：11

2. 创建 Epic（取决于提供方）：

   如果 task_provider == "linear"：

   • save_project({name: "Epic {N}: {Title}", description: epic_markdown, team: teamId, state: "planned"})
   • 收集返回的 URL

   否则，如果 task_provider == "github"：

   • gh issue create -R {REPO} --title "Epic {N}: {Title}" --body "{epic_markdown}" --label "epic"
   • 添加到项目并将状态设为 Backlog（参见 provider_github.md）
   • 收集返回的 issue URL

   否则（文件模式）：

   • mkdir -p docs/tasks/epics/epic-{N}-{slug}/stories/
   • Write("docs/tasks/epics/epic-{N}-{slug}/epic.md")，写入 Epic Markdown 和文件头（**Status:** Backlog、**Created:** {date}）

3. 更新 kanban_board.md：

   • 在 Tracker Configuration 表中将 Next Epic Number 加 1
   • 在 Epic Story Counters 中添加新行：Epic {N} | - | US001 | - | EPN_01
   • 在 "Epics Overview" → Active 中添加：- [Epic {N}: Title](link) - Backlog

4. 根据 references/provider_file.md, references/provider_github.md, references/provider_linear.md 收集 URL（Linear/GitHub 模式）或文件路径（文件模式）

第 4 步：显示摘要

✅ Created 6 Epics for initiative

Epics created:
- Epic 11: Infrastructure & Operations (Epic 0 index) [link]
- Epic 12: User Management (Epic 1 index) [link]
- Epic 13: Product Catalog (Epic 2 index) [link]
- Epic 14: Shopping Cart (Epic 3 index) [link]
- Epic 15: Payment Processing (Epic 4 index) [link]
- Epic 16: Order Management (Epic 5 index) [link]

Next Epic Number updated to: 17

Next Steps:
1. Use ln-220-story-coordinator to create Stories for each Epic (run 6 times)
2. OR use ln-200-scope-decomposer to automate Epic + Story creation

输出： 已创建的 Epic URL + 摘要

TodoWrite 格式： 添加 Phase 1-5a 待办事项、每个 Epic 对应一项待办事项，以及 kanban 更新事项。将状态标记为 in_progress/completed。

---

第 5b 阶段：重新规划模式（发现现有 Epic）

触发条件： 第 3 阶段确定 Count ≥ 1（重新规划模式）

完整工作流： 必须读取： 加载 references/replan_workflow.md，查看完整的重新规划流程。

摘要：

1. 加载现有 Epic（如果 task_provider == "linear"：从 Linear API 获取 | 如果 task_provider == "github"：从 gh issue list --label epic 获取 | 否则：从 docs/tasks/epics/*/epic.md 获取）
2. 比较理想计划与现有内容 → 分类为：保留/更新/废弃/创建
3. 显示重新规划摘要，包括差异和警告
4. 必须获得用户确认
5. 执行操作（参见 provider_*.md）并更新 kanban_board.md

约束： 绝不自动更新或归档包含进行中 Story 的 Epic。绝不删除（使用归档）。始终要求确认。

---

关键规则

• 优先拆分： 检查现有 Epic 前，始终先制定理想的 Epic 计划（避免受过时结构影响）
• Epic 0 预留给基础设施： 业务领域从 Epic 1 开始；检测到新项目、多技术栈或基础设施需求时，自动提议 Epic 0
• 提问前先自动提取： 从文档（requirements.md、architecture.md、tech_stack.md）和 HTML 中提取 Q1-Q5；仅将缺失信息一次性集中询问用户
• 绝不自动更新包含进行中 Story 的 Epic： 重新规划模式需要用户确认；对包含活跃 Story 的 Epic 发出警告，不得静默更改
• 跟踪器标题格式： "Epic {Next Epic Number}: {Domain Title}" — 按 kanban_board.md 中的编号顺序递增

---

完成定义

完成工作前，请确认所有检查项均已完成：

✅ 探索完成（第 1 阶段）：

• 已从 kanban_board.md 加载团队 ID
• 已从 kanban_board.md 加载下一个 Epic 编号
• 已扫描文档（requirements.md、architecture.md、tech_stack.md）
• 已扫描 HTML 文件（如果存在前端）
• 已根据项目条件决定是否创建基础设施 Epic（是/否）

✅ 范围分析完成（第 2 阶段）：

• 已根据文档和 HTML 自动识别领域
• 在适用时已包含基础设施 Epic（Epic 0）
• 已构建 Epic 列表（Epic 0-N 或 Epic 1-N）
• 用户已确认 Epic 结构（控制点 1）

✅ 已检查现有 Epic（第 3 阶段）：

• 已从 kanban_board.md 读取 Epic 故事计数器
• 已确定现有 Epic 数量（0 → 创建，≥1 → 重新规划）

✅ Epic 准备完成（第 4 阶段——仅创建）：

• 已为所有领域自动提取 Q1-Q5
• 如需补充信息，用户已提供（批量提问）
• 已生成所有 Epic 文档（Epic 0-N 索引）

✅ Epic 创建完成（第 5a 阶段——仅创建）：

• 已展示包含 Epic 0-N 索引的批量预览
• 用户已确认预览（控制点 2）
• 已通过配置的跟踪器提供方创建所有 Epic，格式为 "Epic {N}: {Title}"（N = 下一个 Epic 编号）
• 每创建一个 Epic 后都已更新 kanban_board.md：
  • 下一个 Epic 编号加 1
  • 已添加 Epic 故事计数器行
  • 已更新 Epic 概览
• 已展示包含所有 Epic URL 的摘要
• 已在最终确认期间记录协调器 epic-plan 摘要

✅ Epic 重新规划完成（第 5b 阶段——仅重新规划）：

• 必须阅读： 加载 references/replan_workflow.md 以查看完整检查清单
• 已在最终确认期间记录协调器 epic-plan 摘要

输出： Epic URL 列表（Epic {N}: {Title}）+ 下一个 Epic 编号值

---

使用示例

请求：“为电子商务平台创建 Epic”

**流程：**第 1 阶段（发现团队 ID=Product、下一个编号=11，扫描文档和 HTML）→ 第 2 阶段（识别出 6 个领域：基础设施、用户、产品、购物车、支付、订单）→ 第 3 阶段（数量=0 → 创建）→ 第 4 阶段（自动提取 Q1-Q5，生成文档）→ 第 5a 阶段（预览、确认，通过配置的跟踪器提供方创建：Epic 11-16）

**结果：**已创建 6 个 Epic（内部索引为 Epic 0-5，跟踪器标题为 Epic 11-16）

---

第 6 阶段：元分析

可选参考：仅当用户要求进行运行后元分析或按协议格式整理运行反思时，才加载 references/meta_analysis_protocol.md。

技能类型：planning-coordinator。收到请求后，在所有阶段完成后执行。使用 planning-coordinator 格式在聊天中输出。

参考文件

• 必须阅读： 加载 references/environment_state_contract.md
• 必须阅读： 加载 references/storage_mode_detection.md
• [必须] 问题解决方法： references/problem_solving.md
• 协调器生命周期： references/orchestrator_pattern.md
• 自动发现模式： references/auto_discovery_pattern.md
• 优先分解模式： references/decompose_first_pattern.md
• 编号约定： references/numbering_conventions.md（Epic 0 保留、跟踪器编号）
• 问题创建工作流： references/issue_creation_workflow.md
• linear_integration.md： 发现模式 + Linear API 参考（已移至 references/templates/linear_integration.md）
• epic_template_universal.md： Epic 模板结构
• replan_workflow.md： 完整的重新规划模式工作流（第 5b 阶段）

最佳实践

• 先做调研： 在询问用户前，先查阅文档（requirements.md、architecture.md、tech_stack.md）和 HTML
• 基础设施使用 Epic 0： 基础设施 Epic 保留编号 0；业务领域从 Epic 1 开始
• 业务 Epic 分组： 1 个 Epic = 5–10 个 Story = 1 项业务能力（而非技术组件）
• 自动提取： 提问前先从文档中提取 Q1–Q5；仅询问缺失信息
• 跟踪器标题： 格式为“Epic {Next Epic Number}: {Domain}”
• 以业务为重点的范围： 列出用户能力，而非技术任务
• 可衡量的标准： 使用“<200ms”，而非“快速”；使用“>98% 登录率”，而非“可靠”
• 不包含代码片段： 仅包含高层级功能和目标

---

版本： 8.0.0 最后更新： 2026-04-05