Cursor checkpoints are convenient snapshots of Agent changes, but they are not a replacement for version control. Commit meaningful states in Git before risky work.
1. Create a clean starting point
Make sure Git status is understood before starting. Commit or stash unrelated local changes so the Agent diff is easy to interpret.
2. Ask for one bounded change
Limit the task to one bug or feature slice. Broad tasks create a diff that is harder to reason about and harder to restore selectively.
3. Review the diff by intent
Check changed files, deleted code, generated files and configuration. For each hunk, ask whether it is necessary for the stated task.
4. Run the repository checks
Execute the tests, lint, typecheck or build that prove the change works. Do not treat a green-looking diff as evidence that behavior is correct.
5. Restore when the direction is wrong
If Agent took the wrong approach, use the available checkpoint or Git to return to a known state, then rewrite the task instead of layering fixes over a bad foundation.
After editing, stop and show me a concise diff summary grouped by behavior. Then run the existing checks that cover this change. If more than the intended files changed, explain each extra file before I accept it.
Treating checkpoints as durable source control; starting with a dirty Git tree; accepting generated-file churn; restoring a checkpoint without understanding which unrelated changes it contains.
Finish check
You can explain every changed file, tests cover the intended behavior, and both Git and checkpoint recovery paths are clear.