Back to Details

ln-220-story-coordinator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Story Coordinator

Story 协调器

Universal Story management coordinator that delegates CREATE/REPLAN operations to specialized workers after building IDEAL Story plan.
通用Story管理协调器，在构建完理想的Story计划后，将创建/重新规划操作委托给专用处理模块。

When to Use This Skill

何时使用此技能

Use when:
  • Decompose Epic to User Stories (5-10 Stories covering Epic scope)
  • Update existing Stories when Epic requirements change
  • Rebalance Story scopes within Epic
  • Add new Stories to existing Epic structure
适用于以下场景：
  • 将Epic分解为用户Story（5-10个，覆盖Epic全部范围）
  • 当Epic需求变更时更新现有Story
  • 重新平衡Epic内的Story范围
  • 向现有Epic结构中添加新Story

Core Pattern: Decompose-First

核心模式：先分解

Key principle: Build IDEAL Story plan FIRST, THEN check existing Stories to determine mode:
  • No existing Stories → CREATE MODE (delegate to ln-221-story-creator)
  • Has existing Stories → REPLAN MODE (delegate to ln-222-story-replanner)
Rationale: Ensures consistent Story decomposition based on current Epic requirements, independent of existing Story structure (may be outdated).
核心原则： 先构建理想的Story计划，再检查现有Story以确定执行模式：
  • 无现有Story → 创建模式（委托给ln-221-story-creator）
  • 存在现有Story → 重新规划模式（委托给ln-222-story-replanner）
设计理由： 确保基于当前Epic需求进行一致的Story分解，不受可能已过时的现有Story结构影响。

Story Numbering Convention

Story编号规范

MANDATORY READ: Load 
shared/references/numbering_conventions.md
for Story numbering rules (US001 sequential across Epics, no Story 0).
必读要求： 加载
shared/references/numbering_conventions.md
查看Story编号规则（US001跨Epic连续编号，无Story 0）。

How It Works

工作流程

Phase 1: Context Assembly

阶段1：上下文收集

Objective: Gather context for Story planning (Epic details, planning questions, frontend context, fallback docs, user input)
Step 1: Discovery (Automated)
Auto-discovers from 
docs/tasks/kanban_board.md
:
  1. Team ID: Reads Linear Configuration table
  2. Epic: Parses Epic number from request → Validates in Linear → Loads Epic description
    • User format: "Epic N" (Linear Project number, e.g., "Epic 7: OAuth Authentication")
    • Query: 
      get_project(query="Epic N")
      → Fetch full Epic document
    • Extract: Goal, Scope In/Out, Success Criteria, Technical Notes (Standards Research if Epic created by ln-210 v7.0.0+)
    • Note: Epic N = Linear Project number (global), NOT initiative-internal index (Epic 0-N)
  3. Next Story Number: Reads Epic Story Counters table → Gets next sequential number
Step 2: Extract Planning Information (Automated)
Parses Epic structure for Story planning questions:
QuestionExtraction Source
Q1 - User/PersonaEpic Goal ("Enable [persona]...") + Scope In (user roles)
Q2 - What they wantEpic Scope In (capabilities) + functional requirements
Q3 - Why it mattersEpic Success Criteria (metrics) + Goal (business value)
Q4 - Which EpicAlready from Step 1
Q5 - Main ACDerive from Epic Scope In features → testable scenarios
Q6 - Application typeEpic Technical Notes (UI/API mentioned) → Default: API
Step 3: Frontend Research (Optional)
Trigger: If Q2 (capabilities) OR Q5 (AC) missing after Step 2
Process:
  1. Scan HTML files: 
    Glob
    **/*.html
    , 
    src/**/*.html
  2. Extract:
    • Forms → AC scenarios (e.g., 
      <form id="login">
      → "Given valid credentials, When submit, Then login success")
    • Buttons/Actions → capabilities (e.g., 
      <button id="register">
      → "User registration")
    • Validation rules → edge case AC (e.g., 
      minlength="8"
      → "Given password <8 chars, Then error")
  3. Combine with Epic context, deduplicate, prioritize Epic AC if conflict
Fallback: If no HTML → Skip to Step 4
Step 4: Fallback Search Chain
Objective: Fill missing Q1-Q6 BEFORE asking user.
For each question with no answer from Step 2-3:
QuestionFallback Search
Q1 (User/Persona)Search 
requirements.md
for "User personas", "Actors" → Default "User" if not found
Q3 (Why it matters)Search 
requirements.md
for "Business objectives", "Goals" → Infer from Epic Success Criteria
Q6 (Application type)Search 
tech_stack.md
for "Frontend", "Backend", "API" → Default "API"
Skip: Q2, Q5 (Epic + HTML are sources of truth), Q4 (already known)
Step 5: User Input (Only if Missing)
If still missing after Step 2 + 3 + 4:
  • Show extracted: "From Epic: [Epic info]. From HTML: [HTML info]. From fallback: [fallback info]"
  • Ask user to confirm or provide remaining missing details
