plan-checker

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Plan Checker Skill

Purpose

用途

Validate plans before execution using goal-backward analysis. Start from the stated goal, verify every requirement has a complete path through the plan to completion. Catch plan-level defects before they waste an entire execution cycle.

Key principle: Plan completeness does not equal goal achievement. A plan can have all tasks filled in, each well-specified, and still miss the goal. The checker works backward from the goal through every requirement to verify complete coverage -- not just that each task looks reasonable in isolation.

采用目标逆向分析，在执行前对计划进行验证。从既定目标出发，验证每一项需求都能通过计划中的路径完整落地。在计划层面的缺陷浪费整个执行周期前将其发现。

核心原则：计划完整并不等同于目标达成。一个计划可能填满了所有任务，每个任务都描述清晰，但仍然无法实现目标。本校验工具从目标出发，逆向遍历每一项需求以验证完整覆盖度——而非仅检查单个任务本身是否合理。

Operator Context

操作者场景

This skill operates as a gate between planning and execution. It validates plan quality across 10 dimensions, produces structured findings, and issues a PASS/BLOCK verdict. If issues are found, a bounded revision loop allows up to 3 iterations before proceeding with documented risks.

本Skill作为规划与执行之间的闸门，从10个维度验证计划质量，生成结构化检查结果，并给出PASS/BLOCK判定。若发现问题，将启动最多3次迭代的有限修订循环，之后可带着已记录的风险继续推进。

Hardcoded Behaviors (Always Apply)

硬编码行为（始终生效）

CLAUDE.md Compliance: Read and follow repository CLAUDE.md before validation. Repository rules inform dimension 9 (CLAUDE.md compliance).
Goal-Backward Analysis: Always start from the stated goal and trace backward through the plan. Never validate tasks in isolation -- a task is only valid if it contributes to a path from goal to completion.
Structured Findings Format: Every issue uses the standard format (plan, dimension, severity, description, fix_hint). Unstructured feedback is not actionable and gets lost.
Bounded Revision Loop: Maximum 3 revision iterations. After 3, remaining issues are documented as known risks. This prevents infinite planning loops -- the cost of one more revision iteration is never zero, and at some point execution with known risks beats continued planning.
Codebase Verification for Dependencies: Dimension 3 (dependency correctness) and dimension 9 (CLAUDE.md compliance) require reading actual files. Do not validate file paths or import references from memory -- verify against the codebase.
BLOCK on Any Blocker: A single blocker-severity finding means BLOCK verdict. Blockers are non-negotiable because they predict execution failure, not just suboptimal execution.

CLAUDE.md合规性：在验证前读取并遵循仓库的CLAUDE.md。仓库规则将作为第9维度（CLAUDE.md合规性）的校验依据。
目标逆向分析：始终从既定目标出发，逆向遍历计划。绝不孤立验证任务——只有当任务能为目标到结果的路径做贡献时，才视为有效。
结构化检查结果格式：所有问题均采用标准格式呈现（计划、维度、严重程度、描述、修复提示）。非结构化反馈不具备可执行性，容易被忽略。
有限修订循环：最多允许3次修订迭代。3次后，剩余问题将被记录为已知风险。这是为了避免无限规划循环——每一次额外的修订迭代都有成本，在某些情况下，带着已知风险执行比持续规划更有价值。
依赖项的代码库验证：第3维度（依赖项正确性）和第9维度（CLAUDE.md合规性）需要读取实际文件。请勿仅凭记忆验证文件路径或导入引用——必须以代码库为依据进行验证。
发现阻塞项即判定BLOCK：只要存在一个阻塞级别的问题，就会给出BLOCK判定。阻塞项是不可协商的，因为它们预示着执行必然失败，而非仅仅是执行效果不佳。

Default Behaviors (ON unless disabled)

默认行为（默认开启，可关闭）

Communication Style: Report findings factually with severity and fix hints. No self-congratulation. Show evidence (file paths, missing requirements) rather than assertions.
Full Dimension Scan: Run all 10 dimensions on every check. Skipping dimensions creates false confidence -- a plan that passes 7 of 10 dimensions is not "mostly good," it has 3 unchecked risk areas.
Severity-Ordered Output: Report blockers before warnings. The reader needs to know immediately whether execution is blocked.
Fix Hints Required: Every finding must include a fix_hint. A finding without a fix is a complaint, not actionable feedback.

