blueprint

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Blueprint Skill

蓝图Skill

Purpose

用途

Produce collaborative implementation plans as written artifacts, where every step follows a build-review-verify cycle. Transform vague feature requests, architectural changes, or refactoring goals into concrete, sequenced plans that a human or agent can execute step by step. Treat planning as a dialogue — explore the codebase, discover tooling, ask questions, compare approaches, assess complexity, then generate the plan.

生成可协作的书面实施计划产物，每一步都遵循构建-评审-验证周期。将模糊的功能需求、架构变更或重构目标转化为可由人或Agent逐步执行的具体、有序计划。将规划视为对话过程：探索代码库、梳理工具链、提出疑问、对比方案、评估复杂度，再生成最终计划。

Effort Level

投入程度

Scale exploration depth to task complexity, but always err toward more thoroughness. Read broadly before narrowing — the goal is a plan that surfaces zero surprises during execution.

探索深度可随任务复杂度调整，但始终应倾向于更全面的调研。在缩小范围前先做广泛的信息收集，目标是生成执行过程中不会出现意外问题的计划。

Anti-pattern: "Too Simple to Plan"

反模式：「过于简单无需规划」

Even a one-line change carries assumptions about where it goes, what it affects, and how it gets verified. "Simple" tasks are precisely where unexamined assumptions cause wasted rework — the build-review-verify structure catches those before they compound. A plan can be a single step with one acceptance criterion; the fast-path for small plans (≤2 steps) already keeps overhead minimal. The anti-pattern is skipping planning entirely, not the plan's size.

即便是单行代码变更，也隐含了对代码位置、影响范围、验证方式的假设。「简单」任务恰恰是未经验证的假设导致返工浪费的重灾区，构建-评审-验证结构可以在问题放大前提前发现隐患。计划可以是只有一个验收标准的单步骤，≤2步的小计划快速通道已经将 overhead 降到最低。反模式指的是完全跳过规划，而不是计划本身的篇幅大小。

Design Principles

设计原则

Prose Over Code

文字优先于代码

Plan steps describe intent in prose. Do not include code blocks except for interface signatures, config keys, and schema shapes (full policy in

references/step-template.md

). Tool commands in Phase 3 checklists are operational instructions, not code — they are always permitted.

计划步骤用文字描述意图。除了接口签名、配置键和 schema 结构外，不要包含代码块（完整规则见

references/step-template.md

）。第三阶段检查清单中的工具命令属于操作指令，不属于代码范畴，始终允许使用。

Workflow

工作流

dot

digraph blueprint {
    rankdir=TB
    node [shape=box, style=rounded, fontname="Helvetica", fontsize=10]
    edge [fontname="Helvetica", fontsize=9]

    explore   [label="Explore codebase\n& discover tools"]
    confirm   [label="Confirm tool chain\nwith user"]
    clarify   [label="Clarify requirements"]
    gate      [label="Planning gate\nready?", shape=diamond]
    fastappr  [label="Fast-path\napproach?", shape=diamond]
    propose   [label="Propose 2-3\napproaches"]
    pick      [label="User picks\napproach"]
    assess    [label="Assess complexity"]
    generate  [label="Generate plan"]
    fastrev   [label="Fast-path\nreview?", shape=diamond]
    review    [label="Adversarial review\n(subagent)"]
    passed    [label="Review\npassed?", shape=diamond]
    done      [label="Plan ready\nfor execution", shape=doublecircle]

    explore  -> clarify
    clarify  -> confirm
    confirm  -> gate
    gate     -> fastappr  [label="yes"]
    gate     -> clarify   [label="no — gaps remain"]
    fastappr -> assess    [label="yes — single\nobvious strategy"]
    fastappr -> propose   [label="no"]
    propose  -> pick
    pick     -> assess
    assess   -> generate
    generate -> fastrev
    fastrev  -> done      [label="≤2 steps"]
    fastrev  -> review    [label=">2 steps"]
    review   -> passed
    passed   -> done      [label="yes"]
    passed   -> generate  [label="no — fix issues"]
}