If all questions answered from Epic OR HTML OR fallback: Skip user prompts, proceed to Phase 2
Output: Complete context (Epic details, next Story number, Q1-Q6 answers)
目标： 收集Story规划所需的上下文信息（Epic详情、规划问题、前端上下文、备用文档、用户输入）
步骤1：自动发现
从
docs/tasks/kanban_board.md
自动发现以下信息：
  1. 团队ID： 读取Linear配置表
  2. Epic信息： 从请求中解析Epic编号 → 在Linear中验证 → 加载Epic描述
    • 用户输入格式： "Epic N"（Linear项目编号，例如"Epic 7: OAuth Authentication"）
    • 查询方式： 
      get_project(query="Epic N")
      → 获取完整Epic文档
    • 提取内容： 目标、包含/排除范围、成功标准、技术说明（若Epic由ln-210 v7.0.0+创建，需包含标准研究内容）
    • 注意： Epic N为全局Linear项目编号，而非倡议内部索引（Epic 0-N）
  3. 下一个Story编号： 读取Epic Story计数器表 → 获取下一个连续编号
步骤2：自动提取规划信息
解析Epic结构以获取Story规划所需的问题答案：
问题提取来源
Q1 - 用户/角色Epic目标（"为[角色]提供..."） + 包含范围（用户角色）
Q2 - 用户需求Epic包含范围（功能） + 功能需求
Q3 - 业务价值Epic成功标准（指标） + 目标（商业价值）
Q4 - 所属Epic已从步骤1获取
Q5 - 核心验收标准（AC）从Epic包含范围的功能推导 → 可测试场景
Q6 - 应用类型Epic技术说明（提及UI/API） → 默认值：API
步骤3：前端研究（可选）
触发条件： 步骤2后Q2（功能）或Q5（AC）仍缺失
流程：
  1. 扫描HTML文件：使用
    Glob
    匹配
    **/*.html
    、
    src/**/*.html
  2. 提取内容：
    • 表单 → AC场景（例如
      <form id="login">
      → "给定有效凭证，当提交时，登录成功"）
    • 按钮/操作 → 功能（例如
      <button id="register">
      → "用户注册"）
    • 验证规则 → 边界场景AC（例如
      minlength="8"
      → "给定密码长度<8位，显示错误"）
  3. 与Epic上下文合并，去重，若存在冲突则优先采用Epic的AC
备用方案： 若无HTML文件 → 跳至步骤4
步骤4：备用搜索链
目标： 在询问用户前填充Q1-Q6中缺失的信息
针对步骤2-3后仍无答案的问题：
问题备用搜索来源
Q1（用户/角色）在
requirements.md
中搜索"User personas"、"Actors" → 若未找到则默认"User"
Q3（业务价值）在
requirements.md
中搜索"Business objectives"、"Goals" → 从Epic成功标准推导
Q6（应用类型）在
tech_stack.md
中搜索"Frontend"、"Backend"、"API" → 默认值：API
跳过： Q2、Q5（Epic + HTML为权威来源），Q4（已明确）
步骤5：用户输入（仅当信息仍缺失时）
若步骤2+3+4后仍有缺失：
  • 展示已提取信息："来自Epic：[Epic信息]。来自HTML：[HTML信息]。来自备用搜索：[备用信息]"
  • 请求用户确认或补充剩余缺失的细节
若所有问题已从Epic/HTML/备用搜索得到答案： 跳过用户提示，进入阶段2
输出： 完整的上下文信息（Epic详情、下一个Story编号、Q1-Q6答案）

Phase 2: Standards Research (Delegated)

阶段2：标准研究（委托）

Objective: Research industry standards/patterns BEFORE Story generation to ensure implementation follows best practices.
Why: Prevents outdated patterns or RFC violations (e.g., OAuth without PKCE).
Process:
  1. Parse Epic for domain keywords: Extract domain from Epic goal/Scope In (authentication, rate limiting, payments)
  2. Delegate to ln-001-standards-researcher:
    • Call 
      Skill(skill: "ln-001-standards-researcher", epic_description="[Epic full description]", story_domain="[domain]")
    • Wait for Standards Research (Markdown string)
  3. Store: Cache for Phase 5a/5b (workers insert in Story Technical Notes)
Output: Standards Research stored for ALL Stories in Epic
Skip conditions:
  • Epic has NO standards in Technical Notes
  • Story domain is trivial CRUD
  • Epic says "research not needed"
Time-box: 15-20 minutes (handled by ln-001)
Note: Research done ONCE per Epic, results reused for all Stories (5-10 Stories benefit from single research)
目标： 在生成Story前研究行业标准/模式，确保实现遵循最佳实践。
原因： 避免使用过时模式或违反RFC规范（例如OAuth未使用PKCE）。
流程：
  1. 解析Epic的领域关键词： 从Epic目标/包含范围提取领域（认证、限流、支付等）
  2. 委托给ln-001-standards-researcher：
    • 调用
      Skill(skill: "ln-001-standards-researcher", epic_description="[完整Epic描述]", story_domain="[领域]")
    • 等待标准研究结果（Markdown字符串）
  3. 存储： 缓存结果供阶段5a/5b使用（处理模块会将其插入Story技术说明）
输出： 为Epic中所有Story存储的标准研究结果
跳过条件：
  • Epic技术说明中无标准相关内容
  • Story领域为简单CRUD操作
  • Epic明确标注"无需研究"
时间限制： 15-20分钟（由ln-001处理）
注意： 每个Epic仅执行一次研究，结果可复用给所有Story（5-10个Story共享单次研究成果）