沟通风格：基于事实报告检查结果，包含严重程度和修复提示。不进行自我夸耀，展示证据（文件路径、缺失的需求）而非主观断言。
全维度扫描：每次检查都会运行全部10个维度。跳过任何维度都会带来虚假的安全感——一个通过10个维度中7个的计划并非「大体良好」，而是存在3个未检查的风险点。
按严重程度排序输出：先报告阻塞项，再报告警告项。读者需要立即知晓执行是否会被阻塞。
必须提供修复提示：每个检查结果都必须包含修复提示。没有修复建议的问题只是抱怨，而非可执行的反馈。

Optional Behaviors (OFF unless enabled)

可选行为（默认关闭，可开启）

Auto-revise mode: Automatically revise the plan to fix findings instead of just reporting them (OFF by default -- human review of revisions is safer)
Cross-plan validation: When multiple plans exist for the same feature, validate data contracts between them (OFF by default -- enable for multi-plan features)

自动修订模式：自动修订计划以修复问题，而非仅报告问题（默认关闭——人工审核修订内容更安全）
跨计划验证：当同一功能存在多个计划时，验证它们之间的数据契约（默认关闭——针对多计划功能启用）

What This Skill CAN Do

本Skill可完成的工作

Validate plans against 10 verification dimensions
Verify file paths and imports against the actual codebase
Check CLAUDE.md compliance for the target repository
Produce structured findings with severity and fix hints
Issue PASS/BLOCK verdicts
Run bounded revision loops (max 3 iterations)
Validate plans from any source (feature-plan, workflow-orchestrator, manual)

从10个验证维度对计划进行校验
对照实际代码库验证文件路径和导入项
检查目标仓库的CLAUDE.md合规性
生成带有严重程度和修复提示的结构化检查结果
给出PASS/BLOCK判定
运行有限修订循环（最多3次迭代）
验证来自任意来源的计划（feature-plan、workflow-orchestrator、手动编写）

What This Skill CANNOT Do

本Skill无法完成的工作

Create plans (use feature-plan or workflow-orchestrator)
Execute plans (use feature-implement)
Manage plan lifecycle (use plan-manager)
Fix plans automatically without user review (unless auto-revise is enabled)
Validate plans without a stated goal (goal-backward analysis requires a goal)

创建计划（请使用feature-plan或workflow-orchestrator）
执行计划（请使用feature-implement）
管理计划生命周期（请使用plan-manager）
无需用户审核自动修复计划（除非开启自动修订模式）
验证无既定目标的计划（目标逆向分析必须以目标为基础）

Instructions

操作步骤

Phase 1: LOAD

阶段1：加载

Load the plan and its context. The checker needs three things: the plan itself, the goal it serves, and the repository rules it must comply with.

Step 1: Identify the plan

Accept the plan from one of these sources (in priority order):

Explicit path: User provides a file path to the plan
Feature state: Check
```
.feature/state/plan/
```
for the active feature plan
Active plans: Check
```
plan/active/
```
for workflow-orchestrator plans
Inline plan: User pastes plan content directly

If no plan is found:

BLOCK: No plan found. Provide a plan file path, or run /feature-plan or
workflow-orchestrator to create one first.

Step 2: Extract the goal

The goal is the anchor for goal-backward analysis. Find it in:

The plan's own
```
## Goal
```
or
```
## Success Criteria
```
section
The parent design document (for feature plans:
```
.feature/state/design/
```
)
The user's original request (for workflow-orchestrator plans)

If no goal is found:

BLOCK: No stated goal found in plan or design document. Goal-backward
analysis requires a goal. Add a ## Goal section to the plan.

Step 3: Load repository context

Read the target repository's CLAUDE.md (if it exists) for dimension 9 validation:

bash

find . -maxdepth 2 -name "CLAUDE.md" -type f 2>/dev/null | head -5

Read any found CLAUDE.md files to extract rules the plan must comply with.

Step 4: Extract requirements

From the goal and design document, extract a numbered list of requirements. Each requirement becomes a row in the coverage matrix. If the plan includes success criteria, those count as requirements too.

GATE: Plan loaded. Goal identified. Requirements extracted. Proceed to CHECK.

加载计划及其上下文。校验工具需要三个要素：计划本身、计划要达成的目标、计划必须遵守的仓库规则。

步骤1：识别计划

从以下来源获取计划（按优先级排序）：

明确路径：用户提供计划的文件路径
功能状态：检查
```
.feature/state/plan/
```
目录下的当前功能计划
活跃计划：检查
```
plan/active/
```
目录下的workflow-orchestrator计划
内联计划：用户直接粘贴计划内容

若未找到计划：