<PLANNING-GATE> Do not begin plan generation until: (1) the user has confirmed the discovered tool chain, and (2) all critical ambiguities surfaced during clarification have been resolved. An ambiguity is critical if resolving it differently would change the plan's structure, step count, or chosen approach. Proceeding without both produces plans built on guesswork. </PLANNING-GATE>

dot

digraph blueprint {
    rankdir=TB
    node [shape=box, style=rounded, fontname="Helvetica", fontsize=10]
    edge [fontname="Helvetica", fontsize=9]

    explore   [label="Explore codebase\n& discover tools"]
    confirm   [label="Confirm tool chain\nwith user"]
    clarify   [label="Clarify requirements"]
    gate      [label="Planning gate\nready?", shape=diamond]
    fastappr  [label="Fast-path\napproach?", shape=diamond]
    propose   [label="Propose 2-3\napproaches"]
    pick      [label="User picks\napproach"]
    assess    [label="Assess complexity"]
    generate  [label="Generate plan"]
    fastrev   [label="Fast-path\nreview?", shape=diamond]
    review    [label="Adversarial review\n(subagent)"]
    passed    [label="Review\npassed?", shape=diamond]
    done      [label="Plan ready\nfor execution", shape=doublecircle]

    explore  -> clarify
    clarify  -> confirm
    confirm  -> gate
    gate     -> fastappr  [label="yes"]
    gate     -> clarify   [label="no — gaps remain"]
    fastappr -> assess    [label="yes — single\nobvious strategy"]
    fastappr -> propose   [label="no"]
    propose  -> pick
    pick     -> assess
    assess   -> generate
    generate -> fastrev
    fastrev  -> done      [label="≤2 steps"]
    fastrev  -> review    [label=">2 steps"]
    review   -> passed
    passed   -> done      [label="yes"]
    passed   -> generate  [label="no — fix issues"]
}

<PLANNING-GATE> 满足以下两个条件前不要开始生成计划：(1) 用户已确认梳理出的工具链；(2) 需求澄清阶段发现的所有关键歧义都已解决。如果不同的歧义解决方式会改变计划结构、步骤数量或所选方案，则该歧义属于关键歧义。未满足这两个条件就推进，生成的计划将建立在猜测之上。 </PLANNING-GATE>

1. Understand the Task and Discover Tooling

1. 理解任务与梳理工具链

Begin by reading the codebase broadly. Examine:

Project structure (directories, modules, packages).
Entry points (main files, route definitions, CLI commands).
Data layer (models, schemas, migrations, repositories).
Configuration (settings files, environment variables, feature flags).
Existing tests (test structure, fixtures, factories, coverage).
Documentation (architecture docs, ADRs, READMEs with setup instructions).

While exploring, discover project tooling. Tool discovery is not a separate phase — it happens naturally during codebase exploration. As configuration files, CI pipelines, and lock files are encountered, record the test runner, linter, formatter, type checker, and package manager they imply. See

references/tool-discovery.md

for the full per-language lookup table and detection methodology. When CI pipeline commands conflict with config file commands, prefer the CI commands — they reflect what actually runs.

Then ask clarifying questions. Focus on:

What the user actually wants (not what they said — these sometimes differ).
What constraints exist that are not visible in the code.
What the definition of done looks like for this work.
Whether there are related changes planned that this should accommodate.

Iterate on understanding. Summarize what has been gathered so far, identify gaps, and ask follow-up questions. Two to three rounds of clarification is normal for non-trivial plans. For simple, well-defined tasks, one round may suffice.

When planning involves architectural decisions that benefit from diagrams or visual comparison of approaches, the superpowers plugin's visual companion can render these in a browser. This capability requires the superpowers plugin to be installed; no fallback is provided if it is absent.

Required deliverable before proceeding: Present the discovered tool chain to the user for confirmation. Format it as a numbered list with the source of each discovery in parentheses. The user may confirm, add, remove, or reorder tools. Do not proceed to step 2 until the tool chain is confirmed. Example:

