技能介绍

问题从哪来

一个仓库里往往同时堆着 .claude/skills/、命令、食谱和零散代理提示，但没人先回答：重复任务该用技能、食谱、工作流、钩子还是「什么都不做」？谁拥有 ship-feature、cut-release 这类域？工作流是中心辐射还是扁平「代理包团」？Loom 针对的是操作层缺乏系统设计——不是缺单个 SKILL.md，而是缺可验证的蓝图与明确的委托边界。

它如何工作

Loom 的定位是元设计：只织布，不纺线。默认走 SURVEY → MAP → DESIGN → DELEGATE → VERIFY 五段流程。

SURVEY：分析栈、约定与反复任务；深度代码阅读交给 Lens，直接读现有 .claude/ 层，并复用 Sigil 已有技能清单，不越界重写。
MAP：对每个任务按 _common/MECHANISM_SELECTION.md 选机制——每次/绝不规则 → 钩子，路径约束 → 限定规则，可复用方法论 → 技能；食谱与工作流是 Loom 本地机制，分别对应可重复多步任务与多代理协调。
DESIGN：产出技能套件方案、食谱集、带正式拓扑（中心辐射 / 管道 / 层级）的工作流，以及 Nexus 可消费的项目路由映射；工作流顺序阶段 ≤ 5，并设验证检查点。
DELEGATE / VERIFY：为 Sigil、Nexus、Orbit、Latch、Grove 等发出显式交接规范；交付前必须通过 reference/validation-checklist.md 的 14 项检查（含套件内与生态系统重叠 < 30%）。

子命令包括 blueprint（完整层）、recipe、workflow、map、audit；一次蓝图提议 10+ 个新技能需先与用户确认。

边界与注意

不要找 Loom 写单个技能正文 → 用 Sigil；运行时每次请求编排 → Nexus；代码级状态机 / Saga → Weave；全局 ~/.claude/skills/ 代理 → Architect。
Loom 绝不自行编写技能主体、运行链或安装文件；跳过 SURVEY、机制选择或验证即视为不完整交付。
与生态系统代理重叠 ≥ 30% 的任务应通过路由委托，而非再建重复项目技能；非结构化对等网络工作流会被拒绝发布。