Phase 3: Planning

阶段3：规划

Objective: Build IDEAL Story plan, determine execution mode
Story Grouping Guidelines:
Each Story = ONE vertical slice of user capability (end-to-end: UI → API → Service → DB).
✅ GOOD Story Grouping (1 Story = 1 user journey):
  • ✅ "User registration" (form → validation → API → database → email)
  • ✅ "Password reset" (request link → verify token → set password → update DB)
  • ✅ "Product search" (input → filter/sort → API → DB query → display)
❌ BAD Story Grouping (horizontal slices):
  • ❌ "Create user table" (database only, no user value → Task, not Story)
  • ❌ "User registration API endpoint" (API layer only, not vertical)
  • ❌ "Registration UI form" (frontend only, not vertical)
Rule: 1 Story = 1 user capability = 3-5 AC = 6-20 hours = 10-28 tests
Database Creation Principle (Incremental Schema Evolution):
Each Story creates ONLY the tables it needs (not all tables upfront).
✅ GOOD (Incremental):
  • ✅ "User registration" → Creates Users table
  • ✅ "Product search" → Creates Products table
  • ✅ "Order checkout" → Creates Orders, Payments tables
❌ BAD (Big-Bang):
  • ❌ "Setup database" → Creates all 50 tables (no user value, violates vertical slicing)
  • ❌ "Database schema" → Creates Users, Products, Orders, Payments upfront
Rationale: Big-bang database setup violates incremental delivery. Each Story should deliver user value, not technical infrastructure.
Build IDEAL Plan (Automated):
  1. Analyze Epic Scope: Review features in Epic Scope In, identify user capabilities
  2. Determine Story Count:
    • Simple Epic (1-3 features): 3-5 Stories
    • Medium Epic (4-7 features): 6-8 Stories
    • Complex Epic (8+ features): 8-10 Stories
    • Max 10 Stories per Epic
  3. Story Size Guidelines:
CriterionMinMaxUnder-decomposedOver-decomposed
AC35>5 AC (split)<3 AC (merge)
Duration6h20h>20h (split)<6h (merge)
Tests1028>28 tests (split)<10 tests (merge)
Over-decomposition indicators:
  • ❌ <3 AC, <6 hours, <10 tests
  • ❌ Purely technical (no user value)
  • ❌ Title starts with "Add", "Create", "Update" (likely Task)
  • ❌ Crosses only 1-2 layers (not vertical)
  1. Build IDEAL Plan "in mind":
    • Each Story: persona + capability + business value
    • Each Story: 3-5 testable AC (Given-When-Then)
    • Stories ordered by dependency
    • Each Story: Test Strategy section exists but is empty (tests planned later by ln-510-test-planner)
    • Each Story: Technical Notes (architecture, integrations, Standards Research from Phase 2, guide links)
  2. AC Quality Validation (CRITICAL - delegates to workers):
Workers (ln-221, ln-222) must validate AC quality:
Completeness Check (3 scenario types required):
  • ✅ Happy Path (1-2 AC): main success scenarios
  • ✅ Error Handling (1-2 AC): invalid inputs, auth failures, system errors
  • ✅ Edge Cases (1 AC): boundary conditions, special states, race conditions
Example: ❌ BAD: "User can login" (only happy path) ✅ GOOD:
  • AC1: Valid credentials → login success (happy path)
  • AC2: Invalid password → 401 error (error handling)
  • AC3: Account locked → 403 error (edge case)
Specificity Check (measurable outcomes required):
  • ✅ HTTP status codes (200, 401, 403, 404)
  • ✅ Measurable performance (<200ms, 99% uptime)
  • ✅ Exact error messages ("Invalid credentials")
Example: ❌ BAD: "Login should be fast" (vague) ✅ GOOD: "Then receive token <200ms" (measurable)
INVEST Checklist:
CriterionCheck✅ GOOD❌ BAD
IndependentCan develop/deploy without blocking others + NO forward dependencies"Request OAuth token" (Story N uses only N-1)"Validate token depends on Story N+2 refresh flow" (forward dependency!)
NegotiableAC focus on WHAT, not HOW"User gets valid token" (what)"Use authlib 1.3.0, store in Redis" (how)
ValuableClear business value"User refreshes expired token to maintain session""Add token_refresh table" (no user value)
EstimableCan estimate 6-20hClear scope, known patterns, researched standards"Implement authentication" (too vague)
SmallFits 1-2 sprints3-5 AC, 6-20h"Full OAuth flow" (>5 AC, >20h)
TestableAC measurable"Given valid refresh token, Then receive token <200ms""Token refresh should be fast" (not measurable)
Output: IDEAL Story plan (5-10 Stories) with titles, statements, core AC, ordering
目标： 构建理想的Story计划，确定执行模式
Story分组指南：
每个Story = 一个用户功能的垂直切片（端到端：UI → API → 服务 → 数据库）。
✅ 合理的Story分组（1个Story = 1个用户旅程）：
  • ✅ "用户注册"（表单 → 验证 → API → 数据库 → 邮件）
  • ✅ "密码重置"（请求链接 → 验证令牌 → 设置密码 → 更新数据库）
  • ✅ "产品搜索"（输入 → 筛选/排序 → API → 数据库查询 → 展示）
