End Your Prompts with Success Criteria So Claude Knows When It's Done
Without a clear finish line, Claude has to guess when the job is done. Sometimes it stops after the first file edit. Sometimes it keeps going and refactors half your codebase. The fix is simple: tell it exactly what "done" looks like.
Add a password reset flow to the app.
This task is complete when:
- A user can request a reset link from /forgot-password
- The email sends with a valid signed URL
- The reset form accepts and validates a new password
- All existing auth tests still pass
Claude will work through each criterion methodically and won't stop until they're all satisfied. It also gives Claude permission to run tests, check routes, or verify behaviour — because it knows what it needs to prove.
This pattern works for any scope:
Refactor the order service to use the repository pattern.
Done when:
- No Eloquent queries remain in OrderController
- OrderRepository handles all database access
- Existing feature tests pass without modification
Fix the broken CSV export.
Success criteria:
- The export downloads without a 500 error
- All columns match the spec in docs/export-format.md
- Empty datasets export a header-only file instead of failing
Where this really shines:
- Multi-step features — Claude won't declare victory after step one.
- Bug fixes — forces Claude to verify the fix, not just apply a patch.
- Refactoring — ensures behaviour stays identical while internals change.
A prompt without success criteria is a task without a definition of done — and that's how scope creep starts.
via Claude Code
Log in to leave a comment.
Before jumping to implementation, describe the problem conversationally and let Claude be your thinking partner. It asks clarifying questions, surfaces tradeoffs you haven't considered, suggests approaches, and pokes holes in your plan — so by the time you say "ok, build it," both of you know exactly what to build and why.
Paste error messages with "why did this fail?" instead of "fix this" to get Claude to diagnose the root cause before applying a fix.
When you need Claude to make changes in one area without affecting another, add negative constraints — "fix the bug but don't change the public API", "refactor the internals but don't create new files", or "update the logic but don't modify any tests." Explicit exclusions prevent Claude from making well-intentioned changes you'll have to undo.