loom-router

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 入口路由

loom-router 是轻量入口分流层，只判断当前请求应该进入哪个 loom 能力。它不生成 dynamic_steps，不写 pipeline.state.json，不替代 loom-pipeline-selector。

触发条件

• 用户提出新请求，但还不清楚应使用哪个 loom skill。
• 用户问“这个任务应该走什么流程”。
• 请求可能属于 bug、功能开发、代码审查、QA、分支收尾、索引更新、架构改进、技能编写或 loom 使用咨询之一。
• 当前会话需要判断继续当前上下文、写 handoff、压缩，还是开 fresh session。

非触发条件

• 已经处在明确的 pipeline stage 中，并且下一步由 pipeline.state.json / progress.md 决定。
• 用户已经明确指定要运行某个 skill。
• loom-pipeline-selector 已完成选择且用户已确认，后续应按 pipeline 状态执行。

职责边界

router 负责

• 识别请求入口类型。
• 解释推荐路径和理由。
• 判断是否需要先澄清、先复现、先审查、先 QA，或交给 loom-pipeline-selector。
• 给出上下文卫生建议：继续当前会话、写 handoff、压缩，或开 fresh session。

router 禁止

• 禁止直接写 pipeline.state.json。
• 禁止生成或持久化 dynamic_steps。
• 禁止绕过 loom-pipeline-selector 的用户确认门禁。
• 禁止把自己变成第二套 pipeline planner。

路由表

用户请求类型	推荐入口	说明
新功能、需求、跨模块改动	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。

执行流程

Step 1：分类请求

用一句话标注请求类型，例如：bug 调试、新功能开发、代码审查、QA 验收、分支收尾、loom 咨询。

Step 2：说明推荐路径

输出推荐入口、原因和下一步。开发型任务必须说明：具体流水线仍由 loom-pipeline-selector 选择，且需要用户确认后才会写入状态。

Step 3：判断是否需要阻塞执行

以下情况必须先停下，不直接实现：

• 需求关键行为不清楚。
• bug 没有可运行的失败信号。
• 要审查的 diff 或 fixed point 不明确。
• pipeline selector 尚未展示步骤并获得用户确认。
• 阶段切换前还没有写 handoff。

Step 4：给出上下文卫生建议

• 当前澄清链路、同一 bug 的反馈环、同一小任务：继续当前会话。
• spec、plan、executing、verification 阶段结束：先写 handoff，再压缩旧上下文。
• 每个独立 issue 实现、prototype 探索、并行 subagent、高风险实验、严重上下文污染：开 fresh session 或隔离 subagent。

输出格式

## 路由建议

- 类型：<请求类型>
- 推荐入口：<skill 或 pipeline selector>
- 原因：<1-3 条>
- 下一步：<要执行或要用户确认的动作>
- 上下文策略：<继续当前会话 | 写 handoff 后推进 | fresh session/subagent>

完成条件

• 已明确请求类型。
• 已给出推荐入口和理由。
• 如果是开发型任务，已明确后续由 loom-pipeline-selector 选择 steps。
• 已说明是否需要用户确认、补充信息、handoff、压缩或 fresh session。