Loom执行计划编写器Skill：把复杂开发任务编排成可并行、可验证的执行计划
- 它是什么：
loom-plan-writer（Loom执行计划编写器Skill）是创建 Loom 执行计划的必需技能，专门把「一句需求」翻译成结构化的、基于 DAG 的多阶段执行计划。 - 强制骨架：任何计划都必须以「知识引导」阶段开头、以「集成验证」阶段收尾，中间才是实现阶段——这一点由技能强制约束。
- 两个并行维度：阶段内并行子代理（第一优先级）+ 并发工作树阶段（第二优先级），目标是最大化吞吐量。
- 反「假完成」设计：每个标准阶段必须声明
truths、artifacts、wiring中至少一项，用可观察行为与接线模式证明「功能真的接上了」，而不是「测试碰巧通过了」。 - 落地方式：计划统一写入
doc/plans/PLAN-<描述>.md，写完后由用户执行loom init ... && loom run启动编排，技能本身不负责实施。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | Loom执行计划编写器Skill |
| 技能英文名 | loom-plan-writer |
| 技能 ID | 13493 |
| 可用工具权限 | Read、Grep、Glob、Write、Edit |
| 核心触发关键词 | loom、计划、阶段、工作树、编排、并行执行、并行阶段、并发执行、知识引导、集成验证、验收标准、信号、交接、执行图、dag、依赖、loom计划、创建计划、编写计划、执行计划、编排计划、阶段依赖、并行子代理、功能验证、布线验证、冒烟测试 |
它解决什么问题？
在没有这个技能之前，让 AI 代理去「写一个开发计划」，得到的东西往往是不能用的：阶段划分靠感觉、没有并行策略、验收标准写成「功能正常」这种无法执行的句子、YAML 元数据格式随手一改就解析失败，最常见的翻车则是——所有测试都通过了，功能却根本没有被接进主程序。loom-plan-writer 的价值就在于把这些经验固化成规则：它规定了计划的输出位置、文档结构、YAML 元数据格式、并行化优先级、沙盒配置，以及一套「目标逆向验证」字段，让计划从「写给人看的文档」变成「机器能跑、能验、能拒绝的工程产物」。
一键安装的思路与步骤
- 准备前提：该技能服务于 Loom 编排体系，因此除了在技能市场/技能库中安装技能本体，还需要环境中具备 Loom 命令行工具（详情中出现了
loom init、loom run、loom knowledge、loom memory、loom sandbox suggest等命令）。具体安装方式与版本要求以官方说明为准。 - 找到技能：在 AI 技能市场或技能库中按技能 ID
13493或英文名loom-plan-writer检索，确认技能描述中包含「创建Loom执行计划的必需技能」字样即为目标技能。 - 一键安装：点击安装/添加到工作区，技能会以技能包形式落位到你的技能目录中（具体入口与目录路径以官方说明为准）。安装时注意它申请的权限是只读检索类（Read/Grep/Glob）加写作类（Write/Edit），属于写文档必需的最小集合。
- 验证是否生效：在会话中直接说「用 loom 创建执行计划，拆解一个并行阶段」，或干脆只输入关键词「编排计划」。若技能生效，输出应满足几个硬性特征：计划写到
doc/plans/PLAN-<描述>.md；开头是知识引导阶段、结尾是集成验证阶段；正文里出现被<!-- loom 元数据 -->注释包裹的 YAML 块；每个标准阶段都带truths/artifacts/wiring。 - 端到端验证：对生成的计划执行
loom init doc/plans/PLAN-<名称>.md，如果计划不符合规则（例如标准阶段缺少验证字段），loom init会直接拒绝，这本身就是一次有效的验证信号。
2. 该技能的主要功能和特点
- 强制「书挡」结构：第一个阶段固定为知识引导（
stage_type: knowledge），最后一个阶段固定为集成验证（stage_type: integration-verify），中间才是实现阶段。只有在doc/loom/knowledge/已填充且loom knowledge check显示覆盖率 ≥ 50% 时，才允许跳过知识引导。 - 三级并行化策略：优先级从高到低依次为「同阶段内代理团队」→「同阶段内并行子代理」→「独立工作树阶段」。只有当任务之间存在文件重叠（会合并冲突）或代码依赖（B 依赖 A 产出的代码）时，才拆成独立阶段；否则一律在阶段内并行，因为每个阶段都会新建一个 git 工作树、生成新会话，开销很大。
- 目标逆向验证（已验证）：标准阶段必须至少提供一项
truths（可观察行为，如myapp --help）、artifacts（必须存在的真实实现文件）、wiring（证明接线的代码模式，含source与pattern）。缺了这些字段，loom init直接拒绝计划。 - 沙盒配置生成能力：通过与用户对话收集网络访问域名、需要保护的敏感路径（如
~/.ssh、.env）、所需构建工具，再结合loom sandbox suggest的建议，生成sandbox配置块，支持全局与单阶段覆盖。 - 强制
working_dir：每个阶段必须显式声明工作目录（"."或子目录如"loom"），并且所有acceptance、artifacts、wiring、truths中的路径都相对于它解析，从源头避免「目录写重复导致验收永远失败」。 - 内存与知识分离：实现阶段只允许写
loom memory，禁止直接改知识库；知识引导阶段和集成验证阶段才有知识写入权限，由集成验证阶段把内存中经过验证的洞察策展进永久知识。 - 格式防错规则：YAML 用三个反引号、禁止在描述里嵌套代码围栏（否则解析器崩溃并误报「缺少 truths/artifacts」）、
stage_type必须是小写烤肉串命名（PascalCase 会被拒绝）、路径禁止../、网络配置必须写成结构体而不是network: deny。 - 写完即停：技能明确规定计划文件就是交付物，写完后要停止，提示用户审阅并执行
loom init ... && loom run，不得自行继续实施。
和普通「让 AI 列个 TODO」相比，它强在：输出有固定落盘位置、有机器可解析的元数据、有会被校验拒绝的硬约束、有多级并行策略、有防「假完成」的验证字段。
3. 如何使用该技能？
第 1 步：触发技能。 用自然语言描述目标即可，例如「用 loom 编写一个执行计划：给项目加上 OAuth 登录和请求日志」。命中「loom」「编写计划」「编排计划」等关键词后技能自动介入。
第 2 步：回答预计划问题。 技能会先做两件事：一是拉起探索子代理，去现有代码里找可复用的模式、实用函数、集成点和约定，并要求在任务列表里标注 REUSE:；二是向你提三个问题——是否需要网络访问及哪些域名、有哪些敏感路径需要保护、需要哪些构建工具。这三项会被合并成 sandbox 配置块。
第 3 步：让技能先摸清知识现状。 知识引导阶段会调用 loom knowledge check 查看覆盖率；覆盖率低于 50% 或架构信息不完整时执行 loom map --deep 建立结构基线；随后派并行子代理分别梳理入口点、模式、约定，并用 loom knowledge update 写入 doc/loom/knowledge/ 对应文件。长内容可用 heredoc 方式写入。
第 4 步：审阅阶段拆分与并行策略。 重点看三件事：是否有文件重叠的任务被错放进同一阶段（应拆开）、是否有本可并行的任务被写成串行（应合并为同阶段子代理）、每个阶段描述里是否带上那句强制提示「使用并行子代理和技能以最大化性能。」
第 5 步：检查验证字段。 每个 stage_type: standard 阶段至少要有一条 truths、artifacts 或 wiring。例如给 CLI 加子命令的阶段，可以写成：truths: ["myapp new-command --help"]、artifacts: ["src/commands/new_command.rs"]、wiring: [{source: "src/main.rs", pattern: "mod new_command", description: "命令模块在 main 中导入"}]。
第 6 步：确认输出与执行。 计划应落在 doc/plans/PLAN-<描述>.md，文档上部是人类可读的概述、执行图与阶段说明，下部是被 <!-- loom 元数据 --> 包裹的 YAML。确认无误后执行 loom init doc/plans/PLAN-<名称>.md && loom run 启动编排。
第 7 步：执行期遵守记录规则。 实现阶段只写内存：loom memory note "观察"、loom memory decision "选择" --context "原因"；集成验证阶段读取 loom memory show --all，把值得沉淀的洞察用 loom knowledge update 策展进知识库。
输入输出示例：输入「给 API 加认证中间件 + 加请求日志，两者都在 src/api/handler.rs 里改」→ 输出应拆成两个有依赖关系的串行阶段（因为文件重叠），并在集成验证阶段给出 truths: ["curl -f localhost:8080/api/health"] 这类可执行冒烟检查。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| loom-plan-writer（本技能） | Loom 编排体系的计划生成器 | 强制知识引导与集成验证书挡、DAG 依赖、三级并行、truths/artifacts/wiring 验证、沙盒配置、YAML 元数据校验 | 需在技能库安装并配套 Loom CLI；需理解阶段与工作树概念 | 多模块并行开发、需要「真接线」验证的中大型任务 | 优势：结构可执行、可被 loom init 校验、防假完成；不足：规则密集，学习曲线偏陡，强绑定 Loom 生态 |
| 人工手写 Markdown 计划 | 传统工程文档 | 自由格式任务拆解与排期 | 零门槛 | 小改动、单人任务 | 优势：灵活低成本；不足：无校验、无并行推导、容易出现测试通过但功能未接线的盲区 |
| 通用 AI 编码助手直接列 TODO | 对话式任务拆解 | 快速产出任务清单 | 极低 | 探索性、一次性任务 | 优势：上手最快；不足：输出不稳定、无固定落盘位置、无验证字段、不会主动做代码复用探索 |
| 传统任务管理工具（如看板类工具） | 项目协作与进度跟踪 | 任务卡片、状态流转、工时统计 | 低 | 跨角色协作与进度可见性 | 优势：协作与可视化强；不足：不生成可执行的技术计划，不理解文件重叠与代码依赖，无法与代理编排联动 |
结论：如果研发流程根本不涉及 AI 代理编排，用看板或手写文档更轻；一旦进入「多阶段并行 + 代理执行」的场景，本技能的约束性反而是它最大的竞争力。
5. 该技能的典型应用场景与实际体验情况
场景一：多模块功能并行开发（后端工程师 + 代理协作）
痛点是一次性要加认证、日志、限流三块能力，人工排期容易串行化，浪费等待时间。使用方式：让技能先判断文件是否重叠——三块分别落在 src/auth/**、src/logging/**、src/ratelimit/** 时，可以放进同一阶段的并行子代理；一旦都改同一个 handler 文件，就自动降级为串行阶段。实际体验：上手需要先理解「阶段昂贵」这一前提，但一旦理解，拆阶段会变得非常有分寸，不会无脑铺开一堆工作树。
场景二：接手陌生代码库（新成员或新会话）
痛点是代理在不懂项目约定的情况下重复造轮子。技能的知识引导阶段会用 loom knowledge check 判断覆盖率、用 loom map --deep 建立结构基线，再派子代理分别整理入口点、模式、约定。实际体验：前期多花一些时间，但后续阶段的返工明显减少；注意 doc/loom/knowledge/ 已足够完善时不要重复生成，否则纯属浪费令牌。
场景三：治理「测试全绿但功能没接上」 这是技能最针对的痛点。集成验证阶段被强制要求做布线验证与手工冒烟测试：CLI 命令是否注册可调用、API 端点是否安装可达、UI 组件是否渲染可交互，并由多个审查子代理（安全、资深工程、测试）并行审查且必须修复问题而非只报告。实际体验：这一阶段往往是最耗时的一环，但也是唯一能给出「整个计划单一权威通过/失败结论」的环节。
场景四：受限环境下的代理执行
痛点是不敢让代理自由访问网络或读取私钥。技能会收集网络域名、敏感路径、构建工具，生成 sandbox 配置，支持按阶段覆盖（例如只在某个阶段放开 build/** 写入）。实际体验：配置项细，network 必须写成结构体这类细节容易写错，好在有 loom sandbox suggest 可以兜底。
整体体验小结：上手难度中等偏高，主要成本在于理解阶段类型、路径相对规则与验证字段；效果上，计划的可执行性和可校验性提升明显；注意事项是坚决避免在 YAML 描述中嵌套代码围栏，以及牢记路径相对 working_dir 解析这两条最容易踩的坑。
6. 该技能能为用户带来的价值
- 把「计划」从文档升级为可执行工件：固定的落盘位置、机器可解析的 YAML、可被
loom init校验拒绝的硬约束，让计划第一次具备「不达标就启动不了」的严肃性。 - 吞吐量提升来自并行判断而非拍脑袋：先问文件是否重叠、是否存在代码依赖，再决定用子代理团队、并行子代理还是独立阶段，避免为并行付出不必要的工作树与会话开销。
- 显著降低返工成本：
truths/artifacts/wiring三件套直接对准「编译通过、测试通过、功能没接线」这一高频浪费点；集成验证阶段的一次性权威结论也避免了「每个人都以为别人验过」。 - 知识资产可累积：知识引导 → 内存记录 → 集成验证策展的闭环，使每次任务的教训沉淀为下次可读的知识文件与
mistakes.md，长期看是团队级的复利收益。 - 降低协作与审查门槛：计划文档采用「人类可读在上、YAML 元数据在下」的结构，产品、测试、管理者无需读懂 YAML 也能快速审阅，代理则获得完整上下文。
7. 常见问题 FAQ
Q1：怎么安装这个技能？安装后怎么确认生效？
在 AI 技能市场/技能库中按技能 ID 13493 或英文名 loom-plan-writer 检索并一键添加即可，具体入口与目录以官方说明为准。同时需要环境中具备 Loom CLI。验证方式：让它「用 loom 创建执行计划」，输出应落在 doc/plans/PLAN-<描述>.md，且包含知识引导与集成验证两个书挡阶段和被 <!-- loom 元数据 --> 包裹的 YAML。
Q2：这个技能收费吗？ 技能自身的定价与授权方式取决于你使用的技能市场或技能库，请以官方说明为准；文中不涉及任何价格信息。需要额外准备的是 Loom 命令行工具的运行环境。
Q3：为什么我的计划被 loom init 拒绝了？
最常见的三种原因：一是某个 stage_type: standard 阶段没有写 truths、artifacts、wiring 中的任何一项；二是 stage_type 用了 PascalCase 而不是小写烤肉串命名；三是在 YAML 的 description 里嵌套了三反引号代码围栏，导致解析器崩溃并误报「缺少验证字段」。另外，working_dir 缺失、路径出现 ../、network 写成 deny 字符串而非结构体，也会导致校验失败。
Q4：什么情况下必须拆成独立阶段，什么时候用并行子代理？ 判断标准只有两条：任务之间是否触碰同一批文件（会合并冲突）、是否存在代码依赖（B 依赖 A 的产出）。两者皆否时，放进同一阶段用并行子代理更便宜；任一为真时，才拆成独立阶段并由 loom 合并分支。因为每个阶段都要新建 git 工作树、生成新会话，代价不小。
Q5：适合谁用？和通用 AI 编码助手怎么选？ 适合需要把中大型开发任务交给代理编排执行的团队与个人开发者，尤其是对「功能是否真的接线」有强要求的项目。如果只是小改动或一次性探索，直接让通用 AI 助手列个清单更轻；一旦进入多阶段并行、需要可校验计划与知识沉淀的场景，本技能的强制约束就是它的核心价值。