BLOCK: 未找到计划。请提供计划文件路径，或先运行/feature-plan或workflow-orchestrator创建计划。

步骤2：提取目标

目标是目标逆向分析的锚点。从以下位置查找目标：

计划自身的
```
## Goal
```
或
```
## Success Criteria
```
章节
父级设计文档（针对功能计划：
```
.feature/state/design/
```
）
用户的原始请求（针对workflow-orchestrator计划）

若未找到目标：

BLOCK: 未在计划或设计文档中找到既定目标。目标逆向分析必须以目标为基础，请在计划中添加## Goal章节。

步骤3：加载仓库上下文

读取目标仓库的CLAUDE.md（若存在），用于第9维度的验证：

bash

find . -maxdepth 2 -name "CLAUDE.md" -type f 2>/dev/null | head -5

读取找到的所有CLAUDE.md文件，提取计划必须遵守的规则。

步骤4：提取需求

从目标和设计文档中提取编号的需求列表。每个需求将成为覆盖矩阵中的一行。若计划包含成功标准，这些标准也视为需求。

闸门：计划已加载，目标已识别，需求已提取。进入校验阶段。

Phase 2: CHECK

阶段2：校验

Run goal-backward analysis across all 10 verification dimensions. For each dimension, produce structured findings or mark as PASS.

对所有10个验证维度执行目标逆向分析。针对每个维度，生成结构化检查结果或标记为PASS。

Dimension 1: Requirement Coverage

维度1：需求覆盖

Severity: Blocker Check: Every extracted requirement appears in at least one task.

Trace backward from each requirement:

Which task(s) address this requirement?
Is the coverage complete (full path to implementation) or partial?

Produce a coverage matrix:

undefined

严重程度：阻塞项 校验内容：每一项提取的需求都至少对应一个任务。

从每个需求逆向追踪：

哪些任务覆盖了该需求？
覆盖是完整的（有完整的实现路径）还是部分的？

生成覆盖矩阵：

undefined

Requirements Coverage Matrix

需求覆盖矩阵

#	Requirement	Covered By	Status
R1	[requirement]	T1, T3	COVERED
R2	[requirement]	T2	COVERED
R3	[requirement]	--	UNCOVERED


Any UNCOVERED requirement is a blocker finding.

#	需求	覆盖任务	状态
R1	[需求内容]	T1, T3	已覆盖
R2	[需求内容]	T2	已覆盖
R3	[需求内容]	--	未覆盖


任何未覆盖的需求都将被判定为阻塞项。

Dimension 2: Task Completeness

维度2：任务完整性

Severity: Warning Check: Each task has concrete actions, not vague descriptions.

Scan every task for vague verbs that signal incomplete thinking:

Vague (reject)	Concrete (accept)
"implement feature"	"add handler to router with X signature"
"ensure error handling"	"wrap fetchUser in try/catch, return 404 for NotFound"
"handle edge cases"	"add nil-check for user.Profile before accessing Avatar"
"improve performance"	"add index on orders.user_id, batch N+1 into JOIN"
"align the API"	"add created_at field to response struct"
"clean up"	"extract validation into validateInput() function"

A task that uses vague verbs without specifying the concrete action is a warning finding.

严重程度：警告项 校验内容：每个任务都有具体的操作，而非模糊的描述。

扫描所有任务，查找表示思考不完整的模糊动词：

模糊表述（拒绝）	具体表述（接受）
"implement feature"	"为路由添加带有X签名的处理器"
"ensure error handling"	"将fetchUser包裹在try/catch中，对NotFound返回404"
"handle edge cases"	"在访问Avatar前为user.Profile添加空值检查"
"improve performance"	"为orders.user_id添加索引，将N+1查询批量转换为JOIN查询"
"align the API"	"为响应结构体添加created_at字段"
"clean up"	"将验证逻辑提取到validateInput()函数中"

若任务使用模糊动词且未指定具体操作，将被判定为警告项。

Dimension 3: Dependency Correctness

维度3：依赖项正确性

Severity: Blocker Check: Tasks reference the right files and imports, verified against the actual codebase.

For each task that references files:

bash

undefined

严重程度：阻塞项 校验内容：任务引用的文件和导入项正确，需对照实际代码库验证。

针对每个引用文件的任务：

bash

undefined

Verify each referenced file exists

验证每个引用的文件是否存在

ls -la /path/to/referenced/file


For each task that references imports or packages:
- Verify the package/module exists in the codebase or dependency manifest
- Check that the import path is correct

A task referencing a nonexistent file or wrong import path is a blocker finding.

