Use it when
When you want to understand a failure before fixing it.
Before moving on
Ask for missing error text and avoid recommending destructive reset commands.
Capture an error, trace the actual cause, make a focused fix, and review what changed.
Paste the complete error with secrets removed. Explain what you clicked, what you expected, and what happened. Ask for a diagnosis before a change.
Paste the complete error with secrets removed. Explain what you clicked, what you expected, and what happened. Ask for a diagnosis before a change.
Open one task, customize it for your project, and check the result before moving on. Skip any step that does not apply.
Use it when
When you want to understand a failure before fixing it.
Before moving on
Ask for missing error text and avoid recommending destructive reset commands.
Use it when
When the browser console shows a repeatable error.
Before moving on
Reproduce the original flow and check for new related errors.
Restore a broken action without redesigning the page.
Open this task ↗Use it when
When a click produces no useful result.
Before moving on
Check success, failure, loading state, and existing surrounding behavior.
Align the server-rendered page with the browser render.
Open this task ↗Use it when
When a supported framework reports a hydration error.
Before moving on
Check initial load and navigation; do not merely suppress the warning.
Make direct visits behave like in-app navigation.
Open this task ↗Use it when
When refreshing a deeper page returns a 404.
Before moving on
Check direct load, refresh, client navigation, and real unknown-route 404 behavior.
Use it when
When you want a plain-English review of your working changes.
Before moving on
Reference affected files and separate confirmed problems from possibilities.
Save your work or review a Git commit between meaningful stages. A clean checkpoint makes the next experiment easier to understand and reverse.
Learn the terminal basics →