ln-300-task-coordinator

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

任务协调器

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

由运行时支持的任务规划协调器。运行时负责就绪状态门控、暂停／恢复以及工作者结果跟踪。

必须阅读： 加载 references/coordinator_runtime_contract.md、references/task_planning_runtime_contract.md、references/coordinator_summary_contract.md 和 references/task_plan_worker_runtime_contract.md 必须阅读： 加载 references/environment_state_contract.md、references/storage_mode_detection.md、references/problem_solving.md 和 references/creation_quality_checklist.md 必须阅读： 触发第 3 阶段外部验证时，加载 references/agent_delegation_pattern.md 必须阅读： Story 引用了 H/G/run ID，或实现就绪状态取决于项目假设时，加载 references/researchgraph_mcp_usage.md。 工具策略：遵循宿主 AGENTS.md 中的 MCP 偏好；仅当宿主策略缺失或 MCP 行为不明确时，才加载 references/mcp_tool_preferences.md 和 references/mcp_integration_patterns.md。

目的

• 解析一次 Story 上下文
• 在检查现有任务前，制定理想的实现任务计划
• 运行确定性的就绪状态门控
• 检测 CREATE、ADD 或 REPLAN
• 委派给独立工作者

输入

参数	必填	说明
storyId	是	要规划的 Story
autoApprove	否	如果为 false，运行时可能会暂停以等待就绪审批

运行时

运行时系列：task-planning-runtime

标识符：

• story-{storyId}

阶段：

1. PHASE_0_CONFIG
2. PHASE_1_DISCOVERY
3. PHASE_2_DECOMPOSE
4. PHASE_3_READINESS_GATE
5. PHASE_4_MODE_DETECTION
6. PHASE_5_DELEGATE
7. PHASE_6_VERIFY
8. PHASE_7_SELF_CHECK

终止阶段：

• DONE
• PAUSED

协调器阶段产物：

• 验证后写入 summary_kind=pipeline-stage
• ln-1000 将此产物用作第 0 阶段完成信号

阶段映射

阶段 1：发现

解析 Story，并仅收集任务规划所需的输入：

• Story AC
• 技术说明
• 上下文
• 项目架构和技术栈
• 任务提供方

此处不要加载现有任务。仅在阶段 4 加载现有任务。

• 对于涉及受支持语言的现有代码修改的 Story，只构建一次图谱上下文：
  • index_project(path=project_root)
  • analyze_architecture(path=project_root, verbosity="minimal")
  • 对 Story AC 或技术说明中提及的组件使用 find_symbols + inspect_symbol；但应尽可能先缩小 path 范围。如果符号发现结果被截断，则在据此规划前，先细化为 name + file 或 workspace_qualified_name
• 使用图谱上下文，在分解前确认实际受影响的模块和入口点
• 对于引用假设、目标或运行证据的 Story，运行 verify_index，然后仅检查所引用的 H##／G## ID 或候选项。
• 使用 hex-research 确认假设的实现状态、细化缺口和提案就绪情况；将 hex-graph 作为代码符号和模块边界的来源。

检查点负载：

• discovery_ready

阶段 2：分解

仅根据验收条件（AC）构建理想任务计划。不要阅读或参考现有任务。

操作顺序：

1. 构建 AC 到场景的可追溯性表格，包含以下列：AC | Actor | (1) 触发条件 | (2) 入口点 | (3) 发现方式 | (4) 使用情境 | (5) 结果
2. 扫描入口点、发现方式和使用情境单元格，查找可构建的产物
3. 按架构层对可构建的产物进行分组，使用以下分段边界：
   • 基础层： 执行实际工作的内部逻辑、数据模型或服务（入口点调用的内容）
   • 调用层： 入口点本身——Actor 使用的具名机制
   • 知识层： 使用情境——Actor 正确调用该机制所需了解的信息
   • 接线层： 发现方式 + 集成——系统如何查找／加载该机制并连接组件
4. 每个层级分组至少对应一个任务。单个任务不得跨越多个层级，除非任务极其简单。
5. 存在图上下文时，使用它来：
   • 按实际模块或符号归属拆分任务，而不是猜测文件分组
   • 根据真实调用方、框架入口点和公共 API 安排依赖顺序
   • 使用图分析返回的真实模块／符号丰富“受影响组件”
