plan-maker

计划制定器

使用此技能，根据不完整的输入设计一份符合 PlanWeave 软件包结构的计划草案。只有用户要求具体生成文件时，才编写软件包文件。使用 plan-auditor 审核现有软件包；执行属于单独任务，需要用户提出执行请求。

必需的规划检查清单

使用规划检查清单检查计划结构、执行选项、验收标准和软件包有效性。

快速开始

1. 重述用户的目标、非目标、约束条件和可能的成功标准。
2. 仅提出会阻碍工作的澄清问题；否则说明假设并继续。
3. 从 README、当前代码、架构、测试、示例和相关文档中收集必要的上下文。
4. 确定核心对象、生命周期阶段、契约、风险和验证路径。
5. 起草任务、区块、依赖关系、提示词放置位置、评审关卡和验证方式，然后使用 PlanWeave 现有的软件包概念将任务分组到画布中。
6. 最后列出尚未明确的假设，并建议下一步操作：与用户进一步完善、使用 plan-auditor 审核，或在用户明确要求时将草案具体生成为文件。

上下文探索

• 如果有完善的源文档，且主要工作是将其转换为 Plan Package，请使用 plan-importer。
• 如果没有文档，应检查当前代码库，了解足够的信息以避免虚构架构。
• 在拆分任务前，搜索相关核心对象的生产方和使用方。
• 以用户目标为准，但要标明不确定的范围、缺失的领域规则和未知的外部依赖。
• 不要为了让计划显得完整而虚构大量产品需求。

规划原则

• 围绕核心对象的生命周期进行设计：创建、验证、转换、状态、存储、使用、副作用、最终输出、失败、重试、回滚和人工干预。
• 确保生产方和使用方的架构、类型、API、CLI 标志、事件、文件以及提示词输入和输出保持一致。
• 按数据流、契约边界、职责归属、风险或可独立验证的验收标准拆分任务。
• 不要只为增加节点而拆分任务；应合并那些无法独立认领、测试或报告的细小任务。
• 画布用于组织一项内聚的交付成果；任务负责实现可独立验证的结果；区块则表示执行和评审步骤。将设计细节放入提示词，并使抽象程度与工作规模相称。
• 默认使用一个画布来呈现一项内聚的交付成果，并通过任务或区块表达实现、测试和验收。对于独立交付或维护的范围，使用多个画布，并明确说明各自的具体边界。单画布计划可以省略新的 project-graph.json 文件生成；多画布计划则使用正式的项目图。
• 在图依赖关系和关卡中明确规定必需的执行顺序，而不是只写在提示词或叙述文本中。
• 并行任务在数据和契约时序上必须真正独立；对共享文件、配置和构建输出的写入必须相互隔离或协调。
• 使用 parallel.sharedResources 记录重叠资源；此项仅供参考，不会起到锁定作用。如果共享写入无法协调，应限制并发；使用调度设置，而不要人为添加依赖边。
• 在基础契约和运行时行为稳定之前，不要安排大范围的 UI 或软件包优化工作。
• 遵循目标代码库现有的约定。

计划结构

输出一份包形状的计划草案，以及一份便于阅读的说明。草案必须以 PlanWeave 的现有概念作为后续物化的事实来源：项目图、画布、任务、区块、依赖项、提示词文件和布局。Markdown 报告仅用于说明。

如果不写入文件，请将草案展示为包文件计划，而不是新建一种架构。对于多画布编排，按需包含项目图字段：

Project:
  title: ...
  projectGraph: project-graph.json

Canvases:
  - id: ...
    packageDir: ...
    manifest: .../manifest.json
    tasks: ...

Dependencies:
  canvas: ...
  crossTaskEdges: ...

Prompts:
  .../nodes/.../prompt.md

人类可读的计划说明建议使用以下 Markdown 章节；可以合并较短的章节，也可以省略不适用的章节。任务和区块的源提示词遵循下方的「提示词放置」部分。

## Goal
## Assumptions And Open Questions
## Canvas Strategy
## Project Graph
## Task Graph
## Prompt Placement
## Review Strategy
## Verification Strategy
## Risks And Recovery
## Handoff