ls -la /path/to/referenced/file


针对每个引用导入项或包的任务：
- 验证包/模块是否存在于代码库或依赖清单中
- 检查导入路径是否正确

若任务引用不存在的文件或错误的导入路径，将被判定为阻塞项。

Dimension 4: Key Links Planned

维度4：关键关联已规划

Severity: Blocker Check: Cross-component wiring is explicitly tasked.

For any plan that adds new components, verify that the wiring between components is an explicit task. Common wiring that gets forgotten:

New Component	Required Wiring
New endpoint	Route registration
New handler	Router/mux hookup
New config option	Config loading code
New database table	Migration + ORM registration
New service	Dependency injection / initialization
New hook	Hook registration in settings
New agent	INDEX.json entry
New skill	INDEX.json entry, routing table

If the plan adds a component but has no task for its wiring, that is a blocker finding. WHY: Unwired components are the most common post-execution discovery -- the feature "works" in the new file but is never reachable because nobody registered the route or loaded the config.

严重程度：阻塞项 校验内容：跨组件的连接逻辑已被明确列为任务。

对于任何添加新组件的计划，验证组件之间的连接逻辑是否被明确列为任务。容易被遗漏的常见连接逻辑：

新组件	必需的连接逻辑
新端点	路由注册
新处理器	与Router/mux的关联
新配置项	配置加载代码
新数据库表	迁移 + ORM注册
新服务	依赖注入 / 初始化
新钩子	在设置中注册钩子
新Agent	INDEX.json条目
新Skill	INDEX.json条目、路由表

若计划添加了组件但未包含连接逻辑的任务，将被判定为阻塞项。原因：未连接的组件是执行后最常发现的问题——新文件中的功能「正常工作」，但由于没人注册路由或加载配置，导致永远无法被访问。

Dimension 5: Scope Sanity

维度5：范围合理性

Severity: Warning at 4 tasks, Blocker at 5+ Check: Plan has right-sized scope for a single execution context.

Count the tasks in the plan:

Task Count	Verdict	Rationale
1-3	Good	Right-sized for focused execution
4	Warning	Approaching limit; review if any tasks can merge
5+	Blocker	Split required -- too many tasks for reliable single-context execution. WHY: context windows are finite, and each task adds execution state. Past 5 tasks, the executor loses track of earlier context, makes inconsistent decisions, or runs out of room for error recovery.

For blocker: suggest how to split (by wave, by component, by dependency boundary).

严重程度：4个任务时为警告项，5个及以上任务时为阻塞项 校验内容：计划的范围大小适合单次执行上下文。

统计计划中的任务数量：

任务数量	判定	理由
1-3	良好	范围大小适合聚焦执行
4	警告	接近上限；评审是否可以合并部分任务
5+	阻塞	需要拆分——任务过多，无法在单次上下文内可靠执行。原因：上下文窗口是有限的，每个任务都会增加执行状态。超过5个任务后，执行者会忘记之前的上下文，做出不一致的决策，或没有足够的空间进行错误恢复。

若判定为阻塞项：建议拆分方式（按阶段、按组件、按依赖边界）。

Dimension 6: Verification Derivation

维度6：验证逻辑明确

Severity: Warning Check: How to verify the plan's goal is achieved must be explicit.

Look for a

## Verification

## Success Criteria

section. Check that it specifies:

Concrete commands to run (not just "run tests")
Expected outcomes (not just "tests pass")
Observable behaviors (not implementation tasks)

Insufficient	Sufficient
"run tests"	"run `go test ./pkg/...` and verify TestNewHandler passes"
"check it works"	"curl localhost:8080/api/reset returns 200 with token field"
"verify deployment"	"kubectl get pods -n staging shows 3/3 Running within 60s"

A plan with no verification section or only vague verification is a warning finding.

严重程度：警告项 校验内容：必须明确说明如何验证计划目标是否达成。

查找计划中的

## Verification

或

## Success Criteria

章节。检查是否明确了：

具体要运行的命令（而非仅「运行测试」）
预期结果（而非仅「测试通过」）
可观察的行为（而非实现任务）

不充分的描述	充分的描述
"run tests"	"运行 `go test ./pkg/...` 并验证TestNewHandler通过"
"check it works"	"curl localhost:8080/api/reset返回200状态码且包含token字段"
"verify deployment"	"kubectl get pods -n staging显示60秒内3/3个Pod处于Running状态"

若计划没有验证章节，或只有模糊的验证描述，将被判定为警告项。