Discovered tools for this project:

1. Package manager: uv (from uv.lock)
2. Test runner: pytest (from pyproject.toml [tool.pytest])
3. Linter: ruff check . (from pyproject.toml [tool.ruff])
4. Formatter: ruff format --check . (from pyproject.toml [tool.ruff.format])
5. Type checker: mypy . (from pyproject.toml [tool.mypy])

Add, remove, or reorder? (or confirm to proceed)

Fast-path for small plans: If the user's request is narrowly scoped (e.g., a config change, single-file refactoring, or other small task that will clearly result in 2 or fewer steps), discover tools as normal but present them inline with the generated plan rather than as a separate confirmation gate. Still include the tool chain table in the plan header. For plans with 3 or more steps, or architecturally significant plans, keep the separate confirmation step described above.

首先广泛阅读代码库，检查以下内容：

项目结构（目录、模块、包）
入口点（主文件、路由定义、CLI 命令）
数据层（模型、schema、迁移文件、仓储层）
配置（配置文件、环境变量、功能开关）
现有测试（测试结构、fixture、factory、覆盖率）
文档（架构文档、ADR、包含搭建说明的README）

探索过程中同步梳理项目工具链。工具梳理不是独立阶段，会在代码库探索过程中自然完成。遇到配置文件、CI 流水线、锁文件时，记录其中隐含的测试运行器、linter、格式化工具、类型检查器和包管理器。完整的各语言查询表和检测方法见

references/tool-discovery.md

。如果CI流水线命令与配置文件命令冲突，优先采用CI命令——它们反映了实际运行的规则。

之后提出澄清问题，重点关注：

用户的真实需求（而非字面表述，二者有时存在差异）
代码中不可见的约束条件
本次工作的完成定义
是否有需要兼容的相关变更计划

迭代确认需求理解：总结目前收集到的信息，识别信息缺口，提出跟进问题。非 trivial 的计划通常需要2-3轮澄清，简单明确的任务1轮即可。

如果规划过程中的架构决策需要用图表或可视化方案对比来呈现，可使用 superpowers 插件的可视化配套功能在浏览器中渲染。该能力需要预先安装 superpowers 插件，如未安装无降级方案。

推进前的必填产出：将梳理出的工具链提交给用户确认，格式为编号列表，括号中注明每个工具的发现来源。用户可以确认、新增、移除或重新排序工具。工具链确认前不要进入第2步。示例：

Discovered tools for this project:

1. Package manager: uv (from uv.lock)
2. Test runner: pytest (from pyproject.toml [tool.pytest])
3. Linter: ruff check . (from pyproject.toml [tool.ruff])
4. Formatter: ruff format --check . (from pyproject.toml [tool.ruff.format])
5. Type checker: mypy . (from pyproject.toml [tool.mypy])

Add, remove, or reorder? (or confirm to proceed)

小计划快速通道：如果用户需求范围很窄（例如配置变更、单文件重构，或其他明显只会生成2步及以内的小任务），照常梳理工具链，但不要单独设置确认环节，而是和生成的计划一起呈现。但仍需在计划头部包含工具链表。如果计划包含3步及以上，或是架构层面的重要计划，保留上述单独确认步骤。

2. Propose Approaches

2. 提出可选方案

Once the task is understood and tooling confirmed, outline 2-3 candidate implementation strategies before locking in a plan structure. For each, describe the approach in a sentence or two and call out its key trade-offs — what it optimizes for, what it sacrifices, and where it carries risk. Open with the strategy you recommend and explain the reasoning; then present the alternatives so the user can make an informed choice. Wait for the user to select an approach before moving to complexity assessment and plan generation.

Fast-path: When the task is narrowly scoped and only one credible strategy exists, state it briefly and move on — inventing artificial alternatives wastes time and muddies the conversation.

