菜单
Route a user request to the appropriate loom capability without replacing pipeline selection. Use when: a user request needs intent classification before choosing a skill, pipeline selector, QA, review, debugging, or branch finishing path.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Read-only cross-artifact consistency analysis after planning and before approval. Verifies that spec.md, requirements.json, plan.md, tasks/Tn.md, traceability.json are mutually consistent: no duplicate/ambiguous requirements, every behavior mapped to a task, no orphan tasks, no coverage gaps, no contradictions. Outputs artifact-analysis.json with coverage% and severity. CRITICAL/HIGH findings block the approval gate. Use when: planning produced plan.md + tasks + traceability.json, before the user approves the plan.
Explore 2-3 implementation options with trade-offs when the user describes a new feature or requirement. Use when: the user asks for a new feature design, implementation options, or technical trade-off analysis.
After implementation and before final verification, compare current code/tests against the intent inventory (requirements.json + traceability.json). Classify each requirement/behavior as covered, missing, partial, contradicts, or unrequested. Append missing/partial/contradicts as new tasks back to executing. Repeat until converged: zero blocker findings. Outputs convergence-report.json. Use when: executing produced test-report.md but before loom-verification-before-completion.
Expand each requirement into verifiable Behavior Obligations across 15 fixed dimensions (happy-path, boundary, invalid-input, authorization, state-transition, idempotency, concurrency, atomicity, external-failure, compatibility, security, performance, observability, recovery, forbidden-behavior) before planning. Use when: brainstorming produced requirements.json and spec is approved, but behaviors are still placeholders or only happy-path; before loom-writing-plans.
Read-only adversarial reviewer that looks for what SHOULD exist but doesn't, by cross-checking Behavior Obligations against code, tests, expected side effects, forbidden side effects, failure scenarios, and public API changes. Focuses on negative space: events that should not repeat, permissions that should not be bypassed, partial writes that should not happen, old APIs that should not change, swallowed exceptions, leaked secrets. Outputs findings.json. Use when: executing or converge needs an independent omission sweep.
Analyze user request + collect signals (file scope, keywords, worktree state, spec existence), then select pipeline steps via rule short-circuit / AI fallback / rule-based fallback. Select steps first, expose the choice to the user, and persist selected dynamic_steps only after explicit user confirmation; pipeline-plan.md is optional for manual review. Use when: user is unsure which pipeline type to pick, or wants AI to choose steps automatically.
| name | loom-router |
| description | Route a user request to the appropriate loom capability without replacing pipeline selection. Use when: a user request needs intent classification before choosing a skill, pipeline selector, QA, review, debugging, or branch finishing path. |
| when_to_use | Classify an ambiguous user request and route it to the right Loom skill or pipeline entry. |
| argument-hint | <user request> |
| user-invocable | true |
loom-router 是轻量入口分流层，只判断当前请求应该进入哪个 loom 能力。它不生成 dynamic_steps，不写 pipeline.state.json，不替代 loom-pipeline-selector。
pipeline.state.json / progress.md 决定。loom-pipeline-selector 已完成选择且用户已确认，后续应按 pipeline 状态执行。loom-pipeline-selector。pipeline.state.json。dynamic_steps。loom-pipeline-selector 的用户确认门禁。| 用户请求类型 | 推荐入口 | 说明 |
|---|---|---|
| 新功能、需求、跨模块改动 | loom-pipeline-selector | router 只说明应进入开发流水线；具体 steps 由 selector 选择并等待用户确认。 |
| 需求含糊、设计取舍多 | loom-brainstorming | 先澄清 shared understanding，再进入 spec / plan。 |
| bug、测试失败、异常行为 | loom-systematic-debugging | 先构造 red-capable feedback loop，再考虑修复。 |
| 明确行为变更或 bug 修复 | loom-test-driven-development | 在实现阶段使用 seam gate 和红绿重构。 |
| 准备发起审查 | loom-requesting-code-review | 先做 Standards + Spec 双轴预审查，再生成审查请求。 |
| 收到审查反馈 | loom-receiving-code-review | 分类处理、修复或 push back。 |
| 新功能验收或 release 验收 | loom-qa | 生成/执行 QA 用例并输出报告。 |
| 开发分支已验证完成 | loom-finishing-a-development-branch | 选择 merge、PR、keep 或 discard。 |
| 代码已变更且验证通过 | loom-index-update | 同步图后端、memory 和必要入口文档。 |
| 多个独立任务可并行 | loom-dispatching-parallel-agents | 仅在无共享文件冲突且已有确认 plan 时使用。 |
| 需要编写或修改 skill | loom-writing-skills | 检查职责边界、触发条件、完成标准和 context load。 |
| 用户询问 loom 能力 | loom-using-loom | 解释框架、skills 和 pipeline。 |
用一句话标注请求类型，例如：bug 调试、新功能开发、代码审查、QA 验收、分支收尾、loom 咨询。
输出推荐入口、原因和下一步。开发型任务必须说明：具体流水线仍由 loom-pipeline-selector 选择，且需要用户确认后才会写入状态。
以下情况必须先停下，不直接实现：
## 路由建议
- 类型：<请求类型>
- 推荐入口：<skill 或 pipeline selector>
- 原因：<1-3 条>
- 下一步：<要执行或要用户确认的动作>
- 上下文策略：<继续当前会话 | 写 handoff 后推进 | fresh session/subagent>
loom-pipeline-selector 选择 steps。