ln-220-story-coordinator

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

Story 协调器

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

由运行时支持的 Story 规划协调器。运行时负责流程控制、暂停/恢复和工作器结果跟踪。

必须阅读

执行前加载以下文件：

• references/coordinator_runtime_contract.md
• references/story_planning_runtime_contract.md
• references/coordinator_summary_contract.md
• references/environment_state_contract.md
• references/storage_mode_detection.md
• references/problem_solving.md

**必须阅读：**当 Epic、源文档或现有 Story 引用了 H/G/运行 ID，或 ResearchGraph 布局可能改变 Story 分解时，加载 references/researchgraph_mcp_usage.md。

目的

• 汇总 Epic 规划上下文
• 仅在会影响技术说明时开展有针对性的标准研究
• 在检查现有 Story 之前，制定理想的 Story 计划
• 按 Epic 分组检测路由和模式
• 在委派前批量准备子清单/制品
• 将创建或重新规划工作委派给独立工作器

输入

参数	必填	描述
epicId	是	要分解的 Epic
autoApprove	否	如果为 false，运行时会暂停，等待预览确认

运行时

运行时系列：story-planning-runtime

标识符：

• epic-{epicId}

阶段：

1. PHASE_0_CONFIG
2. PHASE_1_CONTEXT_ASSEMBLY
3. PHASE_2_RESEARCH
4. PHASE_3_PLAN
5. PHASE_4_ROUTING
6. PHASE_5_MODE_DETECTION
7. PHASE_6_DELEGATE
8. PHASE_7_FINALIZE
9. PHASE_8_SELF_CHECK

终止阶段：

• DONE
• PAUSED

摘要流程：

• 从 ln-221 / ln-222 获取子级 story-plan-worker 制品
• 在 PHASE_7_FINALIZE 期间写入协调器 story-plan 制品

阶段映射

阶段 1：上下文汇总

解析 Epic，并仅汇总会影响 Story 分解的规划输入：

• Epic 范围
• 成功标准
• 已知角色和约束
• 项目任务提供方

检查点载荷：

• context_ready

阶段 2：研究

仅在会影响 Story 技术说明或实现约束时开展有针对性的研究。

不要让研究扩大 Story 范围。

如果存在 ResearchGraph 布局，请先使用 verify_index，然后只查询相关目标、假设、证据或运行。利用图谱结果作为 Story 范围、就绪状态和技术说明的依据；不要仅因为图谱存在债务就创建新的 Story 范围。

检查点载荷：

• research_status
• research_file

阶段 3：规划

在查看现有 Story 之前，制定理想的 Story 计划。

规则：

• 仅采用纵向切片
• Epic 需要时，规划 5-10 个 Story
• Story 陈述简洁，验收标准（AC）可观察
• 计划中不得包含编排说明
• 委派的 AC 必须说明为行动者配备了什么（上下文、指令、工具、配置），而不能只说明行动者要做什么

检查点载荷：

• ideal_plan_summary

阶段 4：路由

将规划好的 Story 路由到各个 Epic 组。

快速路径：

• 所有 Story 均保留在已解析的 Epic 中

仅当路由存在歧义或需要确认时暂停。

检查点载荷：

• routing_summary

阶段 5：模式检测

按 Epic 组确定模式：

• CREATE
• REPLAN
• ADD

检查点载荷：

• epic_group_modes

阶段 6：委派

阶段 6 包含两个内部步骤。

阶段 6a：准备委派

• 完成路由分组
• 生成 Worker 清单
• 为每个子任务预先计算 run_id 和 summary_artifact_path
• 在执行前检查点记录预期的 Worker 集合

阶段 6b：执行委派

按组委派：

• ln-221-story-creator
• ln-222-story-replanner

Worker 仍可独立运行。在托管模式下，协调器通过 planning-worker-runtime 启动它们，传入 runId + summaryArtifactPath，将启动元数据存储在 child_run 中，然后通过 record-epic 记录生成的 Worker 工件。

Worker 摘要类型：

• story-plan-worker

阶段 7：最终处理

仅在记录完所有预期的 Worker 摘要后进行最终处理。

协调器输出：

• 为父级运行时构建一份 story-plan 摘要
• 通过 node references/scripts/story-planning-runtime/cli.mjs record-plan-summary 写入摘要
• 在进入 PHASE_8_SELF_CHECK 前持久化工件