理解任务且工具链确认后，在锁定计划结构前先梳理2-3个候选实现策略。每个方案用1-2句话描述，说明核心权衡：优化点、牺牲项、潜在风险。开头先说明你推荐的方案及理由，再呈现其他备选方案，方便用户做出知情选择。等待用户选定方案后，再进入复杂度评估和计划生成环节。

快速通道：如果任务范围很窄且只有一种可行策略，简要说明后直接推进，人为编造备选方案只会浪费时间、混淆沟通。

2. Assess Complexity

2. 评估复杂度

With the approach selected, determine the plan's scope:

Count the anticipated steps. Each step should represent a single logical unit of work — larger than a trivial config change, smaller than a full feature. If it can be described in one sentence, merge it with an adjacent step. If it needs its own sub-plan, split it.
Evaluate whether natural milestones exist (e.g., "data layer first, then API, then UI").
Choose the output format based on step count:
- 5 or fewer steps, single concern: single plan document.
- 6-8 steps, single concern: single document with grouped headings.
- Distinct phases or more than 8 steps: milestone folder with one file per milestone.
- Ambiguous: ask the user.

Step sizing guidance:

Each step must be independently verifiable — all its tests pass without depending on future steps being complete.
Steps should build on each other sequentially. Later steps may depend on earlier steps, but not the reverse.
Avoid steps that are purely structural ("set up the directory") unless the project has no existing structure. Structural work should be folded into the first functional step.

选定方案后，确定计划的范围：

统计预期步骤数：每个步骤应代表一个逻辑工作单元，比 trivial 的配置变更大，比完整功能小。如果一句话就能描述，可以和相邻步骤合并；如果需要单独的子计划，就拆分。
评估是否存在天然里程碑（例如「先做数据层，再做API，最后做UI」）。
根据步骤数选择输出格式：
- 5步及以内，单一关注点：单份计划文档
- 6-8步，单一关注点：单份文档，步骤按分组标题组织
- 存在不同阶段或超过8步：里程碑文件夹，每个里程碑对应一个文件
- 不确定：询问用户

步骤大小指导：

每个步骤必须可独立验证：所有测试可通过，不依赖后续步骤完成
步骤应按顺序递进，后续步骤可依赖前置步骤，反之不可
避免纯结构类步骤（例如「创建目录」），除非项目没有现有结构。结构类工作应合并到第一个功能性步骤中

3. Generate the Plan

3. 生成计划

Write the plan artifact(s) following the structure defined in

references/step-template.md

. Every step includes all three phases: Build, Adversarial Review, and Verification.

Plan header: Include a title, date, summary of the goal, and the confirmed tool chain.

markdown

undefined

按照

references/step-template.md

定义的结构编写计划产物。每个步骤都包含三个阶段：构建、对抗性评审、验证。

计划头部：包含标题、日期、目标摘要、已确认的工具链。

markdown

undefined

Plan: [Feature/Change Title]

Date: YYYY-MM-DD Goal: [1-2 sentence summary of what this plan achieves]

Tool Chain

Category	Tool	Command
Test runner	[discovered]	`[test command]`
Linter	[discovered]	`[lint command]`
Type checker	[discovered]	`[type-check command]`
Formatter	[discovered]	`[format command]`

Category	Tool	Command
Test runner	[discovered]	`[test command]`
Linter	[discovered]	`[lint command]`
Type checker	[discovered]	`[type-check command]`
Formatter	[discovered]	`[format command]`

Steps

[Steps follow here, each using the 3-phase template]


**Step generation rules**:

- Number steps sequentially starting from 1.
- Write clear, specific titles that describe the deliverable ("Add user authentication endpoint"), not the activity ("Work on authentication").
- Write acceptance criteria that are concrete and testable. Avoid vague criteria like "code is clean" or "performance is good." Use measurable conditions: "Response time under 200ms for 95th percentile," "All validation errors return 422 with field-level messages."
- In Phase 1 (Build), describe intent per the prose-first approach. Specify what to create, modify, and test. Reference existing code patterns where applicable ("Follow the same repository pattern used in `src/repos/product_repo.py`").
- In Phase 2 (Adversarial Review), write step-specific review questions targeting the most likely failure modes, but also include broader integration questions: Does this change fit naturally in the existing codebase? Does it follow established conventions and patterns? Could it break or degrade anything outside its immediate scope? The review is a thorough, critical code review of the work done — not just an acceptance criteria checklist. The goal is to eliminate all issues introduced by the build phase before proceeding.
- In Phase 3 (Verification), include the full checklist with tool commands from the confirmed tool chain. Add step-specific verification items beyond the standard checks.