6. 验证基础层优先的顺序和 1-8 个任务的数量
7. 将可追溯性表格和层级分组保存到 .hex-skills/task-planning/{identifier}_traceability.md

规则：

• 仅包含实现任务
• 1-8 个任务
• 此处不包含测试或重构任务
• 保持基础层优先的顺序
• 指定有意义的验证意图
• 仅涉及基础设施的任务，不能满足要求某项功能可供使用的验收条件
• 调用层任务不能满足要求 Actor 知道如何使用该机制的验收条件——这属于知识层产物
• 参见 creation_quality_checklist.md 中的 #17b、#17c、#17d

检查点负载：

• ideal_plan_summary
• traceability_table_path

阶段 3：就绪度门禁

委派前为计划评分。

步骤 1：自评分

评分策略：

• 6-7 -> 继续
• 4-5 -> 因等待审批或改进而进入 PAUSED
• <4 -> 修正计划前阻止继续

自检：如果可追溯性表格包含相应分段中的可构建产物，则验证每个层级（基础层、调用层、知识层、接线层）至少有一个任务。

步骤 2：有条件的外部可追溯性验证

仅当至少满足一项触发条件时运行此步骤：

• 就绪度评分为 4-5
• 模式看起来存在歧义（ADD 与 REPLAN）
• AC 到任务的覆盖不完整
• 自评分后，任务边界或层级归属仍存在冲突

触发时：

1. 运行 Agent 健康检查：node references/agents/agent_runner.mjs --health-check --json

2. 如果顾问 Agent 可用： a. 根据 references/agents/prompt_templates/traceability_validator.md 构建验证提示词 b. 填入阶段 1 的发现结果和阶段 2 的输出 c. 将填好的提示词保存到 .hex-skills/task-planning/{identifier}_traceability_prompt.md d. 通过 agent_runner.mjs 启动 Agent：

   node references/agents/agent_runner.mjs \
     --agent {advisor_agent} \
     --prompt-file .hex-skills/task-planning/{identifier}_traceability_prompt.md \
     --output-file .hex-skills/task-planning/{identifier}_traceability_result.json \
     --cwd {project_dir}
   

   e. 解析结果 JSON，查找缺口 f. 每发现一个 MISSING 缺口：readiness_score -= 1 g. 每发现一个 BUNDLED 缺口：readiness_score -= 0.5 h. 如果发现 MISSING 缺口：重新进入阶段 2。最多重新分解 1 次。

3. 如果没有可用的 Agent：记录日志，并保留本地评分，同时降低置信度。

未触发时：

• 设置 traceability_validation = self_check_only
• 不进行外部验证，直接继续

检查点负载：

• readiness_score
• readiness_findings
• traceability_validation — 以下值之一：agent_validated、self_check_only、redecomposed

阶段 4：模式检测

检测：

• CREATE
• ADD
• REPLAN

模式有歧义时暂停。

检查点载荷：

• mode_detection

阶段 5：委派

单次变更交接。恰好委派给一个工作器：

• ln-301-task-creator
• ln-302-task-replanner

托管委派顺序：

1. 计算 childRunId = {parent_run_id}--{worker}--{storyId}。
2. 计算 childSummaryArtifactPath = .hex-skills/runtime-artifacts/runs/{parent_run_id}/task-plan/{worker}--{storyId}.json。
3. 在 .hex-skills/task-planning/{worker}--{storyId}_manifest.json 生成子清单。
4. 使用 --run-id 和 --summary-artifact-path 启动 task-plan-worker-runtime。
5. 调用工作器前，先将 child_run 元数据写入检查点。
6. 通过 Skill 工具调用工作器，并传入这两个传输输入。
7. 仅读取最终的 task-plan 工件，并通过运行时 record-plan 记录。

传递给工作器的协调器上下文：

• idealPlan：阶段 2 的完整理想计划
• traceabilityTablePath：已生成的可追溯性表路径
• discoveryContext：阶段 1 的发现结果
• 在 ADD 模式下：指定要创建哪些任务

阶段 6：验证