模板合规性门槛： 通过已配置的跟踪器提供方获取每个已创建的 Story（按照 references/tracker_provider_contract.md 中的 getStory 操作）。运行 planning-runtime/lib/template-compliance.mjs 中的 validateTemplateCompliance(description, 'story')。所有 Story 都必须通过检查（按顺序包含 9 个章节）。在状态中记录 template_compliance_passed。如果没有此项，守卫会阻止进入 SELF_CHECK。

检查点负载：

• final_result
• template_compliance_passed

阶段 8：自检

确认：

• 阶段覆盖情况
• 计划的 Story 数量与实际生成的数量
• 没有遗漏的 Epic 分组

检查点负载：

• pass
• final_result

待定决策

对于以下情况，使用运行时的 PAUSED + pending_decision：

• 缺少上下文
• 路由确认
• ADD 与 REPLAN 含义不明确
• autoApprove=false 时的预览确认

不要只在聊天中处理这些决策。

Worker 契约

Worker：

• 不知道协调器的存在
• 不读取运行时状态
• 保持独立运行
• 可接收 summaryArtifactPath
• 无论哪种情况都返回共享摘要封装

预期摘要类型：

• 子 Worker：story-plan-worker
• 协调器输出：story-plan

Worker 调用（强制）

宿主 Skill 调用： Skill(skill: "...", args: "...") 是强制委派方式。

• Claude：严格按所示方式调用 Skill 工具。
• Codex：如果不存在 Skill 工具，则在可用的 skills 中找到指定的 skill，读取其 SKILL.md，将 args 视为 $ARGUMENTS，执行该 skill 工作流，然后携带其结果/工件返回此处。
• 不要内联 Worker 逻辑，也不要在未执行目标 skill 的情况下将 Worker 标记为完成。

阶段	Worker	上下文
6	ln-221-story-creator	CREATE 或 ADD 路径
6	ln-222-story-replanner	REPLAN 路径

node references/scripts/planning-worker-runtime/cli.mjs start --skill {worker} --identifier {identifier} --manifest-file {workerManifestPath} --run-id {childRunId} --summary-artifact-path {childSummaryArtifactPath}
child_run = { skill, run_id, identifier, summary_artifact_path }
childSummaryArtifactPath = .hex-skills/runtime-artifacts/runs/{parent_run_id}/story-plan-worker/{worker}--{identifier}.json
Skill(skill: "{worker}", args: "{identifier} --ideal-plan {idealPlanJSON} --epic {epicId} --run-id {childRunId} --summary-artifact-path {childSummaryArtifactPath}")
Read {childSummaryArtifactPath}
node references/scripts/story-planning-runtime/cli.mjs record-epic --epic {epicId} --payload-file {childSummaryArtifactPath}
node references/scripts/story-planning-runtime/cli.mjs record-plan-summary --epic {epicId} --payload-file {coordinatorSummaryPath}

TodoWrite 格式（强制）

- Phase 1: Assemble context (pending)
- Phase 2: Research only what changes Technical Notes (pending)
- Phase 3: Build ideal Story plan (pending)
- Phase 4: Route Stories by Epic (pending)
- Phase 5: Detect mode per group (pending)
- Phase 6a: Prepare delegation batch (pending)
- Phase 6b: Execute worker(s) sequentially (pending)
- Phase 7: Finalize result (pending)
- Phase 8: Self-check (pending)

关键规则

• 在检查现有 Stories 之前，先制定理想计划。
• 仅使用调研来改进技术说明和实现方案的可行性。
• 不要只在聊天状态中保留路由或预览审批。
• 仅批量处理只读准备工作。除非运行时语义明确允许，否则不要并行修改不同路由分组中的 Story。
• 应由 Worker 执行时，不要直接创建或更新 Story。
• 使用 Worker 摘要，而非自由文本形式的 Worker 描述。

完成定义

• 使用 Epic 范围标识符启动运行时
• 已对上下文汇总设置检查点
• 已对调研设置检查点，或明确标记为最少调研
• 已对理想计划设置检查点
• 已对路由设置检查点
• 已对模式检测设置检查点
• 已记录所有预期的 Worker 摘要
• 已记录协调器的 story-plan 摘要
• 已对最终结果设置检查点
• 所有已创建的 Story 均已通过模板合规性检查
• 自检已通过

元分析

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

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

参考文件

• references/environment_state_contract.md
• references/storage_mode_detection.md
• references/replan_algorithm.md

---

版本： 5.0.0 最后更新： 2026-02-03