**Dependency tracking**: If a step depends on artifacts from a previous step, state the dependency explicitly in the objective. Example: "Depends on Step 2 (user repository). Uses the `UserRepository` interface defined there."

**Writing the milestone folder** (when applicable):

- Create one file per milestone: `01_milestone-name.md`, `02_milestone-name.md`, etc.
- Each milestone file follows the same structure (header, tool chain, steps).
- Add a root `README.md` in the plan folder that lists milestones in order with one-sentence descriptions.
- Keep milestones to 3-5 steps each. If a milestone has more, split it.

[Steps follow here, each using the 3-phase template]


**步骤生成规则**：

- 步骤从1开始顺序编号
- 编写清晰具体的标题，描述交付物（例如「新增用户认证端点」），而非活动（例如「做认证相关工作」）
- 验收标准要具体可测，避免「代码整洁」「性能良好」这类模糊标准，使用可量化条件：「95分位响应时间低于200ms」「所有校验错误返回422状态码和字段级错误提示」
- 第一阶段（构建）按照文字优先的原则描述意图，说明需要创建、修改、测试的内容，可参考现有代码模式（例如「遵循`src/repos/product_repo.py`中使用的仓储层模式」）
- 第二阶段（对抗性评审）编写针对该步骤最可能故障模式的评审问题，同时包含更广泛的集成问题：该变更是否适配现有代码库？是否遵循已有的规范和模式？是否会破坏或影响其直接范围外的功能？评审是对完成工作的全面严格代码评审，不只是验收标准检查清单，目标是在推进前消除构建阶段引入的所有问题
- 第三阶段（验证）包含已确认工具链的完整检查命令清单，在标准检查之外补充步骤特有的验证项

**依赖跟踪**：如果某个步骤依赖前置步骤的产物，在目标中明确说明依赖关系，例如：「依赖步骤2（用户仓储层），使用其中定义的`UserRepository`接口」。

**里程碑文件夹编写规则**（适用时）：

- 每个里程碑对应一个文件：`01_milestone-name.md`、`02_milestone-name.md`等
- 每个里程碑文件遵循相同结构（头部、工具链、步骤）
- 在计划文件夹根目录添加`README.md`，按顺序列出所有里程碑及一句话说明
- 每个里程碑包含3-5个步骤，超过则拆分

5. Adversarial Plan Review

5. 计划对抗性评审

After writing the plan to disk, dispatch a subagent to perform an adversarial review of the entire plan. The subagent reads the plan fresh from disk with no anchoring to the planning context — it acts as a critical second pair of eyes whose sole purpose is to find weaknesses before execution begins.

Why a subagent: The agent that wrote the plan is anchored to its own reasoning. A fresh subagent without the full planning conversation history reads the plan as an executor would — spotting ambiguities, gaps, and logical flaws that the author is blind to. The subagent receives only a brief scope summary (see

{{PLANNING_CONTEXT}}

below) to verify the plan addresses the user's full intent, not the entire planning dialogue.

Fast-path for small plans: If the plan has 2 or fewer steps and covers a narrowly scoped change (e.g., a config change, a single-file refactoring, a straightforward addition), skip the subagent dispatch. Instead, perform a quick self-review checking for obvious gaps in acceptance criteria, missing verification items, and dependency issues. Present the plan to the user and ask if they want to start execution. For plans with 3 or more steps, or any plan that touches architecture, multiple modules, or cross-cutting concerns, always dispatch the subagent — no exceptions.