❌ 不合理的Story分组（水平切片）：
  • ❌ "创建用户表"（仅数据库操作，无用户价值 → 属于任务，非Story）
  • ❌ "用户注册API端点"（仅API层，非垂直切片）
  • ❌ "注册UI表单"（仅前端，非垂直切片）
规则： 1个Story = 1个用户功能 = 3-5条AC = 6-20小时工作量 = 10-28个测试用例
数据库创建原则（增量 schema 演进）：
每个Story仅创建自身所需的表（而非提前创建所有表）。
✅ 合理方式（增量）：
  • ✅ "用户注册" → 创建Users表
  • ✅ "产品搜索" → 创建Products表
  • ✅ "订单结算" → 创建Orders、Payments表
❌ 不合理方式（大爆炸式）：
  • ❌ "设置数据库" → 创建全部50张表（无用户价值，违反垂直切片原则）
  • ❌ "数据库schema" → 提前创建Users、Products、Orders、Payments表
设计理由： 大爆炸式数据库设置违反增量交付原则。每个Story应交付用户价值，而非仅技术基础设施。
构建理想计划（自动化）：
  1. 分析Epic范围： 回顾Epic包含范围的功能，识别用户功能
  2. 确定Story数量：
    • 简单Epic（1-3个功能）：3-5个Story
    • 中等Epic（4-7个功能）：6-8个Story
    • 复杂Epic（8+个功能）：8-10个Story
    • 每个Epic最多10个Story
  3. Story规模指南：
标准最小值最大值分解不足过度分解
AC数量35>5条AC（需拆分）<3条AC（需合并）
工作量6h20h>20h（需拆分）<6h（需合并）
测试用例数1028>28个测试用例（需拆分）<10个测试用例（需合并）
过度分解的迹象：
  • ❌ <3条AC、<6小时工作量、<10个测试用例
  • ❌ 纯技术任务（无用户价值）
  • ❌ 标题以"Add"、"Create"、"Update"开头（大概率为任务）
  • ❌ 仅涉及1-2个层级（非垂直切片）
  1. 构建理想计划：
    • 每个Story：角色 + 功能 + 商业价值
    • 每个Story：3-5条可测试AC（Given-When-Then格式）
    • Story按依赖关系排序
    • 每个Story：包含测试策略部分但为空（测试用例后续由ln-510-test-planner规划）
    • 每个Story：技术说明（架构、集成、阶段2的标准研究结果、指南链接）
  2. AC质量验证（关键 - 由处理模块执行）：
处理模块（ln-221、ln-222）必须验证AC质量：
完整性检查（需包含3种场景类型）：
  • ✅ 正常流（1-2条AC）：主要成功场景
  • ✅ 错误处理（1-2条AC）：无效输入、认证失败、系统错误
  • ✅ 边界场景（1条AC）：边界条件、特殊状态、竞争条件
示例： ❌ 不合理："用户可以登录"（仅包含正常流） ✅ 合理：
  • AC1：给定有效凭证，登录成功（正常流）
  • AC2：给定无效密码，返回401错误（错误处理）
  • AC3：给定锁定账户，返回403错误（边界场景）
具体性检查（需可衡量结果）：
  • ✅ HTTP状态码（200、401、403、404）
  • ✅ 可衡量性能（<200ms、99%可用性）
  • ✅ 精确错误信息（"Invalid credentials"）
示例： ❌ 不合理："登录速度应快"（模糊） ✅ 合理："在200ms内收到令牌"（可衡量）
INVEST checklist：
标准检查内容✅ 合理❌ 不合理
独立性可独立开发/部署，无前置依赖"请求OAuth令牌"（Story N仅依赖N-1）"令牌验证依赖Story N+2的刷新流程"（存在前置依赖！）
可协商性AC聚焦于做什么，而非怎么做"用户获取有效令牌"（做什么）"使用authlib 1.3.0，存储在Redis"（怎么做）
价值性明确商业价值"用户刷新过期令牌以维持会话""添加token_refresh表"（无用户价值）
可估算性可估算6-20小时工作量范围明确、模式已知、标准已研究"实现认证功能"（过于模糊）
规模适中可在1-2个迭代内完成3-5条AC、6-20小时工作量"完整OAuth流程"（>5条AC、>20小时）
可测试性AC可衡量"给定有效刷新令牌，在200ms内收到新令牌""令牌刷新速度应快"（不可衡量）
输出： 理想的Story计划（5-10个Story），包含标题、描述、核心AC、排序

Phase 4: Check Existing & Detect Mode

阶段4：检查现有Story并确定模式

Objective: Determine execution mode based on existing Stories AND user intent
Process:
Query Linear for existing Stories in Epic:
list_issues(project=Epic.id, label="user-story")
Mode Detection:
  1. Analyze user request for keywords:
    • ADD keywords: "add story", "one more story", "additional story", "append"
    • REPLAN keywords: "update plan", "revise", "requirements changed", "replan stories"
  2. Decision matrix:
ConditionModeDelegate To
Count = 0CREATEPhase 5a: ln-221-story-creator
Count ≥ 1 AND ADD keywordsADDPhase 5c: ln-221-story-creator (appendMode)
Count ≥ 1 AND REPLAN keywordsREPLANPhase 5b: ln-222-story-replanner
Count ≥ 1 AND ambiguousASK USER"Add new Story or revise the plan?"
Important: Orchestrator loads metadata ONLY (ID, title, status). Workers load FULL descriptions (token efficiency).
Output: Execution mode determined + existingCount for workers
目标： 根据现有Story和用户意图确定执行模式
流程：
查询Linear中该Epic下的现有Story：
list_issues(project=Epic.id, label="user-story")
模式检测：
  1. 分析用户请求的关键词：
    • 添加类关键词："add story"、"one more story"、"additional story"、"append"
    • 重新规划类关键词："update plan"、"revise"、"requirements changed"、"replan stories"
  2. 决策矩阵：
条件模式委托对象
现有Story数量=0创建模式阶段5a：ln-221-story-creator
现有Story数量≥1且包含添加类关键词添加模式阶段5c：ln-221-story-creator（appendMode）
现有Story数量≥1且包含重新规划类关键词重新规划模式阶段5b：ln-222-story-replanner
现有Story数量≥1且意图模糊询问用户"添加新Story还是修改现有计划？"
重要提示： 协调器仅加载元数据（ID、标题、状态）。处理模块加载完整描述（提升令牌效率）。
输出： 确定的执行模式 + 现有Story数量（供处理模块使用）

Phase 5a: Delegate CREATE (No Existing Stories)

阶段5a：委托创建模式（无现有Story）

Trigger: Epic has no Stories yet (first decomposition)
Delegation:
Call ln-221-story-creator via Skill tool:
javascript
Skill(
  skill: "ln-221-story-creator",
  epicData: {id, title, description},
  idealPlan: [ /* 5-10 Stories from Phase 3 */ ],
  standardsResearch: "Standards Research from Phase 2",
  teamId: "team-id",
  autoApprove: false  // or true for automation
)
Worker handles:
  • Generate Story documents (8 sections, insert Standards Research)
  • Validate INVEST criteria
  • Show preview
  • User confirmation (if autoApprove=false)
  • Create in Linear (project=Epic, labels=user-story, state=Backlog)
  • Update kanban_board.md (Epic Grouping Algorithm)
Output: Created Story URLs + summary from worker
触发条件： Epic尚无Story（首次分解）
委托方式：
通过Skill工具调用ln-221-story-creator：
javascript
Skill(
  skill: "ln-221-story-creator",
  epicData: {id, title, description},
  idealPlan: [ /* 阶段3的5-10个Story */ ],
  standardsResearch: "阶段2的标准研究结果",
  teamId: "team-id",
  autoApprove: false  // 自动化场景设为true
)
处理模块负责：
  • 生成Story文档（8个部分，插入标准研究结果）
  • 验证INVEST标准
  • 展示预览
  • 用户确认（若autoApprove=false）
  • 在Linear中创建（项目=Epic，标签=user-story，状态=Backlog）
  • 更新kanban_board.md（Epic分组算法）
输出： 已创建的Story链接 + 处理模块返回的摘要

Phase 5b: Delegate REPLAN (Existing Stories Found)

阶段5b：委托重新规划模式（存在现有Story）

Trigger: Epic already has Stories (requirements changed)
Delegation:
Call ln-222-story-replanner via Skill tool:
javascript
Skill(
  skill: "ln-222-story-replanner",
  epicData: {id, title, description},
  idealPlan: [ /* 5-10 Stories from Phase 3 */ ],
  standardsResearch: "Standards Research from Phase 2",
  existingCount: N,
  teamId: "team-id",
  autoApprove: false  // or true for automation
)
Worker handles:
  • Load existing Stories (Progressive Loading: ONE BY ONE for token efficiency)
  • Compare IDEAL vs existing (KEEP/UPDATE/OBSOLETE/CREATE operations)
  • Show replan summary with diffs (AC, Standards Research, Technical Notes)
  • User confirmation (if autoApprove=false)
  • Execute operations (respecting status constraints: Backlog/Todo only, warnings for In Progress/Review/Done)
  • Update kanban_board.md (add NEW Stories only via Epic Grouping Algorithm)
Output: Operation results + warnings + affected Story URLs from worker
触发条件： Epic已有Story（需求变更）
委托方式：
通过Skill工具调用ln-222-story-replanner：
javascript
Skill(
  skill: "ln-222-story-replanner",
  epicData: {id, title, description},
  idealPlan: [ /* 阶段3的5-10个Story */ ],
  standardsResearch: "阶段2的标准研究结果",
  existingCount: N,
  teamId: "team-id",
  autoApprove: false  // 自动化场景设为true
)
处理模块负责：
  • 加载现有Story（渐进式加载：逐个加载以提升令牌效率）
  • 对比理想计划与现有Story（确定保留/更新/废弃/创建操作）
  • 展示重新规划摘要及差异（AC、标准研究、技术说明）
  • 用户确认（若autoApprove=false）
  • 执行操作（遵循状态约束：仅操作Backlog/Todo状态的Story，对In Progress/Review/Done状态的Story发出警告）
  • 更新kanban_board.md（仅通过Epic分组算法添加新Story）
输出： 操作结果 + 警告信息 + 受影响的Story链接

Phase 5c: Delegate ADD (Append to Existing Stories)

阶段5c：委托添加模式（向现有Story中追加）

