ln-210-epic-coordinator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Epic Coordinator

Epic协调器

Universal Epic management coordinator that handles both creation and replanning through scope decomposition.
通用Epic管理协调器,通过范围分解处理Epic的创建与重新规划。

When to Use This Skill

何时使用此Skill

This skill should be used when:
  • Start new scope/initiative requiring decomposition into multiple logical domains (CREATE mode)
  • Break down large architectural requirement into Epics
  • Update existing Epics when scope/requirements change (REPLAN mode)
  • Rebalance Epic scopes within an initiative
  • Add new Epics to existing initiative structure
  • First step in project planning (scope → Epics → Stories → Tasks)
  • Define clear scope boundaries and success criteria for each domain
Output: 3-7 Linear Projects (logical domains/modules)
当出现以下情况时应使用此Skill:
  • 启动需要分解为多个逻辑领域的新范围/计划(CREATE模式)
  • 将大型架构需求拆分为Epic
  • 当范围/需求变更时更新现有Epic(REPLAN模式)
  • 重新平衡计划内的Epic范围
  • 向现有计划结构中添加新Epic
  • 项目规划的第一步(范围 → Epic → 用户故事 → 任务)
  • 为每个领域定义清晰的范围边界和成功标准
输出: 3-7个Linear项目(逻辑领域/模块)

Core Concepts

核心概念

Decompose-First Pattern

先分解模式

Key principle: ALWAYS analyze scope and build IDEAL Epic plan FIRST, THEN check existing Epics to determine mode:
  • No existing Epics → CREATE MODE (generate and create all Epics)
  • Has existing Epics → REPLAN MODE (compare, determine operations: KEEP/UPDATE/OBSOLETE/CREATE)
Rationale: Ensures consistent Epic decomposition based on current scope requirements, independent of existing Epic structure (which may be outdated or suboptimal).
核心原则: 始终先分析范围并构建理想的Epic计划,然后再检查现有Epic以确定模式:
  • 无现有Epic → CREATE模式(生成并创建所有Epic)
  • 存在现有Epic → REPLAN模式(对比,确定操作:保留/更新/废弃/创建)
原理: 确保基于当前范围需求进行一致的Epic分解,不受可能过时或非最优的现有Epic结构影响。

Epic 0 Reserved for Infrastructure

Epic 0 预留用于基础设施

MANDATORY READ: Load
shared/references/numbering_conventions.md
for Epic 0 rules, when to use it, and Linear numbering.

必读: 加载
shared/references/numbering_conventions.md
查看Epic 0的规则、使用场景以及Linear编号规范。

Workflow

工作流程

Phase 1: Discovery & Research

阶段1:发现与调研

Objective: Gather all necessary context before Epic decomposition.
Step 1: Load Configuration
Auto-discovers Team ID and Next Epic Number from
docs/tasks/kanban_board.md
:
  • Team ID: Reads Linear Configuration table → Fallback: Ask user directly
  • Next Epic Number: Reads Next Epic Number field → Fallback: Ask user directly
Details: See CLAUDE.md sections "Configuration Auto-Discovery" and "Linear Integration".
Step 2: Project Research
Objective: Research project documentation AND frontend code to understand context BEFORE asking user questions.
Process:
  1. Document Scan:
    • Use
      Glob
      to find:
      docs/requirements.md
      ,
      docs/architecture.md
      ,
      docs/tech_stack.md
    • Use
      Read
      to load found documents
  2. Frontend Code Scan (if applicable):
    • Use
      Glob
      to find:
      **/*.html
      ,
      src/**/*.html
      ,
      public/**/*.html
      ,
      templates/**/*.html
    • Use
      Read
      to load HTML files
    • Extract functional domains from:
      • Navigation menus:
        <nav>
        ,
        <a href>
        links reveal feature areas
      • Forms: Input fields reveal data models (user registration, login, checkout)
      • Page titles:
        <h1>
        ,
        <title>
        tags reveal feature names
      • Route patterns: URL structures reveal domain boundaries
    Example HTML extraction:
    html
    <nav>
      <a href="/products">Products</a>
      <a href="/cart">Shopping Cart</a>
      <a href="/checkout">Checkout</a>
    </nav>
    <!-- Reveals domains: Product Catalog, Shopping Cart, Payment -->
  3. Extract key information from docs + HTML:
    • Business objectives: What is the project trying to achieve? (from requirements.md)
    • User personas: Who will use the system? (from requirements.md)
    • Major functional domains: What are the main modules/areas? (from requirements.md, architecture.md, HTML navigation)
    • Technical stack: What technologies mentioned? (from tech_stack.md, architecture.md, HTML meta/script tags)
    • Infrastructure requirements: Any mention of logging, monitoring, deployment, CI/CD, security, performance optimization?
  4. Combine findings:
    • Merge domains from docs + HTML (deduplicate, consolidate similar)
    • Example: "User Auth" (from docs) + "Login" (from HTML) → "User Management"
