Plan Crafting 的目标是从一个界定清晰的工作范围出发，写出一份可执行的计划文档，使任务能够以“worker-validator”成对的形式并行派发。
用途与定位 它用于任务范围已经明确、需要进行多步骤实现、且尚未触碰代码的阶段。触发时机包括：澄清技能完成并生成 Context Brief 文件之后；用户以清晰提示明确要求创建计划时；以及需要进行多步骤实现并需定义带依赖的任务顺序时。相反，若工作范围仍然模糊，应回到澄清技能；单文件编辑、简单缺陷修复等单步任务，或用户明确表示“跳过计划，直接做”时，不适用本技能。
核心原则与硬性要求 计划文档必须能被一个零代码库上下文的执行者直接执行，且无需任何额外提问，所有歧义都必须在规划阶段解决。硬性门槛包括：每一步都必须可执行，绝不允许占位符（如 TBD、TODO、“稍后实现”）；必须防止任务冲突，修改同一文件的任务不得并行运行，存在依赖的任务必须等待前序任务完成；必须进行自我审查；任务须分解到最小功能单元，一个任务产出一个明确的交付物。
输入 本技能以 Context Brief 文件作为输入，用于填充计划头部：Goal 映射到目标，Scope（In/Out）映射到工作范围（包含/排除），Technical Context 映射到架构、技术栈及文件结构映射依据，Constraints 在进行任务分解时作为约束体现，Success Criteria 用作自我审查标准，Open Questions 作为计划中的假设体现并与用户确认。若不存在 Context Brief 文件而用户直接请求计划，则需先与用户确认目标、工作范围、技术栈等必要信息。
计划文档结构与保存位置 默认保存位置为 docs/engineering-discipline/plans/YYYY-MM-DD-<feature-name>.md，用户对计划位置的偏好可覆盖此默认值。文档头部包含：标题（[Feature Name] Implementation Plan）、面向执行者的说明（按任务逐条执行，每步使用复选框语法跟踪进度）、Goal、Architecture、Tech Stack、Work Scope（in scope / out of scope）、Verification Strategy（级别、命令、验证内容）。
文件结构映射 在定义任务之前，先梳理将要创建或修改的文件，分解决策在此阶段锁定。每个文件应有单一明确职责；一起变更的文件应放在一起，按职责而非技术层拆分；遵循现有代码库模式；文件结构为任务分解提供依据，每个任务应产出可独立理解的、自包含的变更。
验证发现与项目能力发现 在分解任务前，发现项目最高层级的验证能力，这决定了每个计划收尾的最终验证任务。发现顺序为：现有端到端测试（e2e）→ 集成测试 → 验证类技能或智能体 → 项目测试套件 → 构建加 lint。若仅有第 5 级（无有意义验证），则需新增 Task 0：创建验证基础设施，搭建本计划所需的最小验证，使测试在实现前失败、在所有任务完成后通过。同时，应发现项目中可被 worker 利用的智能体与技能（项目级、插件级、项目技能），并在适用的任务步骤中引用；这些只是效率提示，worker 并非必须使用。
任务分解 任务应面向最大并行化设计，但以下情况需等待前序任务完成：修改同一文件的任务、一个任务输出被另一任务引用的接口依赖、修改共享状态（数据库模式、配置文件等）的任务。依赖关系写入任务头部，无依赖的任务标记为可并行。每个任务按 worker-validator 结构设计：worker 执行任务步骤，以任务的目标与验收标准为约束性契约，当代码库与某步骤冲突时做最小自适应；validator 仅针对验收标准逐条二值判定。每个步骤应为一个动作（2–5 分钟），如“写失败的测试”“运行确认失败”“写最小实现”“运行确认通过”“提交”。
任务格式 包含 Task N 名称、Goal（一句话，可原样复制进 validator 提示）、Dependencies、Files（Create/Modify/Test 及锚点）、Acceptance Criteria（可二值判定条件）、以及带复选框的步骤（含实际代码与确切命令及预期输出）。文件引用使用符号锚点（函数名、类名、配置键、段落标题），而非行号，因行范围在文件被编辑后会失效。
验收标准规则 验收标准是任务的契约，不可协商，validator 只判定它。每个任务至少一条标准；无法用标准陈述完成的任务不算任务。每条标准必须可二值判定，独立 validator 阅读代码并运行所列命令后应能回答“达成/未达成”而无需判断。例如“代码干净”“合理处理错误”“正确工作”“足够快”为计划失败；“pytest tests/api/test_users.py 通过”“缺少 email 的 POST /api/users 返回 400”“grep -r 'legacyParser' src/ 无匹配”为可二值判定。任务总判定为其各标准的逻辑与，无部分完成。
最终验证任务 每个计划必须以最终验证任务收尾，运行所发现的最高层级验证，始终是最后一个任务，依赖所有其他任务，不可并行。步骤包括：运行最高层级验证（预期全部通过）、逐条检查计划头部成功标准、运行完整测试套件检查回归。若最终验证失败，则计划未完成。
无占位符与注意事项 每一步必须包含 worker 所需实际内容，禁止“稍后填充”“添加适当错误处理”“为以上编写测试”（无实际测试代码）、“同 Task N”（需重复代码）等写法，也禁止未定义类型的引用和不可二值判定的验收标准。应始终给出确切文件路径、每步完整代码、含预期输出的确切命令，并遵循 DRY、YAGNI、TDD 与频繁提交。
自我审查 写完计划后以全新视角对照规格自查：规格覆盖（每个需求能否对应到任务）、占位符扫描、类型一致性（后续任务中的类型、方法签名、属性名是否与之前定义一致）、依赖验证（并行任务不修改同一文件、依赖链无缺失）、验证覆盖（是否含最终验证任务并引用发现的验证命令，若无验证是否有 Task 0）、标准可判定性（以敌意 validator 视角逐条检查）。发现问题就地修复。
执行交接与反模式 保存计划后提供执行选择：子智能体执行（推荐，每个任务派发新子智能体，任务间审查，快速迭代）或内联执行（在本会话中使用 run-plan 技能批量执行并在检查点处停下）。常见反模式包括：把修改同一文件的任务标为并行、列出任务却不写依赖、假设“worker 会自己搞明白”、批准含占位符的计划、未自我审查就完成计划。
最小检查清单与过渡 完成计划编写时自查：所有任务是否都有确切文件路径；每个任务是否有目标与可二值判定的验收标准；所有步骤是否含可执行代码/命令；并行任务间是否无文件冲突；依赖链是否准确；计划是否覆盖全部规格需求；是否无占位符；头部是否有验证策略；最终验证任务是否为最后一个任务。计划批准后如需执行则转到 run-plan 技能；若发现工作范围仍有歧义，则回到澄清技能解决。本技能自身不调用下一个技能，而是以呈现计划文档、由用户选择下一步作为结束。