Trigger: Epic has Stories, user wants to ADD more (not replan existing)
Delegation:
Call ln-221-story-creator via Skill tool with appendMode:
javascript
Skill(
  skill: "ln-221-story-creator",
  appendMode: true,  // ADD to existing, don't replace
  epicData: {id, title, description},
  newStoryDescription: userRequestedStory,  // Single Story from user request
  standardsResearch: "Standards Research from Phase 2",
  teamId: "team-id",
  autoApprove: false
)
Key differences from CREATE MODE:
  • appendMode: true
    → Skip full IDEAL plan, create only requested Story
  • newStoryDescription
    → User's specific request (e.g., "add authorization Story")
  • Does NOT require Phase 3 IDEAL plan for all Stories
  • Preserves existing Stories without comparison
Worker handles:
  • Research standards for NEW Story only
  • Generate Story document (8 sections)
  • Validate INVEST criteria
  • Create in Linear (append to existing)
  • Update kanban_board.md
Output: Created Story URL + summary from worker
TodoWrite format (mandatory): Add phases to todos before starting:
- Phase 1: Context Assembly (in_progress)
- Phase 2: Standards Research via ln-221 (pending)
- Phase 3: Build IDEAL Story Plan (pending)
- Phase 4: Check Existing Stories (pending)
- Phase 5: Delegate to ln-222/ln-223 (pending)
- Wait for worker result (pending)
Mark each as in_progress when starting, completed when done.
触发条件： Epic已有Story，用户希望添加新Story（不修改现有内容）
委托方式：
通过Skill工具调用ln-221-story-creator并设置appendMode：
javascript
Skill(
  skill: "ln-221-story-creator",
  appendMode: true,  // 追加到现有Story，不替换
  epicData: {id, title, description},
  newStoryDescription: userRequestedStory,  // 用户请求的单个Story
  standardsResearch: "阶段2的标准研究结果",
  teamId: "team-id",
  autoApprove: false
)
与创建模式的核心差异：
  • appendMode: true
    → 跳过完整理想计划，仅创建用户请求的Story
  • newStoryDescription
    → 用户的具体请求（例如"add authorization Story"）
  • 无需阶段3的完整理想计划
  • 保留现有Story，不进行对比
处理模块负责：
  • 仅为新Story进行标准研究
  • 生成Story文档（8个部分）
  • 验证INVEST标准
  • 在Linear中创建（追加到现有Story）
  • 更新kanban_board.md
输出： 已创建的Story链接 + 处理模块返回的摘要
TodoWrite格式（必填）： 开始前需将阶段添加到待办事项：
- Phase 1: Context Assembly (in_progress)
- Phase 2: Standards Research via ln-221 (pending)
- Phase 3: Build IDEAL Story Plan (pending)
- Phase 4: Check Existing Stories (pending)
- Phase 5: Delegate to ln-222/ln-223 (pending)
- Wait for worker result (pending)
开始阶段时标记为in_progress，完成后标记为completed。

Integration with Ecosystem

生态系统集成

Calls:
  • ln-001-standards-researcher (Phase 2) - research standards/patterns for Epic
  • ln-221-story-creator (Phase 5a, 5c) - CREATE and ADD worker
  • ln-222-story-replanner (Phase 5b) - REPLAN worker
Called by:
  • ln-200-scope-decomposer (Phase 3) - automated full decomposition (scope → Epics → Stories)
  • Manual - user invokes for Epic Story creation/replanning
Upstream:
  • ln-210-epic-coordinator - creates Epics (prerequisite for Story creation)
Downstream:
  • ln-300-task-coordinator - creates implementation tasks for each Story
  • ln-310-story-validator - validates Story structure/content
  • ln-400-story-executor - orchestrates task execution for Story
调用的模块：
  • ln-001-standards-researcher（阶段2）- 为Epic研究标准/模式
  • ln-221-story-creator（阶段5a、5c）- 创建和添加Story的处理模块
  • ln-222-story-replanner（阶段5b）- 重新规划Story的处理模块
被以下模块调用：
  • ln-200-scope-decomposer（阶段3）- 自动化完整分解（范围 → Epics → Stories）
  • 手动触发 - 用户调用以创建/重新规划Epic的Story
上游依赖：
  • ln-210-epic-coordinator - 创建Epic（Story创建的前置条件）
下游依赖：
  • ln-300-task-coordinator - 为每个Story创建实现任务
  • ln-310-story-validator - 验证Story结构/内容
  • ln-400-story-executor - 协调Story的任务执行

Definition of Done

完成定义

✅ Phase 1: Context Assembly Complete:
  • Team ID, Epic number, Next Story Number loaded from kanban_board.md
  • Q1-Q6 extracted from Epic (Step 2)
  • Frontend Research attempted if Q2/Q5 missing (Step 3)
  • Fallback Search attempted for missing info (Step 4)
  • User input requested if still missing (Step 5)
  • Complete Story planning context assembled
✅ Phase 2: Standards Research Complete:
  • Epic parsed for domain keywords
  • ln-001-standards-researcher invoked with Epic description + Story domain
  • Standards Research cached for workers
  • OR Phase 2 skipped (trivial CRUD, no standards, explicit skip)
