revise

§ 01 · purpose

Purpose

Lets a finished plan absorb new information without losing its shape. revise reads the existing plan, applies precisely the requested changes (add phase · adjust criteria · trim scope · split a phase), and leaves everything else identical. Use it instead of regenerating a plan from scratch when only part of it is wrong.

§ 02 · when to use

When to use it

• Code-review findings recommend specific plan adjustments.
• Implementation hit a blocker that requires a phasing change.
• Scope grew or shrank mid-flight.
• The change is to a plan only — for design changes, re-run design/blueprint to produce a fresh plan instead.

§ 03 · inputs

Inputs

plan path

A review-artifact path is rejected with a hint pointing back to the plan.

§ 04 · outputs

Outputs

§ 05 · key steps

Key steps

1. 01 Validate inputs — plan path vs. review path Why: Common mistake — passing a review artifact instead of the target plan. revise detects this and asks for the plan path explicitly so the wrong file is never edited.
2. 02 Read the existing plan completely Why: Surgical edits require full context of phases, ordering constraints, and success criteria. Reading without limit/offset prevents partial-view rewrites.
3. 03 Categorize the requested change Why: Each change category — add phase, adjust criteria, trim scope, split phase — maps to a different edit shape. Picking the category first prevents a one-line note from triggering a wholesale rewrite.
4. 04 Ground the change against the live codebase Why: Even surgical changes get re-checked against current code state — the codebase may have moved since the plan was written.
5. 05 Apply via Edit, keep untouched sections intact Why: In-place edits via Edit preserve byte-for-byte the rest of the file, so diffs are small and reviewable and the plan's identity stays stable.

§ 06 · related skills

Related skills