mcpField
V
v-planning

v-planning

github.com/desplega-aiAgent 工作流36274 次安装今天更新
代码仓库

关于 v-planning

用于将实现计划组织为可独立测试的垂直切片 DAG。它引导调研、依赖设计、步骤编写和结构验证，之后再将计划交由实现流程处理。

主要功能

  1. 01基于 DAG 的实现计划
  2. 02带依赖关系的垂直切片
  3. 03将调研委派给子 Agent
  4. 04自动验证计划结构
  5. 05步骤级与全局成功标准

适用场景

  1. 01规划可并行的功能实现
  2. 02将工作拆分为可独立测试的步骤
  3. 03为新的实现会话准备计划

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/desplega-ai/ai-toolbox --skill v-planning

安装后在 Claude Code 中输入/v-planning确认已加载。

附带文件templates/root.mdtemplates/step.md

详细介绍

v-planning

你可以将实现计划编写为垂直步骤组成的 DAG——每个步骤都是一个完整且可进行 QA 的价值切片（针对一项功能，包含 DB + API + UI + 测试）。DAG 描述功能级依赖关系，因此可以由子 Agent 并行实现互不依赖的步骤。

输出为一个计划目录：thoughts/<username|shared>/plans/YYYY-MM-DD-description/：

root.md            # Overview, mermaid DAG, step index, Global Verification
step-1.md          # frontmatter (id, name, depends_on) + Success Criteria
step-2.md
└── step-N.md

开始前的设置

  1. 自主模式——由调用命令传入；若未指定，默认为 Critical。

    模式行为
    Autopilot独立开展调研，编写完整计划目录，最后仅提交审阅
    Critical（默认）每完成一个调研步骤后，在起草前询问澄清问题；尤其要在 DAG 分解阶段列出设计选项
    Verbose每个子步骤都进行确认：验证理解、确认范围、指出未知事项，并在编写每个步骤文件前征求确认

  2. 提交偏好——除非处于 Autopilot 模式，否则通过 AskUserQuestion 询问一次：

    问题选项
    “手动验证通过后，是否在每个步骤完成时创建提交？”1. 是（推荐），2. 否，我会自行处理提交

  3. 以往经验——**可选子技能：**如果 ~/.agentic-learnings.json 存在，先运行 /learning recall <topic>。