Dimension 7: Context Compliance

维度7：上下文合规性

Severity: Blocker Check: Plan respects decisions from prior phases.

If the plan is part of a feature lifecycle (design -> plan -> implement):

Read the design document decisions
Verify the plan doesn't contradict them
Check that architectural choices from design are reflected in task details

If the plan is standalone (workflow-orchestrator):

Check that the plan aligns with the user's stated requirements
Verify no scope creep beyond what was requested

A plan that contradicts prior-phase decisions is a blocker finding.

严重程度：阻塞项 校验内容：计划尊重前期阶段的决策。

若计划属于功能生命周期（设计 -> 规划 -> 实现）的一部分：

读取设计文档中的决策
验证计划与这些决策不冲突
检查设计阶段的架构选择是否在任务细节中有所体现

若计划是独立的（workflow-orchestrator）：

检查计划是否符合用户的既定需求
验证是否存在超出请求范围的内容

若计划与前期阶段的决策冲突，将被判定为阻塞项。

Dimension 8: Cross-Plan Data Contracts

维度8：跨计划数据契约

Severity: Blocker Check: One plan's transformations don't conflict with another's.

This dimension only applies when multiple plans exist for the same feature. Check:

Do two plans modify the same files? If so, are the modifications compatible?
Do two plans expect different shapes for shared data structures?
Does Plan B depend on output from Plan A that Plan A doesn't actually produce?

If not applicable (single plan), mark as PASS with note "single plan -- no cross-plan conflicts possible."

严重程度：阻塞项 校验内容：多个计划的修改不会产生冲突。

仅当同一功能存在多个计划时，此维度才适用。检查：

两个计划是否修改了相同的文件？如果是，修改是否兼容？
两个计划是否对共享数据结构有不同的格式要求？
计划B是否依赖计划A的输出，但计划A实际上并不会生成该输出？

若不适用（仅单个计划），标记为PASS并备注「单个计划——不存在跨计划冲突的可能」。

Dimension 9: CLAUDE.md Compliance

维度9：CLAUDE.md合规性

Severity: Blocker Check: Plan doesn't violate repository rules.

Cross-reference the plan against CLAUDE.md rules loaded in Phase 1. Common violations:

Rule Category	What to Check
Branch policy	Plan doesn't commit directly to main/master
Test requirements	Plan includes test tasks if CLAUDE.md requires them
Code style	Plan references correct formatters/linters
Forbidden patterns	Plan doesn't use patterns CLAUDE.md prohibits
Required tools	Plan uses repo-mandated tools (e.g., specific test runners)

A plan that violates a CLAUDE.md rule is a blocker finding.

If no CLAUDE.md was found in Phase 1, mark as PASS with note "no CLAUDE.md found."

严重程度：阻塞项 校验内容：计划不违反仓库规则。

将计划与阶段1中加载的CLAUDE.md规则进行交叉比对。常见违规情况：

规则类别	检查内容
分支策略	计划不会直接提交到main/master分支
测试要求	若CLAUDE.md要求，计划包含测试任务
代码风格	计划引用了正确的格式化工具/代码检查工具
禁止模式	计划未使用CLAUDE.md禁止的模式
必需工具	计划使用了仓库规定的工具（例如特定的测试运行器）

若计划违反CLAUDE.md规则，将被判定为阻塞项。

若阶段1未找到CLAUDE.md，标记为PASS并备注「未找到CLAUDE.md」。

Dimension 10: Achievability

维度10：可实现性

Severity: Warning Check: Plan is completable within approximately 50% of a fresh context window.

Estimate the execution cost:

Number of tasks x average task complexity
Number of files to read for context
Number of verification commands to run
Room needed for error recovery and iteration

If the plan looks like it would consume more than 50% of a context window:

Warning finding with suggestion to split or simplify
WHY 50%: execution always takes more than planned. Errors happen, context is needed for debugging, and verification adds overhead. A plan that fits in 50% leaves room for reality.

GATE: All 10 dimensions checked. Findings collected. Proceed to VERDICT.

严重程度：警告项 校验内容：计划可在全新上下文窗口的约50%范围内完成。

估算执行成本：

任务数量 × 平均任务复杂度
需要读取的上下文文件数量
需要运行的验证命令数量
错误恢复和迭代所需的空间

若计划看起来会消耗超过50%的上下文窗口：

给出警告项，并建议拆分或简化计划
为什么是50%：实际执行时间总是比计划的长。会出现错误，需要上下文进行调试，验证也会增加开销。计划控制在50%以内可以为实际情况留出空间。