Dispatching the review subagent: Use Claude Code's Agent tool to dispatch the plan review subagent. Reference

references/plan-review-subagent.md

for the exact prompt template. Substitute placeholders before dispatching:

```
{{PLAN_PATH}}
```
— absolute path to the plan file or milestone folder.
```
{{PROJECT_ROOT}}
```
— absolute path to the project root.
```
{{PLANNING_CONTEXT}}
```
— compose a brief summary (5-10 sentences) of: what the user originally asked for, key constraints and decisions from the clarification rounds, agreed scope boundaries, and any explicit exclusions ("we agreed not to handle X"). This gives the subagent enough context to verify the plan addresses the user's full intent, not just what the Goal header captured.

The subagent prompt in

references/plan-review-subagent.md

contains the full review methodology covering completeness, dependencies, sizing, criteria quality, phase quality, prose compliance, architecture, and risk.

After the subagent returns:

If the review finds no issues: Inform the user the plan passed adversarial review and ask if they want to start execution.
If the review finds issues: Present all findings to the user with the subagent's full report. The user decides whether changes are needed or the plan is acceptable as-is.
- If the user wants changes: make the requested modifications to the plan, then offer to re-run the adversarial review on the updated plan. The user may accept another review round or decline and proceed to execution. Repeat this review-modify cycle until the user is satisfied.
- If the user says the plan is fine: proceed to ask if they want to start execution.

Do not skip the plan review (except via the fast-path above). Do not auto-resolve findings without user input. The plan review is a hard gate — the plan is not considered complete until it has passed this step.

After approval: Commit the plan file to git so it persists across sessions and supports checkmark-based progress tracking.

将计划写入磁盘后，派遣subagent对整个计划做对抗性评审。subagent从磁盘读取全新的计划内容，不受规划上下文的锚定影响，作为批判性的第二视角，唯一目标是在执行开始前发现计划缺陷。

为什么用subagent：编写计划的Agent会被自己的推理锚定，没有完整规划对话历史的全新subagent会像执行者一样读取计划，更容易发现作者忽略的歧义、缺口和逻辑缺陷。仅向subagent提供简短的范围摘要（见下文

{{PLANNING_CONTEXT}}

）来验证计划是否覆盖用户的全部意图，不需要提供完整的规划对话。

小计划快速通道：如果计划只有2步及以内，且覆盖范围很窄（例如配置变更、单文件重构、简单新增功能），可以跳过派遣subagent，改为快速自审，检查验收标准是否有明显缺口、验证项是否遗漏、依赖是否有问题。将计划呈现给用户，询问是否开始执行。如果计划包含3步及以上，或是涉及架构、多个模块、跨域关注点的计划，必须派遣subagent，无例外。

派遣评审subagent：使用Claude Code的Agent工具派遣计划评审subagent，精确的提示词模板见

references/plan-review-subagent.md

，派遣前替换占位符：

```
{{PLAN_PATH}}
```
—— 计划文件或里程碑文件夹的绝对路径
```
{{PROJECT_ROOT}}
```
—— 项目根目录的绝对路径
```
{{PLANNING_CONTEXT}}
```
—— 编写5-10句话的简短摘要，包含：用户的原始需求、澄清阶段的关键约束和决策、约定的范围边界、所有明确排除的内容（例如「我们约定不处理X场景」）。这些信息足以让subagent验证计划是否覆盖用户全部意图，而不只是目标头部记录的内容

references/plan-review-subagent.md

中的subagent提示词包含完整的评审方法，覆盖完整性、依赖、步骤大小、标准质量、阶段质量、文字规范、架构、风险等维度。

subagent返回后：

如果评审未发现问题：告知用户计划已通过对抗性评审，询问是否开始执行
如果评审发现问题：将所有发现和subagent的完整报告呈现给用户，由用户决定是否需要修改，或是计划可以接受
- 如果用户要求修改：按要求调整计划，然后提议对更新后的计划重新运行对抗性评审，用户可以选择接受新一轮评审，或是跳过评审直接执行。重复评审-修改循环直到用户满意
- 如果用户认为计划没问题：直接询问是否开始执行

