Problem
During /spec planning phase, the plan-verifier/plan-challenger (now consolidated into plan-reviewer on latest upstream) agents find issues and the spec-plan command instructs Claude to fix must_fix/should_fix findings before presenting the plan for user approval (Step 1.7 → Step 1.8).
In practice, Claude sometimes:
- Receives agent findings
- Does not fully incorporate them into the plan
- Presents the plan to the user for approval
- After user approves, rushes to incorporate the findings it should have already handled
This means the user approves a plan that doesn't reflect the agent's feedback, and then sees unexpected changes post-approval.
Current State (upstream/main, latest)
The instruction in Step 1.7 is:
"Fix findings: must_fix → should_fix immediately. Suggestions if reasonable. Proceed after all must_fix/should_fix resolved."
There is no explicit verification step to confirm findings were actually written into the plan file before proceeding to the approval gate (Step 1.8). This has been the case from v6.6.0 through the latest upstream/main.
Potential Improvement
Add an explicit checkpoint between Step 1.7 and Step 1.8:
- Re-read the plan file after fixing findings
- List each must_fix/should_fix finding and confirm it's addressed in the plan text
- Only then proceed to approval
Observed On
- Sonnet (primary model for spec workflows)
- Multiple sessions with >3 task plans
Problem
During
/specplanning phase, the plan-verifier/plan-challenger (now consolidated into plan-reviewer on latest upstream) agents find issues and the spec-plan command instructs Claude to fix must_fix/should_fix findings before presenting the plan for user approval (Step 1.7 → Step 1.8).In practice, Claude sometimes:
This means the user approves a plan that doesn't reflect the agent's feedback, and then sees unexpected changes post-approval.
Current State (upstream/main, latest)
The instruction in Step 1.7 is:
There is no explicit verification step to confirm findings were actually written into the plan file before proceeding to the approval gate (Step 1.8). This has been the case from v6.6.0 through the latest upstream/main.
Potential Improvement
Add an explicit checkpoint between Step 1.7 and Step 1.8:
Observed On