每项任务都应包括：

• 任务 ID、标题、所属画布、目标、验收标准、依赖项和可能涉及的文件。
• 区块的类型、用途、共享资源、完成标准、验证方式和报告要求。
• 下方「评审策略」中定义的适用评审门。
• 复杂区块必须包括架构边界、测试位置、配置／环境变量处理方式、适用时对 README 或 .env.example 的更新，以及真实提供方与模拟／试运行的预期。

多画布草案应包含 Project Graph 章节，其中包括：

• 画布 ID、标题、包目录，以及每个画布的存在原因。
• 用于表示阶段、能力、子系统或工作流顺序的画布级依赖边。
• 多画布草案默认设置 crossTaskEdges: []。
• 添加跨任务边之前，应先将紧密耦合的任务移到同一画布；或者在依赖关系决定整个阶段、能力、子系统或工作流的顺序时，使用画布依赖边。
• 仅当不同画布之间存在稀疏且无法化简的任务阻塞关系，而这些画布本身具有内聚性且可独立执行时，才使用显式的 crossTaskEdges。
• 同一画布间密集或重复的跨任务边、通过任务边表达阶段级顺序，以及与画布顺序重复的任务边，都视为画布边界缺陷；应重新划分任务，或将依赖提升到画布级。
• 指明哪些画布可以并行运行，以及它们的数据、契约和上游阻塞项为何相互独立； 说明如何隔离或协调共享写入，以及适用哪些并发限制。
• 任何手动编辑项目图的假设。

提示词放置

• 全局／项目提示词：共享目标、架构规则、编码标准、参考资料和跨领域风险。
• 任务提示词：任务本地上下文、验收理由、依赖项和可能涉及的文件。
• 区块提示词：精确的执行说明、约束、验证命令和报告要求。
• 要求应写在源提示词或任务验收标准中，不能只写在计划报告里。
• 不要将区块提示词留空；如果继承的上下文已足够，应明确说明具体的完成条件。

评审策略

• 对简单文档、配置微调、文案编辑和低风险的局部修复，除非用户提出要求，否则跳过评审。
• 对跨层代码、架构／API／CLI 契约、数据库变更、提供方集成、安全／隐私、架构设计或高风险的用户可见行为，添加评审。
• 评审门应说明其设置原因、执行者、通过标准，以及 needs_changes 将返回到何处。

验证策略

• 每个区块都需要可观察的完成标志：命令、测试、输出产物、状态转换或端到端流程。
• 区分模拟、试运行、实际运行路径和真实产物。
• 不接受「已实现」「逻辑正确」或「看起来可用」之类的验收标准。
• 如果功能需要可靠执行，应包括失败路径验证。

规则

• 此技能生成的是包结构的计划草稿，而非运行时状态。
• 不要创建上下文节点；将上下文放在提示词、验收标准或参考资料中。
• 不要创建 feedback 块；反馈属于运行时状态。
• 在物化计划时，将包结构的计划草稿作为权威输入。使用 PlanWeave CLI 解析工作区，写入声明的包文件，通过 PlanWeave CLI 验证，并报告剩余诊断信息。
• 对画布创建、路径分配、ID 去重、活动画布选择、验证、恢复事务以及运行时状态／结果变更等机械工作区操作，使用 CLI／运行时命令。
• 直接在 CLI 返回的工作区路径中编辑计划包语义文件：project-graph.json 中的画布意图和依赖关系、每个画布 manifest.json 中的任务／块／边／验收标准／提示词路径，以及源提示词 Markdown。
• 如果精确表达语义变更的 CLI 编辑命令可用，则使用该命令；否则，直接更新源包文件和提示词。
• 直接编辑计划后，对已编辑的画布运行画布范围验证；如果 project-graph.json、画布边或 crossTaskEdges 发生变更，则运行项目验证。
• 确认集成和审查任务受到其所需上游工作的阻塞，并确认并发设置符合共享资源约束。桌面应用可用时，检查可见任务、依赖边和布局是否清晰易读；报告任何未经验证的检查项。
• 如果草稿计划用于执行，且风险较高，建议在导入前进行审查。