不要跳过计划评审（上述快速通道场景除外），不要在没有用户输入的情况下自动解决评审发现的问题。计划评审是硬关口——未通过该步骤的计划不视为完成。

审批通过后：将计划文件提交到git，确保跨会话持久化，支持打勾的进度跟踪方式。

Output Formats

输出格式

See Step 3 (Assess Complexity) for which format to choose based on step count.

根据步骤数选择对应格式的规则见第3步（评估复杂度）。

Single Document

单文档

Path:

docs/plans/YYYY-MM-DD-<topic>-plan.md

Example:

docs/plans/2026-03-15-user-auth-plan.md

路径：

docs/plans/YYYY-MM-DD-<topic>-plan.md

示例：

docs/plans/2026-03-15-user-auth-plan.md

Milestone Folder

里程碑文件夹

Path:

docs/plans/YYYY-MM-DD-<topic>/

Contents:

docs/plans/2026-03-15-user-auth/
  README.md
  01_data-layer.md
  02_api-endpoints.md
  03_frontend-integration.md

The

README.md

provides an ordered list of milestones with summaries, the confirmed tool chain, and any cross-cutting concerns that apply to all milestones.

路径：

docs/plans/YYYY-MM-DD-<topic>/

内容：

docs/plans/2026-03-15-user-auth/
  README.md
  01_data-layer.md
  02_api-endpoints.md
  03_frontend-integration.md

README.md

提供按顺序排列的里程碑列表及摘要、已确认的工具链、所有适用于全部里程碑的跨域关注点。

Handling Plan Execution

计划执行处理

When the user asks to execute, invoke

blueprint:execute

— it provides full subagent orchestration with batching, git handling, and progress tracking. If unavailable, work through steps one at a time completing all three phases before advancing. Mark completed steps with a checkmark in the plan heading and tick Phase 3 checkboxes for cross-session resumability. See

references/step-template.md

for what belongs in each phase of a plan step.

当用户要求执行时，调用

blueprint:execute

——它提供完整的subagent编排能力，包含批量处理、git处理和进度跟踪。如果该功能不可用，逐步骤执行，推进前完成全部三个阶段的工作。在计划标题中为已完成步骤打勾，勾选第三阶段的检查框，支持跨会话恢复执行。每个计划步骤的各阶段内容要求见

references/step-template.md

。

Handling Scope Changes

范围变更处理

If scope changes during execution invalidate more than half the remaining plan, recommend starting fresh rather than patching a plan built on outdated assumptions.
If new steps are needed during execution, propose them with the same 3-phase structure (build, adversarial review, verification) and insert them at the appropriate position in the plan.

如果执行过程中的范围变更导致超过一半的剩余计划失效，建议重新生成计划，而非在基于过时假设的计划上修补
如果执行过程中需要新增步骤，按照相同的三阶段结构（构建、对抗性评审、验证）提出，插入到计划的合适位置

Additional Resources

额外资源

Refer to the following reference files for detailed guidance:

references/step-template.md
— Full step template with phase-by-phase guidance and a complete example step. Use this as the structural reference for every step in every plan.
references/tool-discovery.md
— Per-language lookup tables for detecting project tooling across ecosystems. Use as a reference during codebase exploration in step 1.
references/plan-review-subagent.md
— Prompt template for the adversarial plan review subagent dispatched in step 5. Use this verbatim when dispatching the review subagent after plan generation.

参考以下文件获取详细指导：

references/step-template.md
—— 完整的步骤模板，包含分阶段指导和完整示例步骤，作为所有计划中所有步骤的结构参考
references/tool-discovery.md
—— 各生态下项目工具链检测的分语言查询表，在第1步代码库探索阶段作为参考
references/plan-review-subagent.md
—— 第5步派遣的对抗性计划评审subagent的提示词模板，生成计划后派遣评审subagent时直接使用