✅ Phase 3: Planning Complete:
  • Epic Scope analyzed
  • Optimal Story count determined (5-10 Stories)
  • IDEAL Story plan created (titles, statements, core AC, ordering)
  • Story Grouping Guidelines validated (vertical slicing)
  • INVEST checklist validated for all Stories
✅ Phase 4: Check Existing Complete:
  • Queried Linear for existing Stories (count only)
  • Execution mode determined (CREATE or REPLAN)
✅ Phase 5: Delegation Complete:
  • Called ln-221-story-creator (Phase 5a) OR ln-222-story-replanner (Phase 5b) via Skill tool
  • Passed epicData, idealPlan, standardsResearch, teamId, autoApprove
  • Received output from worker (Story URLs + summary + next steps)
✅ 阶段1：上下文收集完成：
  • 从kanban_board.md加载团队ID、Epic编号、下一个Story编号
  • 从Epic提取Q1-Q6（步骤2）
  • 若Q2/Q5缺失则尝试前端研究（步骤3）
  • 为缺失信息尝试备用搜索（步骤4）
  • 若仍缺失则请求用户输入（步骤5）
  • 完成Story规划上下文收集
✅ 阶段2：标准研究完成：
  • 解析Epic的领域关键词
  • 调用ln-001-standards-researcher并传入Epic描述+Story领域
  • 缓存标准研究结果供处理模块使用
  • 或跳过阶段2（简单CRUD、无标准、明确标注无需研究）
✅ 阶段3：规划完成：
  • 分析Epic范围
  • 确定最优Story数量（5-10个）
  • 创建理想的Story计划（标题、描述、核心AC、排序）
  • 验证Story分组指南（垂直切片）
  • 验证所有Story符合INVEST标准
✅ 阶段4：检查现有Story完成：
  • 查询Linear中的现有Story（仅统计数量）
  • 确定执行模式（创建或重新规划）
✅ 阶段5：委托完成：
  • 通过Skill工具调用ln-221-story-creator（阶段5a）或ln-222-story-replanner（阶段5b）
  • 传入epicData、idealPlan、standardsResearch、teamId、autoApprove
  • 接收处理模块返回的输出（Story链接+摘要+下一步操作）

Example Usage

示例用法

CREATE MODE (First Time):
"Create stories for Epic 7: OAuth Authentication"
Process:
  1. Phase 1: Context Assembly → Discovery (Team "API", Epic 7, US004), Extract (Persona: API client, Value: secure API access), Frontend Research (HTML login/register forms → AC), Fallback Search (requirements.md for personas)
  2. Phase 2: Standards Research → Epic mentions "OAuth 2.0", delegate ln-001 → Standards Research with RFC 6749, patterns
  3. Phase 3: Planning → Build IDEAL (5 Stories: "Register client", "Request token", "Validate token", "Refresh token", "Revoke token")
  4. Phase 4: Check Existing → Count = 0 → CREATE MODE
  5. Phase 5a: Delegate CREATE → Call ln-221-story-creator → US004-US008 created with Standards Research
REPLAN MODE (Requirements Changed):
"Replan stories for Epic 7 - removed custom token formats, added scope management"
Process:
  1. Phase 1: Context Assembly → Discovery (Team "API", Epic 7, has US004-US008), Extract (Removed custom formats, added scopes)
  2. Phase 2: Standards Research → Epic mentions "OAuth 2.0 scopes", delegate ln-001 → Updated Standards Research with RFC 6749 Section 3.3
  3. Phase 3: Planning → Build IDEAL (5 Stories: "Register client", "Request token", "Validate token", "Refresh token", "Manage scopes")
  4. Phase 4: Check Existing → Count = 5 → REPLAN MODE
  5. Phase 5b: Delegate REPLAN → Call ln-222-story-replanner → KEEP 4, UPDATE Technical Notes (scope research), OBSOLETE US008, CREATE US009
创建模式（首次分解）：
"Create stories for Epic 7: OAuth Authentication"
流程：
  1. 阶段1：上下文收集 → 发现（团队"API"、Epic7、US004）、提取（角色：API客户端，价值：安全API访问）、前端研究（HTML登录/注册表单 → AC）、备用搜索（requirements.md中的角色）
  2. 阶段2：标准研究 → Epic提及"OAuth 2.0"，委托ln-001 → 包含RFC 6749及相关模式的标准研究结果
  3. 阶段3：规划 → 构建理想计划（5个Story："注册客户端"、"请求令牌"、"验证令牌"、"刷新令牌"、"撤销令牌"）
  4. 阶段4：检查现有Story → 数量=0 → 创建模式
  5. 阶段5a：委托创建 → 调用ln-221-story-creator → 创建US004-US008并包含标准研究结果
重新规划模式（需求变更）：
"Replan stories for Epic 7 - removed custom token formats, added scope management"
流程：
  1. 阶段1：上下文收集 → 发现（团队"API"、Epic7、已有US004-US008）、提取（移除自定义令牌格式、添加范围管理）
  2. 阶段2：标准研究 → Epic提及"OAuth 2.0 scopes"，委托ln-001 → 更新包含RFC 6749第3.3节的标准研究结果
  3. 阶段3：规划 → 构建理想计划（5个Story："注册客户端"、"请求令牌"、"验证令牌"、"刷新令牌"、"管理范围"）
  4. 阶段4：检查现有Story → 数量=5 → 重新规划模式
  5. 阶段5b：委托重新规划 → 调用ln-222-story-replanner → 保留4个Story、更新技术说明（范围研究）、废弃US008、创建US009

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
    (Story sequential across Epics)
  • [必填] 问题解决方法： 
    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
    （Story跨Epic连续编号）