仅验证工作器结果及由此产生的任务集。除非验证证明工作器输出无效，否则不要重新进行分解。

**模板合规门槛：**通过已配置的跟踪系统提供方（references/tracker_provider_contract.md 中的 getTask 操作）获取每个已创建的 Task。运行 planning-runtime/lib/template-compliance.mjs 中的 validateTemplateCompliance(description, 'task')。所有任务都必须通过验证（按顺序包含 7 个部分）。在状态中记录 template_compliance_passed。缺少该项时，守卫会阻止 SELF_CHECK。

检查点载荷：

• verification_summary
• final_result
• template_compliance_passed

验证成功后，写入一份 Stage 0 协调器工件，包含：

• stage=0
• story_id
• status=completed
• final_result
• story_status
• readiness_score
• warnings

阶段 7：自检

确认：

• 阶段覆盖情况
• 已遵守就绪度门槛
• 已记录工作器结果
• 已完成验证
• 已记录 Stage 0 协调器工件

检查点载荷：

• pass
• final_result

待定决策

以下情况使用运行时 PAUSED + pending_decision：

• ADD 与 REPLAN 有歧义
• 分数为 4-5 时需要就绪审批
• 缺少关键 Story 上下文

工作器契约

工作器：

• 不知道协调器的存在
• 不读取运行时状态
• 保持独立运行
• 托管运行要求同时提供 runId 和 summaryArtifactPath
• 返回共享的 task-plan 摘要信封，并在终止状态前写入工件

预期摘要类型：

• task-plan

工作器调用（强制）

**宿主 Skill 调用：**必须使用 Skill(skill: "...", args: "...") 进行委派。

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

阶段	工作器	上下文
5	ln-301-task-creator	CREATE 或 ADD 路径
5	ln-302-task-replanner	REPLAN 路径

node references/scripts/task-plan-worker-runtime/cli.mjs start --skill {worker} --story {storyId} --manifest-file .hex-skills/task-planning/{worker}--{storyId}_manifest.json --run-id {childRunId} --summary-artifact-path {childSummaryArtifactPath}
node references/scripts/task-planning-runtime/cli.mjs checkpoint --story {storyId} --phase PHASE_5_DELEGATE --payload '{"child_run":{"worker":"{worker}","run_id":"{childRunId}","summary_artifact_path":"{childSummaryArtifactPath}"}}'
Skill(skill: "{worker}", args: "{storyId} --ideal-plan {idealPlanJSON} --traceability {tablePath} --discovery {discoveryJSON} --run-id {childRunId} --summary-artifact-path {childSummaryArtifactPath}")
Read {childSummaryArtifactPath}
node references/scripts/task-planning-runtime/cli.mjs record-plan --story {storyId} --payload '{...task-plan summary...}'

TodoWrite 格式（强制）

- Phase 1: Discover Story context (pending)
- Phase 2: Build ideal task plan (pending)
- Phase 3: Run readiness gate (local score first, external validation only if triggered) (pending)
- Phase 4: Detect mode (pending)
- Phase 5: Start child runtime, checkpoint child metadata, and perform the single worker handoff (pending)
- Phase 6: Verify worker result (pending)
- Phase 7: Self-check (pending)

关键规则

• 先构建理想计划，再查看现有任务。
• 就绪度门槛是判断是否可以委派的唯一依据。
• 不要在此技能中创建测试或重构任务。
• 不要仅在聊天中保留审批状态。
• 使用工作器摘要，不要使用工作器的自由文本说明。
• 如果 Story 会影响现有代码且 hex-graph 可用，则在分解前进行一次图发现。
• 使用图输出减少规划歧义；有符号或模块证据时，不要臆造受影响的组件。

完成定义

• 使用 Story 作用域标识符启动运行时
• 发现阶段已设检查点
• 理想计划已设检查点
• 就绪门槛已设检查点
• 模式检测已设检查点
• 使用确定性的 runId 启动子任务计划运行时
• 委派前已设子运行元数据检查点
• 已记录任务计划工作器摘要
• 验证阶段已设检查点
• 所有已创建的 Tasks 均通过模板合规检查
• 已记录最终结果
• 自检通过

元分析

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

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

---

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