Fallback: If docs AND HTML missing → Skip to Phase 2, will ask user basic questions
Step 3: Infrastructure Epic Decision
Objective: Determine if Infrastructure Epic (Epic 0) should be proposed.
Criteria for Infrastructure Epic:
PROPOSE Infrastructure Epic (Epic 0) if ANY of:
  1. New project (no
    docs/infrastructure.md
    found, no Epic "Infrastructure" in kanban_board.md Epic Story Counters)
  2. Multi-stack (requirements.md or tech_stack.md mentions frontend AND backend on different stacks - e.g., React + Python)
  3. Infrastructure requirements mentioned in requirements.md, architecture.md:
    • Logging, Error Handling
    • Monitoring, Alerting
    • Hosting, Deployment, CI/CD
    • Security (authentication, authorization, encryption, secrets management)
    • Performance optimization (caching, rate limiting, database optimization)
DO NOT propose if:
  1. Existing project (found
    docs/infrastructure.md
    )
  2. Epic Story Counters shows existing Epic with "Infrastructure" in title
  3. User explicitly declined in previous interaction
Decision: Store YES/NO decision for use in Phase 2
Output from Phase 1:
  • Team ID, Next Epic Number
  • Project context (business goals, domains from docs + HTML, tech stack, infrastructure needs) - if found
  • Infrastructure Epic decision (YES/NO)

目标: 在Epic分解前收集所有必要的上下文信息。
步骤1:加载配置
docs/tasks/kanban_board.md
自动发现Team ID和下一个Epic编号:
  • Team ID: 读取Linear配置表 → 备选方案:直接询问用户
  • 下一个Epic编号: 读取下一个Epic编号字段 → 备选方案:直接询问用户
详情: 查看CLAUDE.md中的“配置自动发现”和“Linear集成”章节。
步骤2:项目调研
目标: 在询问用户问题前,先调研项目文档和前端代码以了解上下文。
流程:
  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提取示例:
    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元标签/脚本标签)
    • 基础设施需求: 是否提到日志、监控、部署、CI/CD、安全、性能优化?
  4. 整合调研结果:
    • 合并来自文档和HTML的领域(去重、合并相似领域)
    • 示例:“用户认证”(来自文档) + “登录”(来自HTML) → “用户管理”
备选方案: 如果没有找到文档和HTML → 跳过阶段1,直接进入阶段2并询问用户基本问题
步骤3:基础设施Epic决策
目标: 确定是否应提议基础设施Epic(Epic 0)。
基础设施Epic的判定标准:
提议基础设施Epic(Epic 0) 如果满足以下任一条件:
  1. 新项目(未找到
    docs/infrastructure.md
    ,且kanban_board.md的Epic故事计数器中没有“Infrastructure”Epic)
  2. 多技术栈(requirements.md或tech_stack.md提到前端和后端使用不同技术栈 - 例如React + Python)
  3. 需求中提到基础设施 在requirements.md、architecture.md中提及:
    • 日志、错误处理
    • 监控、告警
    • 托管、部署、CI/CD
    • 安全(认证、授权、加密、密钥管理)
    • 性能优化(缓存、限流、数据库优化)