闸门：所有10个维度已校验完成，检查结果已收集。进入判定阶段。

Phase 3: VERDICT

阶段3：判定

Compile findings and issue verdict.

Step 1: Compile findings

Collect all findings from Phase 2 into a structured report. Order by severity (blockers first), then by dimension number.

Each finding uses this format:

Plan: [plan identifier or filename]
Dimension: [N] [dimension name]
Severity: Blocker | Warning
Description: [what is wrong]
Fix hint: [specific suggestion for how to fix it]

Step 2: Issue verdict

Condition	Verdict	Action
Zero findings	PASS	Proceed to execution
Warnings only, no blockers	PASS with warnings	Proceed, but address warnings if time allows
Any blocker findings	BLOCK	Plan must be revised before execution

Step 3: Format output

================================================================
 PLAN CHECK: [plan identifier]
================================================================

 Verdict: PASS | PASS (with warnings) | BLOCK
 Blockers: [count]
 Warnings: [count]

 Requirements Coverage: [N/M] covered

================================================================
 FINDINGS
================================================================

 [structured findings, blockers first]

================================================================
 REQUIREMENTS COVERAGE MATRIX
================================================================

 [coverage matrix from dimension 1]

================================================================

If verdict is PASS or PASS with warnings, suggest:

Plan validated. Proceed to execution with /feature-implement or
continue with workflow-orchestrator EXECUTE phase.

If verdict is BLOCK, proceed to Phase 4 (Revision Loop).

GATE: Verdict issued. If PASS, done. If BLOCK, proceed to revision loop.

整理检查结果并给出判定。

步骤1：整理检查结果

将阶段2的所有检查结果整理成结构化报告。按严重程度排序（先阻塞项，后警告项），再按维度编号排序。

每个检查结果采用以下格式：

计划：[计划标识或文件名]
维度：[N] [维度名称]
严重程度：阻塞项 | 警告项
描述：[问题内容]
修复提示：[具体修复建议]

步骤2：给出判定

条件	判定	操作
无任何问题	PASS	进入执行阶段
仅存在警告项，无阻塞项	PASS（带警告）	继续执行，若时间允许请处理警告项
存在任何阻塞项	BLOCK	计划必须先修订才能执行

步骤3：格式化输出

================================================================
 计划检查：[计划标识]
================================================================

 判定：PASS | PASS（带警告） | BLOCK
 阻塞项数量：[数量]
 警告项数量：[数量]

 需求覆盖情况：[已覆盖数量/总数量]

================================================================
 检查结果
================================================================

 [结构化检查结果，先阻塞项]

================================================================
 需求覆盖矩阵
================================================================

 [来自维度1的覆盖矩阵]

================================================================

若判定为PASS或PASS（带警告），建议：

计划已验证通过。可执行/feature-implement进入执行阶段，或继续workflow-orchestrator的EXECUTE阶段。

若判定为BLOCK，进入阶段4（修订循环）。

闸门：已给出判定。若为PASS，流程结束。若为BLOCK，进入修订循环。

Phase 4: REVISION LOOP (only if BLOCK)

阶段4：修订循环（仅当判定为BLOCK时）

Bounded revision loop: fix blocker findings, re-check, max 3 iterations. This loop exists because most blocker findings are fixable in minutes -- a missing task, a wrong file path, an uncovered requirement. But it's bounded because infinite revision is worse than executing with known risks.

Iteration tracking:

Revision iteration: [N] of 3
Remaining blockers: [count]

Step 1: Revise plan

For each blocker finding:

Apply the fix_hint
If auto-revise is OFF (default): present the suggested revision to the user for approval
If auto-revise is ON: apply the revision directly

Step 2: Re-check

