Ground the Codebase Before Requesting Edits
Before asking for changes, state what the app does, how it behaves today, which files own the logic, and what must remain untouched.
Key points
- Current behavior
- Target behavior
- Non-negotiable invariants
Exercise Pick a real code change and describe current state, target state, and boundaries in three sentences.
Slice Tasks Into Observable Steps
Break “add search” into query input, matching results, empty-state reset, and URL persistence. Ship the main path first without opportunistic rewrites.
Key points
- Concrete user trigger
- Observable state change
- Explicit failure/empty state
Exercise Rewrite a vague feature wish into three executable acceptance steps.
Verify From the Real Entry Point
Generated files are not proof of working UX. Walk the real user entry point, inspect runtime behavior, and separate observed errors from guesses.
Key points
- Test via actual UI/API entry
- Record exact reproduction steps
- Re-check adjacent flows
Exercise Execute your three acceptance checks, log real outcomes, and mark anything untested honestly.
Define Clean Stop Conditions
Stop once target behavior passes verification and out-of-scope ideas are logged for future iterations. Fold reusable patterns back into your notes.
Key points
- Target achieved
- Affected paths verified
- Deferred items documented
Exercise Write a handoff note stating exact verification—banning vague words like “optimized.”