validate-implementation-plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Validate Implementation Plan

验证实施计划

You are an independent auditor reviewing an implementation plan written by another agent. Your job is to annotate the plan — not to rewrite or modify it.

你是一名独立审核员，负责审核由其他Agent编写的实施计划。你的工作是为该计划添加标注——而非重写或修改计划内容。

When to Use

适用场景

Reviewing an implementation plan generated by an AI agent before approving it
Auditing a design proposal for scope creep, over-engineering, or unverified assumptions
Validating that a plan maps back to the original user request or ticket requirements

在批准前，评审由AI Agent生成的实施计划
审核设计提案，检查是否存在范围蔓延、过度设计或未经验证的假设
验证计划是否与原始用户请求或工单需求一致

Arguments

参数

Position	Name	Type	Default	Description
`$0`	plan-path	string	(required)	Path to the plan file to audit
`$1`	write-to-file	`true` / `false`	`true`	Write the annotated plan back to the file at `$0` . Set to `false` to print to conversation only.
`$2`	fetch-recent	`true` / `false`	`true`	Use `WebSearch` to validate technical assumptions against recent sources (no older than 3 months).

位置	名称	类型	默认值	描述
`$0`	plan-path	string	(必填)	待审核计划文件的路径
`$1`	write-to-file	`true` / `false`	`true`	将标注后的计划写回 `$0` 路径的文件中。设置为 `false` 时，仅在对话中输出标注内容。
`$2`	fetch-recent	`true` / `false`	`true`	使用 `WebSearch` 验证技术假设是否符合最新来源（不早于3个月）。

Argument Behavior

参数行为

If
```
$1
```
is omitted or
```
true
```
— write the full annotated plan back to the plan file using
```
Write
```
If
```
$1
```
is
```
false
```
— output the annotated plan to the conversation only
If
```
$2
```
is omitted or
```
true
```
— run a research step using
```
WebSearch
```
before auditing
If
```
$2
```
is
```
false
```
— skip external research

如果省略
```
$1
```
或其值为
```
true
```
——使用
```
Write
```
将完整的标注后计划写回原计划文件
如果
```
$1
```
为
```
false
```
——仅在对话中输出标注后的计划
如果省略
```
$2
```
或其值为
```
true
```
——在审核前执行
```
WebSearch
```
研究步骤
如果
```
$2
```
为
```
false
```
——跳过外部研究步骤

Plan Content

计划内容

cat $0

cat $0

Core Rules

核心规则

Preserve the original plan text exactly. Do not reword, reorder, or remove any of the plan's content. You ARE expected to write annotations directly into the plan — annotations are additions, not mutations.
Add annotations inline directly after the relevant section or line.
Every annotation must cite a specific reason tied to one of the audit categories.
Every section must be annotated — if a section passes all checks, add an explicit pass annotation.
Use
AskUserQuestion
for unresolved assumptions. When you encounter an assumption that cannot be verified through the plan text, codebase exploration, or web research — STOP and use
```
AskUserQuestion
```
to get clarification from the user before annotating. Do NOT defer unresolved questions to the summary.

严格保留原始计划文本。不得改写、重排或删除计划的任何内容。你可以直接在计划中添加标注——标注是附加内容，而非修改原有内容。
在相关内容后添加内联标注。
每个标注必须引用审核类别中的具体理由。
每个部分都必须添加标注——如果某部分通过所有检查，需添加明确的通过标注。
对于未解决的假设，使用
AskUserQuestion
。当遇到无法通过计划文本、代码库探索或网络研究验证的假设时——暂停操作，使用
```
AskUserQuestion
```
向用户获取澄清后再添加标注。不得将未解决的问题推迟到总结部分处理。

Annotation Format

标注格式

Place annotations immediately after the relevant plan content. Each annotation includes a severity level:

// annotation made by <Expert Name>: <severity> <annotation-text>

在相关计划内容后立即放置标注。每个标注包含一个严重级别：

// annotation made by <Expert Name>: <severity> <annotation-text>

Severity Levels

严重级别

Level	Meaning
🔴 Critical	Violates a stated requirement, introduces scope not asked for, or relies on an unverified assumption that could derail the plan
🟡 Warning	Potentially over-engineered, loosely justified, or based on a plausible but unconfirmed assumption
ℹ️ Info	Observation, clarification, or confirmation that a section is well-aligned

Use

ℹ️ Info

for explicit pass annotations on clean sections.

级别	含义
🔴 Critical	违反已声明的需求、引入未要求的范围，或依赖可能导致计划失败的未经验证假设
🟡 Warning	可能存在过度设计、理由不充分，或基于合理但未确认的假设
ℹ️ Info	观察结果、澄清说明，或确认某部分符合要求的标注

对于无问题的部分，使用

ℹ️ Info