Run Phase 2 again on the revised plan. Only re-check dimensions that had findings (optimization -- dimensions that passed don't regress from plan edits).

Step 3: Evaluate

Condition	Action
All blockers resolved	Issue PASS verdict, done
Blockers remain, iterations < 3	Next iteration
Blockers remain, iterations = 3	Document remaining issues as known risks, issue PASS (with known risks)

On max iterations reached:

================================================================
 PLAN CHECK: [plan identifier]
================================================================

 Verdict: PASS (with known risks)
 Revision iterations: 3 of 3 (limit reached)

 Known Risks (unresolved after 3 iterations):
   - [finding 1]
   - [finding 2]

 Proceeding to execution. These risks should be monitored during
 implementation. If any risk materializes, pause execution and
 revise the plan.
================================================================

WHY proceed after 3 iterations: The cost of continued planning is not zero -- it consumes context, delays execution, and each revision may introduce new issues. After 3 good-faith attempts, the remaining issues are either genuinely hard (and better discovered during execution with real code) or low-probability (and not worth further planning time).

有限修订循环：修复阻塞项问题，重新校验，最多3次迭代。存在此循环的原因是，大多数阻塞项问题可在数分钟内修复——例如缺失的任务、错误的文件路径、未覆盖的需求。但循环是有限的，因为无限规划比带着已知风险执行更糟糕。

迭代追踪：

修订迭代：[当前次数] / 3
剩余阻塞项数量：[数量]

步骤1：修订计划

针对每个阻塞项：

应用修复提示中的建议
若自动修订模式为关闭（默认）：将建议的修订内容呈现给用户以获取批准
若自动修订模式为开启：直接应用修订内容

步骤2：重新校验

对修订后的计划再次运行阶段2的校验。仅重新检查有问题的维度（优化——已通过的维度不会因计划编辑而出现问题）。

步骤3：评估

条件	操作
所有阻塞项已解决	给出PASS判定，流程结束
仍有阻塞项，迭代次数<3	进入下一次迭代
仍有阻塞项，迭代次数=3	将剩余问题记录为已知风险，给出PASS（带已知风险）判定

当达到最大迭代次数时：

================================================================
 计划检查：[计划标识]
================================================================

 判定：PASS（带已知风险）
 修订迭代次数：3 / 3（已达上限）

 已知风险（3次迭代后仍未解决）：
   - [问题1]
   - [问题2]

 继续执行。在实现过程中需监控这些风险。若任何风险实际发生，请暂停执行并修订计划。
================================================================

原因：持续规划的成本并非为零——它会消耗上下文，延迟执行，且每次修订可能引入新问题。经过3次真诚的尝试后，剩余问题要么确实难以解决（在执行过程中结合真实代码更容易发现），要么发生概率较低（不值得花费更多时间规划）。

Error Handling

错误处理

Error	Cause	Solution
No plan found	No plan file at expected locations	Provide explicit path, or run /feature-plan first
No goal found	Plan lacks ## Goal or ## Success Criteria	Add a goal section to the plan before checking
File verification fails	Referenced file doesn't exist in codebase	Fix the file path in the plan, or create the file first
CLAUDE.md not found	No CLAUDE.md in target repo	Dimension 9 passes automatically; note in findings
Revision loop exhausted	3 iterations couldn't resolve all blockers	Proceed with known risks documented
Plan is inline text	User pasted plan instead of file path	Parse inline text; warn that revisions won't persist to file

错误	原因	解决方案
未找到计划	预期位置无计划文件	提供明确的文件路径，或先运行/feature-plan创建计划
未找到目标	计划缺少## Goal或## Success Criteria章节	在检查前为计划添加Goal章节
文件验证失败	引用的文件在代码库中不存在	修复计划中的文件路径，或先创建该文件
未找到CLAUDE.md	目标仓库中无CLAUDE.md	第9维度自动通过；在检查结果中备注
修订循环已耗尽	3次迭代仍未解决所有阻塞项	带着已记录的已知风险继续执行
计划为内联文本	用户粘贴了计划内容而非文件路径	解析内联文本；警告用户修订内容不会保存到文件

Anti-Patterns

反模式

Anti-Pattern	Why Wrong	Do Instead
Validate tasks in isolation	A task can look perfect in isolation while missing the goal entirely. Goal-backward analysis catches what task-forward review misses.	Always trace from goal backward through requirements to tasks
Skip dimension because "it looks fine"	"Looks fine" is not validation. Every skipped dimension is an unchecked risk area.	Run all 10 dimensions; mark explicit PASS for clean dimensions
Soft-pass on blockers	"It's probably fine" on a blocker means the executor hits the wall you saw coming. Blockers predict execution failure.	BLOCK on any blocker, no exceptions
Revise without re-checking	A revision that fixes one blocker can introduce another. Untested revisions give false confidence.	Always re-check after every revision
Unlimited revision iterations	Infinite planning is worse than executing with known risks. Each iteration has diminishing returns and non-zero cost.	Hard limit of 3 iterations, then proceed with documented risks
Validate without reading codebase	File paths and imports validated from memory are unreliable. The codebase is the source of truth, not the plan's claims.	Use Read/Grep/Glob to verify dimension 3 against actual files
Accept plan without goal	Goal-backward analysis requires a goal. Without one, you're checking form (do tasks look good?) not substance (do tasks achieve something?).	Require a stated goal before starting validation

反模式	错误原因	正确做法
孤立验证任务	单个任务本身看起来完美，但可能完全偏离目标。目标逆向分析能发现正向任务评审遗漏的问题。	始终从目标出发，逆向遍历需求到任务
因「看起来没问题」而跳过维度	「看起来没问题」不等于验证。每一个跳过的维度都是未检查的风险点。	运行全部10个维度；为无问题的维度明确标记PASS
对阻塞项网开一面	对阻塞项说「可能没问题」意味着执行者会遇到你早已预见的障碍。阻塞项预示着执行必然失败。	只要发现阻塞项就判定BLOCK，无一例外
修订后不重新校验	修复一个阻塞项的修订可能引入另一个阻塞项。未经测试的修订会带来虚假的安全感。	每次修订后都必须重新校验
无限次修订迭代	无限规划比带着已知风险执行更糟糕。每一次迭代的收益递减，且成本不为零。	硬限制为3次迭代，之后带着已记录的风险继续执行
未读取代码库就进行验证	仅凭记忆验证文件路径和导入项不可靠。代码库是唯一的事实来源，而非计划中的声明。	使用Read/Grep/Glob工具对照实际文件验证第3维度
无目标时进行验证	目标逆向分析必须以目标为基础。没有目标的话，你只是在检查形式（任务看起来是否良好？）而非实质（任务是否能达成目标？）。	开始验证前必须要求提供明确的目标

Anti-Rationalization

反合理化

Rationalization Attempt	Why It's Wrong	Required Action
"The plan is detailed enough, no need to check"	Detail is not correctness. A detailed plan with a wrong file path still fails at execution.	Run all 10 dimensions regardless of plan quality appearance
"Only 1 blocker, we can work around it"	Workarounds during execution consume more context than fixing the plan. A known blocker is cheaper to fix pre-execution.	BLOCK verdict, enter revision loop
"This dimension doesn't apply to this plan"	Mark it PASS with a note explaining why. Skipping silently creates an audit gap.	Explicitly mark non-applicable dimensions as PASS with rationale
"The user wants to move fast, skip validation"	Fast execution of a broken plan wastes the entire execution cycle. 2 minutes of validation saves 20 minutes of failed execution.	Run the full check. Speed comes from not re-executing, not from skipping validation
"3 iterations wasn't enough, let me try one more"	The bounded loop exists for a reason. Iteration 4 has even lower probability of success and higher context cost.	Document remaining risks, proceed. The bound is the bound.
"File probably exists, I don't need to check"	"Probably" is not verified. Dimension 3 requires codebase verification.	Read the filesystem. Verify.

合理化尝试	错误原因	必需操作
「计划足够详细，无需检查」	详细不等于正确。一个文件路径错误的详细计划在执行时仍然会失败。	无论计划看起来质量如何，都要运行全部10个维度
「只有1个阻塞项，我们可以在执行时解决」	执行时的临时解决方案比提前修复计划消耗更多的上下文。已知的阻塞项在执行前修复成本更低。	判定为BLOCK，进入修订循环
「这个维度不适用于本计划」	标记为PASS并备注原因。静默跳过会留下审计缺口。	明确将不适用的维度标记为PASS并说明理由
「用户想快速推进，跳过验证」	快速执行一个有问题的计划会浪费整个执行周期。2分钟的验证能节省20分钟的失败执行时间。	执行完整的检查。速度来自避免重复执行，而非跳过验证
「3次迭代不够，再试一次」	有限循环的存在是有原因的。第4次迭代的成功概率更低，且成本更高。	记录剩余风险，继续执行。限制是硬性的
「文件可能存在，无需检查」	「可能存在」不等于已验证。第3维度要求以代码库为依据。	读取文件系统，进行验证

References

参考资料

ADR-074: Plan Checker Pre-Execution Validation
Feature Plan Skill -- produces plans this skill validates
Feature Implement Skill -- executes plans after this skill validates
Workflow Orchestrator -- PLAN phase produces plans this skill can validate
Verification Before Completion -- post-execution counterpart (validates results, not plans)
Gate Enforcement

ADR-074: Plan Checker Pre-Execution Validation
Feature Plan Skill —— 生成本Skill可验证的计划
Feature Implement Skill —— 在本Skill验证后执行计划
Workflow Orchestrator —— 其PLAN阶段生成的计划可由本Skill验证
Verification Before Completion —— 执行后的对应Skill（验证结果而非计划）
Gate Enforcement