Best Practices

最佳实践

Story Content:
  • Research-First: Always perform Phase 2 research (standards/patterns) before Story generation
    • Story level: STANDARDS/PATTERNS (OAuth RFC 6749, middleware pattern)
    • Task level: LIBRARIES (authlib vs oauthlib) - delegated by ln-300
  • Business-oriented Stories: Each Story = USER JOURNEY (what user does, what they get), NOT technical tasks
    • ✅ GOOD: "As API client, I want to refresh expired token, so that I maintain session without re-authentication"
    • ❌ BAD: "Create token refresh endpoint in API" (Task, not Story)
  • Vertical Slicing: Each Story delivers end-to-end functionality (UI → API → Service → DB)
  • One capability per Story: Clear, focused persona + capability + value
  • Testable AC: Given-When-Then, 3-5 AC, specific criteria ("<200ms" not "fast")
  • Test Strategy: Section exists but is empty at Story creation (tests planned later by ln-510-test-planner)
  • Standards Research: Include Phase 2 research in ALL Story Technical Notes
Story Decomposition:
  • Decompose-First: Build IDEAL plan before checking existing - prevents anchoring to suboptimal structure
  • INVEST validation: Validate every Story against INVEST criteria
  • Size enforcement: 3-5 AC, 6-20 hours
  • Avoid over-decomposition: <3 AC, <6 hours → Merge Stories
User Interaction:
  • Epic extraction: Try to extract all planning info from Epic in Phase 1 Step 2 before asking user
  • Frontend Research: HTML forms/validation → AC scenarios (Phase 1 Step 3)
  • Fallback search: requirements.md, tech_stack.md if Epic incomplete (Phase 1 Step 4)
  • Only ask user for missing info after Epic extraction AND frontend AND fallback search fail
Delegation:
  • Orchestrator loads metadata only: ID, title, status (~50 tokens per Story)
  • Workers load full descriptions: 8 sections (~5,000 tokens per Story)
  • Token efficiency: 10 Stories × 50 tokens = 500 tokens (orchestrator) vs 10 Stories × 5,000 tokens = 50,000 tokens (workers load when needed)
Version: 5.0.0 (BREAKING: Added AC Quality Validation in Phase 3 (completeness: happy path + errors + edge cases; specificity: HTTP codes + timing). Updated INVEST Independent criterion with forward dependency check. Added Database Creation Principle to Story Grouping Guidelines per BMAD Method best practices.) Last Updated: 2026-02-03
Story内容：
  • 先研究后创建： 生成Story前务必执行阶段2的标准/模式研究
    • Story层级： 标准/模式（OAuth RFC 6749、中间件模式）
    • 任务层级： 库选择（authlib vs oauthlib）- 由ln-300委托处理
  • 业务导向的Story： 每个Story = 用户旅程（用户做什么、得到什么），而非技术任务
    • ✅ 合理："作为API客户端，我希望刷新过期令牌，以便无需重新认证即可维持会话"
    • ❌ 不合理："在API中创建令牌刷新端点"（任务，非Story）
  • 垂直切片： 每个Story交付端到端功能（UI → API → 服务 → 数据库）
  • 单功能Story： 明确、聚焦的角色 + 功能 + 价值
  • 可测试的AC： Given-When-Then格式、3-5条AC、具体标准（"<200ms"而非"快"）
  • 测试策略： Story创建时包含该部分但为空（测试用例后续由ln-510-test-planner规划）
  • 标准研究： 所有Story的技术说明中需包含阶段2的研究结果
Story分解：
  • 先分解后对比： 先构建理想计划再检查现有内容 - 避免受次优结构影响
  • INVEST验证： 每个Story都需符合INVEST标准
  • 规模强制： 3-5条AC、6-20小时工作量
  • 避免过度分解： <3条AC、<6小时 → 合并Story
用户交互：
  • 优先从Epic提取： 阶段1步骤2中优先从Epic提取所有规划信息，再询问用户
  • 前端研究补充： HTML表单/验证规则 → AC场景（阶段1步骤3）
  • 备用搜索补充： 若Epic信息不完整，使用requirements.md、tech_stack.md补充（阶段1步骤4）
  • 仅询问缺失信息： 仅当Epic提取、前端研究、备用搜索均失败时，才请求用户补充
委托优化：
  • 协调器仅加载元数据： ID、标题、状态（每个Story约50令牌）
  • 处理模块加载完整描述： 8个部分（每个Story约5000令牌）
  • 令牌效率： 10个Story × 50令牌 = 500令牌（协调器） vs 10个Story × 5000令牌 = 50000令牌（处理模块按需加载）
版本： 5.0.0（重大更新：阶段3添加AC质量验证（完整性：正常流+错误处理+边界场景；具体性：HTTP码+时间）。更新INVEST独立性标准，增加前置依赖检查。根据BMAD方法最佳实践，在Story分组指南中添加数据库创建原则。） 最后更新： 2026-02-03