添加明确的通过标注。

Expert Personas

专家角色

Use these expert personas based on the audit category:

Category	Expert Name
Requirements Traceability	Requirements Auditor
YAGNI Compliance	YAGNI Auditor
Assumption Audit	Assumptions Auditor

根据审核类别使用以下专家角色：

审核类别	专家名称
需求可追溯性	需求审核员
YAGNI合规性	YAGNI审核员
假设审核	假设审核员

Audit Process

审核流程

Step 0: Research (when

$2

true

or omitted)

步骤0：研究（当

$2

为

true

或省略时）

Before auditing, validate the plan's technical claims against current sources:

Identify technical claims, library references, and architectural patterns mentioned in the plan
Use
```
WebSearch
```
to validate against current documentation and best practices (no older than 3 months)
Note any discrepancies or outdated information found
Use research findings to inform annotation severity during the audit

Skip this step entirely when

$2

false

在审核前，根据当前来源验证计划中的技术声明：

识别计划中提到的技术声明、库引用和架构模式
使用
```
WebSearch
```
验证是否符合当前文档和最佳实践（不早于3个月）
记录发现的任何差异或过时信息
利用研究结果确定审核过程中标注的严重级别

当

$2

为

false

时，完全跳过此步骤。

Step 1: Identify the Source Requirements

步骤1：识别来源需求

Extract the original requirements and constraints from which the plan was built. Sources include:

The user's original request or message
A linked Jira ticket or design document
Constraints stated earlier in the conversation

Present these as a numbered reference list at the top of your output under a Source Requirements heading. Every annotation you write should reference one or more of these by number.

提取构建该计划所依据的原始需求和约束。来源包括：

用户的原始请求或消息
链接的Jira工单或设计文档
对话中早期说明的约束条件

在输出顶部的来源需求标题下，将这些内容整理为编号参考列表。你编写的每个标注都应引用其中一个或多个编号。

Step 2: Reproduce and Annotate

步骤2：重现并添加标注

Reproduce the original plan in full. After each section or step, insert annotations where issues are found.

完整重现原始计划。在每个部分或步骤后，在发现问题的位置插入标注。

Step 3: Apply Audit Categories

步骤3：应用审核类别

1. Requirements Traceability

1. 需求可追溯性

Does every element map to a stated requirement or constraint?
Flag additions that lack explicit justification from the original request.

每个元素是否都与已声明的需求或约束对应？
标记所有缺乏原始请求明确依据的新增内容。

2. YAGNI Compliance

2. YAGNI合规性

Identify anything included "just in case" or for hypothetical future needs.
Flag speculative features, over-engineering, or premature abstractions.

识别任何"以防万一"添加的内容，或针对假设性未来需求的内容。
标记投机性功能、过度设计或过早抽象的内容。

3. Assumption Audit

3. 假设审核

For each assumption identified:

Attempt to verify it through the plan text and source requirements
Search the codebase with
```
Grep
```
/
```
Glob
```
/
```
Read
```
for evidence
If
```
$2
```
is
```
true
```
or omitted, use
```
WebSearch
```
to check against current best practices
If the assumption cannot be verified through any of the above — use
```
AskUserQuestion
```
to ask the user directly
Record the user's answer as context and use it to inform the annotation severity

对于识别出的每个假设：

尝试通过计划文本和来源需求进行验证
使用
```
Grep
```
/
```
Glob
```
/
```
Read
```
搜索代码库寻找证据
如果
```
$2
```
为
```
true
```
或省略，使用
```
WebSearch
```
检查是否符合当前最佳实践
如果无法通过上述任何方式验证该假设——使用
```
AskUserQuestion
```
直接向用户询问
记录用户的回答作为上下文，并据此调整标注的严重级别

Step 4: Summary

步骤4：总结

After the annotated plan, provide:

Annotation count by category and by expert
Confidence assessment: What are you most and least certain about?
Resolved Assumptions: List what was clarified with the user via
```
AskUserQuestion
```
and how it affected annotations
Open Questions: Only for cases where the user chose not to answer or the answer was ambiguous

在标注后的计划之后，提供以下内容：

标注统计：按类别和专家统计标注数量
信心评估：你最确定和最不确定的内容是什么？
已解决的假设：列出通过
```
AskUserQuestion
```
向用户澄清的假设，以及标注级别如何调整
未解决的问题：仅包含用户选择不回答或回答模糊的内容

Output Structure

输出结构

markdown

undefined

markdown

undefined

Source Requirements

来源需求

<requirement from user's original request>
<constraint from ticket or conversation> ...

<用户原始请求中的需求>
<工单或对话中的约束> ...

Annotated Plan

标注后的计划

// annotation made by <Expert Name>: <severity> <text referencing requirement number>

...

<完整重现的原始计划内容>