10 条规则

  1. 先搭建框架——在任何调研之前，先退出计划模式，并使用 cc-plugin/base/skills/v-planning/templates/root.md 创建计划目录及其中的 root.md。（如果知道用户姓名，就使用该姓名，例如 taras；否则使用 thoughts/shared/。）随着 DAG 在规则 4 中逐渐成形，再添加步骤文件。目录逐步完善，用户可以及早纠正方向。

  2. 繁重工作全部交给子 Agent——文件读取、调研、验证。默认设置 run_in_background: true。不要将原始工具输出放入主会话。 子 Agent 选项：codebase-locator（查找文件）、codebase-analyzer（理解当前实现）、codebase-pattern-finder（查找相似功能）、context7 MCP（库／框架详情）、Explore 或 general-purpose（阅读提及的文件）。

  3. 通过 AskUserQuestion 提问——参阅 desplega:ask-user 了解规范。切勿在聊天中以普通项目符号列表提问。

  4. Critical/Verbose 模式下每完成一个步骤都提问，然后继续循环——按章节逐步编写计划：当前状态分析 → 实现方案 → DAG 分解 → 各步骤详情。每个章节都按以下流程进行：启动子 Agent → 综合调查结果（附 file:line 引用）→ 通过 AskUserQuestion 询问未解决的问题 → 起草 → 进入下一章节。

    • DAG 分解：识别垂直切片（每个切片都能独立进行 QA）、它们的依赖关系，以及任何明确的集成步骤。列出拟议的步骤清单和 mermaid 图，并通过 AskUserQuestion 确认结构，再起草步骤文件。
    • 各步骤详情：根据 cc-plugin/base/skills/v-planning/templates/step.md 创建每个 step-<n>.md。Frontmatter 中的 depends_on: [step-X, ...] 是权威信息；root.md 中的 mermaid 图和步骤索引表是派生视图——需保持同步。

  5. 每个步骤都要有具体交付物（垂直切片）——每个步骤的 Overview 都要说明完成后将有哪些文件／功能／产出。**每个步骤都必须能独立进行 QA。**仅分层的步骤（“DB 迁移”“只有端点”）都应视为问题——应将它们合并为垂直切片。“改进 X”和“重构 Y”也都属于问题。

  6. 用工作成果证明进度：尽量采用自动化验证和自动化 QA——尽可能将工作变为可运行的命令（低层级）和由 Agent 驱动的 QA（browser-use、截图差异比较、CLI 演练）。手动验证是例外。每个步骤都有自己的 Success Criteria 区块；root.md 包含 ## Global Verification，用于在整个 DAG 完成后才执行的跨步骤检查。仅在跨步骤／需要大量证据的 QA 场景下，才使用链接到 desplega:qa 文档的 ### QA Spec (optional):，不要用于常规的逐步骤检查。

  7. 建议拆分 — 当某个步骤包含 >4 个子步骤或 >2 个不同关注点时，将其拆分为多个 DAG 节点（适当连接依赖关系）。当整个 DAG 无法放进一次并行实现会话时，将其拆分为多个计划（例如：契约 → 存储 → UI）。线性 DAG 可以接受，但值得指出——线性的 planning 技能可能更合适。

  8. 坦率直言地提出异议 — 如果计划过大、含糊不清、混杂多个关注点或存在明显风险，请使用 desplega:feedback。沉默是毁灭性的同理心。

  9. 在展示计划前，使用 Haiku 子 Agent 验证结构（general-purpose，并设置 model: haiku）。请验证：每个 step-<n>.md 都包含全部三个“成功标准”小节（自动化验证 + 自动化 QA + 手动验证）；所有条目都使用 - [ ]；自动化检查都是可运行的命令；每个步骤的 depends_on 都引用了现有步骤 ID；DAG 中没有环；root.md 的 mermaid 图表与步骤索引表和步骤 frontmatter 一致；每个步骤的 frontmatter 都有 status: ready（新建计划；状态转换发生在 /v-implement 期间）；引用的路径都存在。请在展示前修正问题。

  10. 交接给新的会话——切勿在此处实现。 收尾步骤：

    1. 打开 /file-review:file-review <plan-dir>/root.md（Autopilot 模式除外）；逐条处理意见。如有需要，重新打开各个 step-<n>.md 文件。

    2. 可选择调用 desplega:reviewing 进行差距分析（通过 AskUserQuestion 提供此选项）。

    3. 可选子技能： 如果产生了重要见解，请通过 /learning capture 记录。

    4. 如果任何步骤包含 ### QA Spec (optional): 块，请在交接前通过 desplega:qa 生成 QA 文档（thoughts/<username|shared>/qa/YYYY-MM-DD-[feature].md）。场景应写在文档中，而不是计划中。

    5. 通过 AskUserQuestion 询问：

      问题选项
      "计划已就绪。接下来怎么做？"1. 在新会话中实现，2. 先运行 /review，3. 暂时完成（搁置计划）

    6. 明确告知用户："打开一个新的 Claude Code 会话并运行 /desplega:v-implement <plan-dir>。从全新会话开始可保持实现上下文干净。"

DAG 细则

  • 依赖关系以 frontmatter 为准。 root.md 的 mermaid 图表由其生成。若两者不一致，以 frontmatter 为准。
  • 步骤必须自成一体。 只拿到一个 step-<n>.md（以及来自 root.md 的计划级上下文）的子 Agent，应无需阅读其他步骤就能实现该步骤。
  • frontmatter 携带执行状态。 每个步骤的初始状态为 status: ready；desplega:step-running 会将状态依次转换为 claimed → done（可重试的失败则恢复为 ready），并在处于 claimed 状态时写入 assignee / claimed_at。这样，同一计划目录就能安全地由多个编排器实例驱动。步骤正文（所需更改、成功标准）在执行期间不可变——只有 frontmatter 和复选框状态会变化。
  • 必要时明确列出集成步骤。 如果并行的同级步骤需要进行非简单的整合（跨领域 e2e、共享界面协调），请添加一个显式的 step-N，设置 depends_on: [step-X, step-Y, ...]，其工作内容为“整合 + e2e”。否则，DAG 会在叶节点处结束。

提交集成

如果在 Setup 中启用了逐步骤提交：

  • 每个步骤通过手动验证后，使用格式 [step-N] <brief description> 提交。
  • 仅在明确确认手动验证通过后才提交。
  • 否则跳过——由用户处理提交。

成功标准格式（必须）

规范格式和标题层级见：

  • cc-plugin/base/skills/v-planning/templates/root.md（## Global Verification）
  • cc-plugin/base/skills/v-planning/templates/step.md（每个步骤的三类成功标准）

结构验证会自动运行（规则 9，Haiku 子 Agent）。

评论

支持 Markdown