不提议 如果:
  1. 现有项目(找到
    docs/infrastructure.md
  2. Epic故事计数器显示标题中包含“Infrastructure”的现有Epic
  3. 用户在之前的交互中明确拒绝
决策: 存储YES/NO决策,供阶段2使用
阶段1输出:
  • Team ID、下一个Epic编号
  • 项目上下文(业务目标、来自文档和HTML的领域、技术栈、基础设施需求)(如果找到)
  • 基础设施Epic决策(YES/NO)

Phase 2: Scope Analysis & Epic Planning

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

Objective: Identify logical domains and build Epic structure inline.
Process:
Step 1: Auto-identify Domains
Use research context from Phase 1 Step 2:
  • If project docs found → Extract domains from requirements.md, architecture.md (module names, feature areas)
  • If HTML found → Extract domains from navigation, forms, page structures
  • Combine and deduplicate domains
  • Example: "User Auth" + "Profile Management" → "User Management"
Fallback: If no docs/HTML → Ask user basic questions (scope, objectives, functional areas)
Step 2: Build Epic List (inline)
IF Infrastructure needed (from Phase 1 Step 3):
  • Epic 0: Infrastructure & Operations — See
    shared/references/numbering_conventions.md#epic-0-content-template
  • Epic 1-N: Business domains (from Step 1)
ELSE:
  • Epic 1-N: Business domains only
Step 3: Determine Epic Count
  • Infrastructure Epic (if applicable): +1 Epic
  • Simple Initiative (1-3 domains): 3-4 Epics total
  • Medium Initiative (4-6 domains): 5-7 Epics total
  • Complex Initiative (7+ domains): 7-10 Epics total (rare)
  • Max 10 Epics per Initiative (enforced)
Step 4: Show Proposed Epic Structure (USER CONTROL POINT 1)
Display identified Epics with initiative-internal indexes:
📋 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
Step 5: User Confirmation
  • User types "confirm" → Proceed to Phase 3
  • User modifies → Update domain list, show again
Output: Approved Epic list (Epic 0-N or Epic 1-N) ready for next phase

目标: 识别逻辑领域并构建Epic结构。
流程:
步骤1:自动识别领域
使用阶段1步骤2的调研上下文:
  • 如果找到项目文档 → 从requirements.md、architecture.md提取领域(模块名称、功能区域)
  • 如果找到HTML → 从导航、表单、页面结构提取领域
  • 合并并去重领域
  • 示例:“用户认证” + “个人资料管理” → “用户管理”
备选方案: 如果没有文档/HTML → 询问用户基本问题(范围、目标、功能区域)
步骤2:构建Epic列表(内联)
如果需要基础设施(来自阶段1步骤3):
  • Epic 0:基础设施与运维 — 查看
    shared/references/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:
📋 提议的Epic结构:

Epic 0:基础设施与运维
Epic 1:用户管理
Epic 2:产品目录
Epic 3:购物车
Epic 4:支付处理
Epic 5:订单管理

总计:6个Epic
输入“confirm”继续,或修改列表
步骤5:用户确认
  • 用户输入“confirm” → 进入阶段3
  • 用户修改 → 更新领域列表,重新展示
输出: 已批准的Epic列表(Epic 0-N或Epic 1-N),准备进入下一阶段

Phase 3: Check Existing Epics

阶段3:检查现有Epic

Objective: Determine CREATE vs REPLAN mode.
Query kanban_board.md and Linear for existing Epics:
  1. Read Epic Story Counters table in kanban_board.md
  2. Count existing Epic rows (excludes header row)
Decision Point:
  • Count = 0 → No existing Epics → Proceed to Phase 4+5a (CREATE MODE)
  • Count ≥ 1 → Existing Epics found → Proceed to Phase 5b (REPLAN MODE)

目标: 确定是CREATE模式还是REPLAN模式。
查询kanban_board.md和Linear中的现有Epic:
  1. 读取kanban_board.md中的Epic故事计数器表格
  2. 统计现有Epic行数(排除表头行)
决策点:
  • 数量=0 → 无现有Epic → 进入阶段4+5a(CREATE模式)
  • 数量≥1 → 找到现有Epic → 进入阶段5b(REPLAN模式)

Phase 4: Epic Preparation (CREATE mode only)

阶段4:Epic准备(仅CREATE模式)

Trigger: Phase 3 determined Count = 0 (CREATE MODE)
Objective: Prepare all Epic documents before batch preview.
Step 1: Auto-extract Information for ALL Domains
For EACH domain (from Phase 2), extract answers to 5 key questions from project documentation:
  1. Q1: Business goal - Why this Epic/domain matters
    • Source: requirements.md (domain objectives section)
    • Extraction: "The [domain] module aims to..." or "Goal: [objective]"
    • Fallback: architecture.md (module purpose)
  2. Q2: Key features in scope - 3-5 bullet points of capabilities
    • Source: requirements.md (functional requirements for this domain)
    • Extraction: Bulleted lists under domain heading, feature descriptions
    • Fallback: architecture.md (component responsibilities)
  3. Q3: Out of scope - Prevent scope creep
    • Source: requirements.md (explicitly excluded features section)
    • Extraction: "Not in scope:", "Future versions:", "Out of scope for [domain]:"
    • Fallback: Infer from requirements.md (features NOT mentioned in domain)
  4. Q4: Success criteria - Measurable outcomes
    • Source: requirements.md (acceptance criteria, metrics, KPIs for domain)
    • Extraction: Performance targets, user metrics, quality gates
    • Fallback: Generic criteria based on domain type (e.g., "<200ms API response" for backend)
  5. Q5: Known risks (Optional) - Blockers, dependencies
    • Source: architecture.md (technical constraints, dependencies section)
    • Extraction: "Risks:", "Dependencies:", "Constraints:"
    • Fallback: User input if critical, otherwise leave as "To be determined during Story planning"
If extraction incomplete:
  • Show extracted information to user
  • Ask ONCE for ALL missing information across ALL domains (batch question, not per-domain)
  • Example: "For Epic 1 (User Management), I couldn't find success criteria. For Epic 2 (Payment), I couldn't find risks. Please provide..."
Step 2: Generate ALL Epic Documents
For EACH domain, generate complete Epic document using epic_template_universal.md:
Epic indexing:
  • IF Infrastructure Epic exists (from Phase 1 Step 3) → Epic 0 (Infrastructure), Epic 1-N (business domains)
  • ELSE → Epic 1-N (business domains only)
Linear Title (will be created in Phase 5a):
  • Use Next Epic Number from kanban_board.md for sequential numbering
  • Format: "Epic {Next Epic Number}: {Domain Title}"
  • Example: Next = 11 → "Epic 11: Infrastructure & Operations"
Sections: Goal, Scope In/Out, Success Criteria, Dependencies, Risks & Mitigations, Architecture Impact, Phases
Use extracted information from Step 1 for all sections
Output: All Epic documents ready (Epic 0-N), indexed within initiative

触发条件: 阶段3判定数量=0(CREATE模式)
目标: 在批量预览前准备所有Epic文档。
步骤1:为所有领域自动提取信息
针对每个领域(来自阶段2),从项目文档中提取以下5个关键问题的答案:
  1. 问题1:业务目标 - 该Epic/领域的重要性
    • 来源: requirements.md(领域目标章节)
    • 提取方式: “[领域]模块旨在...” 或 “目标:[目标内容]”
    • 备选方案: architecture.md(模块用途)
  2. 问题2:范围内的关键功能 - 3-5个功能要点
    • 来源: requirements.md(该领域的功能需求)
    • 提取方式: 领域标题下的项目符号列表、功能描述
    • 备选方案: architecture.md(组件职责)
  3. 问题3:范围外内容 - 防止范围蔓延
    • 来源: requirements.md(明确排除的功能章节)
    • 提取方式: “不在范围内:”、“未来版本:”、“[领域]不包含:”
    • 备选方案: 从requirements.md推断(领域中未提及的功能)
  4. 问题4:成功标准 - 可衡量的结果
    • 来源: requirements.md(该领域的验收标准、指标、KPI)
    • 提取方式: 性能目标、用户指标、质量门槛
    • 备选方案: 基于领域类型的通用标准(例如,后端的“API响应时间<200ms”)
  5. 问题5:已知风险(可选) - 障碍、依赖项
    • 来源: architecture.md(技术约束、依赖项章节)
    • 提取方式: “风险:”、“依赖项:”、“约束:”
    • 备选方案: 如果关键则询问用户,否则留为“用户故事规划阶段确定”
如果提取不完整:
  • 向用户展示已提取的信息
  • 一次性询问所有领域的缺失信息(批量问题,而非按领域询问)
  • 示例:“对于Epic 1(用户管理),我未找到成功标准。对于Epic 2(支付),我未找到风险信息。请提供..."
步骤2:生成所有Epic文档
针对每个领域,使用epic_template_universal.md生成完整的Epic文档:
Epic编号:
  • 如果存在基础设施Epic(来自阶段1步骤3) → Epic 0(基础设施)、Epic 1-N(业务领域)
  • 否则 → Epic 1-N(仅业务领域)
Linear标题(将在阶段5a中创建):
  • 使用kanban_board.md中的下一个Epic编号进行顺序编号
  • 格式:“Epic {下一个Epic编号}:{领域标题}”
  • 示例:下一个编号=11 → “Epic 11:基础设施与运维”
章节: 目标、范围内/外内容、成功标准、依赖项、风险与缓解措施、架构影响、阶段
使用步骤1提取的信息填充所有章节
输出: 所有Epic文档准备完毕(Epic 0-N),在计划内编号

Phase 5a: Epic Creation (CREATE mode)

阶段5a:Epic创建(CREATE模式)

Trigger: Phase 4 completed preparation
Objective: Show preview, get confirmation, create all Epics in Linear.
Step 1: Show Batch Preview (USER CONTROL POINT 2)
Display ALL generated Epics with initiative-internal indexes:
📋 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 in Linear
Step 2: User Confirmation
  • User types "confirm" → Proceed to Step 3
  • User provides feedback → Adjust documents in Phase 4, regenerate preview, repeat
Step 3: Create All Epics in Linear
For EACH Epic (in sequential order for numbering consistency):
  1. Get Next Epic Number:
    • Read current Next Epic Number from kanban_board.md
    • Example: 11
  2. Create Linear Project:
    • Title: "Epic {Next Epic Number}: {Domain Title}"
      • Example: "Epic 11: Infrastructure & Operations" (for Epic 0)
      • Example: "Epic 12: User Management" (for Epic 1)
    • Description: Complete Epic markdown (from Phase 4 Step 2)
    • Team: Team ID from Phase 1
    • State: "planned"
  3. Update kanban_board.md:
    • Increment Next Epic Number by 1 in Linear Configuration table
    • Add new row to Epic Story Counters:
      Epic {N} | - | US001 | - | EPN_01
    • Add to "Epics Overview" → Active:
      - [Epic {N}: Title](link) - Backlog
  4. Collect URL
Step 4: Display Summary
✅ 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
Output: Created Epic URLs + summary
TodoWrite format: Add Phase 1-5a todos + one todo per Epic + kanban update. Mark in_progress/completed.

触发条件: 阶段4完成准备工作
目标: 展示预览、获取确认、在Linear中创建所有Epic。
步骤1:展示批量预览(用户控制点2)
显示带有计划内索引的所有生成Epic:
📋 Epic批量预览(将创建6个Epic)

═══════════════════════════════════════════════
Epic 0:基础设施与运维
═══════════════════════════════════════════════
目标:建立基础架构、部署流水线和运维能力,以支持所有业务Epic

范围内:
- 日志和错误处理框架
- 监控和告警系统
- CI/CD流水线(GitHub Actions)
- 安全基线(密钥管理、加密)
- 性能优化(缓存、限流)

范围外:
- 应用特定的业务逻辑
- 用户面向的功能
- 领域特定的集成

成功标准:
- 所有部署通过CI/CD自动化(部署时间<10分钟)
- 系统可用性≥99.9%
- API响应时间<200ms(p95)
- 通过安全审计

═══════════════════════════════════════════════
Epic 1:用户管理
═══════════════════════════════════════════════
目标:支持用户安全注册、认证和管理账户

范围内:
- 带邮箱验证的用户注册
- 基于JWT的登录/登出
- 密码重置流程
- 个人资料管理

范围外:
- 社交登录(OAuth)- 计划在Epic 5中实现
- 多因素认证- 未来版本
- 用户角色与权限- 属于Epic 3的内容

成功标准:
- 用户注册耗时<2秒
- 登录成功率>98%
- 密码重置完成率>90%

[... 所有其他Epic ...]

───────────────────────────────────────────────
总计:6个Epic(Epic 0:基础设施,Epic 1-5:业务领域)
输入“confirm”在Linear中创建所有Epic
步骤2:用户确认
  • 用户输入“confirm” → 进入步骤3
  • 用户提供反馈 → 返回阶段4调整文档,重新生成预览,重复流程
步骤3:在Linear中创建所有Epic
针对每个Epic(按编号顺序以保证一致性):
  1. 获取下一个Epic编号:
    • 读取kanban_board.md中的当前下一个Epic编号
    • 示例:11
  2. 创建Linear项目:
    • 标题:“Epic {下一个Epic编号}:{领域标题}”
      • 示例:“Epic 11:基础设施与运维”(对应Epic 0)
      • 示例:“Epic 12:用户管理”(对应Epic 1)
    • 描述:完整的Epic markdown(来自阶段4步骤2)
    • 团队:来自阶段1的Team ID
    • 状态:“planned”
  3. 更新kanban_board.md:
    • 在Linear配置表中将下一个Epic编号加1
    • 向Epic故事计数器添加新行:
      Epic {N} | - | US001 | - | EPN_01
    • 添加到“Epics概览” → 活跃:
      - [Epic {N}:标题](链接) - 待办
  4. 收集URL
步骤4:展示摘要
✅ 为计划创建了6个Epic

已创建的Epic:
- Epic 11:基础设施与运维(Epic 0索引)[链接]
- Epic 12:用户管理(Epic 1索引)[链接]
- Epic 13:产品目录(Epic 2索引)[链接]
- Epic 14:购物车(Epic 3索引)[链接]
- Epic 15:支付处理(Epic 4索引)[链接]
- Epic 16:订单管理(Epic 5索引)[链接]

下一个Epic编号已更新为:17

下一步:
1. 使用ln-220-story-coordinator为每个Epic创建用户故事(运行6次)
2. 或使用ln-200-scope-decomposer自动完成Epic + 用户故事创建
输出: 已创建的Epic URL + 摘要
TodoWrite格式: 添加阶段1-5a的待办事项 + 每个Epic的待办事项 + 看板更新。标记进行中/已完成。

Phase 5b: Replan Mode (Existing Epics Found)

阶段5b:重新规划模式(找到现有Epic)

Trigger: Phase 3 determined Count ≥ 1 (REPLAN MODE)
Full workflow: See
references/replan_workflow.md
for complete REPLAN process.
Summary:
  1. Load existing Epics from Linear (full descriptions)
  2. Compare IDEAL plan vs existing → Categorize: KEEP/UPDATE/OBSOLETE/CREATE
  3. Show replan summary with diffs and warnings
  4. User confirmation required
  5. Execute operations in Linear + update kanban_board.md
Constraints: Never auto-update/archive Epics with Stories In Progress. Never delete (use archived). Always require confirmation.

触发条件: 阶段3判定数量≥1(REPLAN模式)
完整工作流程: 查看
references/replan_workflow.md
获取完整的重新规划流程。
摘要:
  1. 从Linear加载现有Epic(完整描述)
  2. 对比理想计划与现有计划 → 分类:保留/更新/废弃/创建
  3. 展示包含差异和警告的重新规划摘要
  4. 需要用户确认
  5. 在Linear中执行操作 + 更新kanban_board.md
约束: 永远不要自动更新/归档包含进行中用户故事的Epic。永远不要删除(使用归档)。始终需要用户确认。

Definition of Done

完成定义

Before completing work, verify ALL checkpoints:
✅ Discovery Complete (Phase 1):
  • Team ID loaded from kanban_board.md
  • Next Epic Number loaded from kanban_board.md
  • Documentation scanned (requirements.md, architecture.md, tech_stack.md)
  • HTML files scanned (if frontend exists)
  • Infrastructure Epic decision made (YES/NO based on project conditions)
✅ Scope Analysis Complete (Phase 2):
  • Domains auto-identified from docs + HTML
  • Infrastructure Epic (Epic 0) included if applicable
  • Epic list built (Epic 0-N or Epic 1-N)
  • User confirmed Epic structure (CONTROL POINT 1)
✅ Existing Epics Checked (Phase 3):
  • Epic Story Counters read from kanban_board.md
  • Existing Epic count determined (0 → CREATE, ≥1 → REPLAN)
✅ Epic Preparation Complete (Phase 4 - CREATE only):
  • Q1-Q5 auto-extracted for ALL domains
  • User provided missing information if needed (batch question)
  • ALL Epic documents generated (Epic 0-N indexes)
✅ Epic Creation Complete (Phase 5a - CREATE only):
  • Batch preview shown with Epic 0-N indexes
  • User confirmed preview (CONTROL POINT 2)
  • ALL Epics created in Linear with "Epic {N}: {Title}" format (N = Next Epic Number)
  • kanban_board.md updated after EACH Epic:
    • Next Epic Number incremented by 1
    • Epic Story Counters row added
    • Epics Overview updated
  • Summary displayed with all Epic URLs
✅ Epic Replan Complete (Phase 5b - REPLAN only):
  • See
    references/replan_workflow.md
    for full checklist
Output: List of Linear Project URLs (Epic {N}: {Title}) + Next Epic Number value

完成工作前,验证所有检查点:
✅ 发现阶段完成(阶段1):
  • 从kanban_board.md加载Team ID
  • 从kanban_board.md加载下一个Epic编号
  • 已扫描文档(requirements.md、architecture.md、tech_stack.md)
  • 已扫描HTML文件(如果存在前端)
  • 已做出基础设施Epic决策(根据项目条件选择YES/NO)
✅ 范围分析完成(阶段2):
  • 从文档和HTML中自动识别领域
  • 如适用,已包含基础设施Epic(Epic 0)
  • 已构建Epic列表(Epic 0-N或Epic 1-N)
  • 用户已确认Epic结构(控制点1)
✅ 现有Epic检查完成(阶段3):
  • 已读取kanban_board.md中的Epic故事计数器
  • 已确定现有Epic数量(0→CREATE,≥1→REPLAN)
✅ Epic准备完成(阶段4 - 仅CREATE模式):
  • 已为所有领域自动提取问题1-5的信息
  • 如需要,用户已提供缺失信息(批量问题)
  • 已生成所有Epic文档(Epic 0-N索引)
✅ Epic创建完成(阶段5a - 仅CREATE模式):
  • 已展示带有Epic 0-N索引的批量预览
  • 用户已确认预览(控制点2)
  • 所有Epic已在Linear中创建,格式为“Epic {N}:{标题}”(N=下一个Epic编号)
  • 每个Epic创建后已更新kanban_board.md:
    • 下一个Epic编号加1
    • 添加Epic故事计数器行
    • 更新Epics概览
  • 已展示包含所有Epic URL的摘要
✅ Epic重新规划完成(阶段5b - 仅REPLAN模式):
  • 查看
    references/replan_workflow.md
    获取完整检查清单
输出: Linear项目URL列表(Epic {N}:{标题}) + 下一个Epic编号值

Example Usage

使用示例

Request: "Create epics for e-commerce platform"
Flow: Phase 1 (discover Team ID=Product, Next=11, scan docs+HTML) → Phase 2 (identify 6 domains: Infrastructure, User, Products, Cart, Payment, Orders) → Phase 3 (count=0 → CREATE) → Phase 4 (auto-extract Q1-Q5, generate docs) → Phase 5a (preview, confirm, create in Linear: Epic 11-16)
Result: 6 Epics created (Epic 0-5 internal indexes, Epic 11-16 Linear titles)

请求: “为电商平台创建Epic”
流程: 阶段1(发现Team ID=Product,下一个编号=11,扫描文档+HTML)→ 阶段2(识别6个领域:基础设施、用户、产品、购物车、支付、订单)→ 阶段3(数量=0→CREATE)→ 阶段4(自动提取问题1-5的信息,生成文档)→ 阶段5a(预览、确认、在Linear中创建:Epic 11-16)
结果: 创建6个Epic(计划内索引为Epic 0-5,Linear标题为Epic 11-16)

Reference Files

参考文件

  • [MANDATORY] Problem-solving approach:
    shared/references/problem_solving.md
  • Orchestrator lifecycle:
    shared/references/orchestrator_pattern.md
  • Auto-discovery patterns:
    shared/references/auto_discovery_pattern.md
  • Decompose-first pattern:
    shared/references/decompose_first_pattern.md
  • Numbering conventions:
    shared/references/numbering_conventions.md
    (Epic 0 reserved, Linear numbering)
  • Linear creation workflow:
    shared/references/linear_creation_workflow.md
  • linear_integration.md: Discovery patterns + Linear API reference (moved to
    shared/templates/linear_integration.md
    )
  • epic_template_universal.md: Epic template structure
  • replan_workflow.md: Complete REPLAN mode workflow (Phase 5b)

  • [必读] 问题解决方法:
    shared/references/problem_solving.md
  • 协调器生命周期:
    shared/references/orchestrator_pattern.md
  • 自动发现模式:
    shared/references/auto_discovery_pattern.md
  • 先分解模式:
    shared/references/decompose_first_pattern.md
  • 编号规范:
    shared/references/numbering_conventions.md
    (Epic 0预留、Linear编号)
  • Linear创建工作流程:
    shared/references/linear_creation_workflow.md
  • linear_integration.md: 发现模式 + Linear API参考(已移至
    shared/templates/linear_integration.md
  • epic_template_universal.md: Epic模板结构
  • replan_workflow.md: 完整的重新规划模式工作流程(阶段5b)

Best Practices

最佳实践

  • Research first: Scan docs (requirements.md, architecture.md, tech_stack.md) + HTML before asking user
  • Epic 0 for Infrastructure: Reserved index for Infrastructure Epic; business domains start from Epic 1
  • Business Epic grouping: 1 Epic = 5-10 Stories = 1 business capability (not technical components)
  • Auto-extraction: Extract Q1-Q5 from docs before asking user; ask only for missing info
  • Linear Title: "Epic {Next Epic Number}: {Domain}" format
  • Business-focused Scope: List USER CAPABILITIES, not technical tasks
  • Measurable criteria: "<200ms" not "fast"; ">98% login rate" not "reliable"
  • No code snippets: High-level features and goals only

Version: 7.0.0 Last Updated: 2025-11-20
  • 先调研: 在询问用户前,先扫描文档(requirements.md、architecture.md、tech_stack.md)和HTML
  • 基础设施使用Epic 0: 预留索引用于基础设施Epic;业务领域从Epic 1开始
  • 业务Epic分组: 1个Epic=5-10个用户故事=1个业务能力(而非技术组件)
  • 自动提取: 在询问用户前先从文档提取问题1-5的信息;仅询问缺失的信息
  • Linear标题: 使用“Epic {下一个Epic编号}:{领域}”格式
  • 业务聚焦的范围: 列出用户能力,而非技术任务
  • 可衡量的标准: 使用“<200ms”而非“快”;使用“>98%登录成功率”而非“可靠”
  • 无代码片段: 仅包含高级功能和目标

版本: 7.0.0 最后更新: 2025-11-20