On this page
Plans and modules
Review the right amount of planning for a change and correct its scope before implementation.
Not every change needs the same amount of planning. A small local fix can stay focused, while a change that crosses files or introduces new states may benefit from a written plan and a clearer breakdown.
Check whether the plan fits the request
Compare its outcome, affected areas, important states, and edge cases with what you asked for.
Read each module as a review unit
Use the module goal and acceptance criteria to spot an omitted dependency or an unrelated task before implementation begins.
Correct the direction before continuing
Explain a scope correction, or start a more focused task when the goal has changed. Do not treat a plan as an implementation detail you must accept.
When a plan appears
RevampKey adapts planning to the request. A plan may appear when the approach, affected areas, or user-visible states need alignment before implementation. A short task may move directly toward review instead.
Use modules for larger changes
Modules divide broader work into understandable parts. Read each module for its goal, affected area, and relationship to the other work. This makes it easier to spot a missing dependency or a scope decision while it is still easy to change.
| Question | What to inspect | If it does not fit |
|---|---|---|
| Does it match the outcome? | Goals, affected areas, and expected behavior | Explain the missing or incorrect scope. |
| Are important states included? | Errors, interruptions, empty states, and success paths | Ask for the missing branch before continuing. |
| Can the result be reviewed? | Acceptance criteria and available project checks | Align the review with the tools the project provides. |
Follow related work products
A larger plan may be accompanied by a specification, design artboards, or a behavior flow. These make different decisions easier to review; see Specs, designs, and flows. For structural context that is separate from the plan, read Codebase Structure.
What if no plan appears?
A short task may move directly toward review. Use the visible request, project context, and resulting changes as your source of truth rather than assuming that a missing plan means missing work.
Continue to Changes and verification after implementation, or use Troubleshooting when a plan or artifact does not match the task.