State Your Constraints Before the Task So Claude Gets It Right the First Time
The most common reason for back-and-forth with Claude is unstated constraints. Claude picks a reasonable default, you correct it, it rewrites — wasting time and context. State the rules first.
# Instead of this:
"Write tests for the UserService"
# ...then correcting: "No, use Pest not PHPUnit"
# ...then correcting: "Don't mock the database, use RefreshDatabase"
# Do this:
"Using Pest with RefreshDatabase (no mocks), write tests for UserService"
The constraint-first pattern works for any task:
# Architecture constraints
"Without adding any new dependencies, refactor the notification system to support SMS"
# Style constraints
"Using only Tailwind utility classes (no custom CSS), build a responsive pricing card"
# Compatibility constraints
"This must work in PHP 8.3 without readonly classes. Update the DTOs accordingly"
# Scope constraints
"Only modify files in src/api/ — don't touch the frontend. Add pagination to the users endpoint"
The most useful constraints to state upfront:
- Technology choices — which framework, library, or tool to use
- What NOT to do — boundaries Claude should respect
- File scope — which files or directories to touch (or avoid)
- Style requirements — formatting, naming conventions, patterns to follow
- Compatibility — language versions, browser support, API versioning
- Testing approach — which test framework, real vs mocked dependencies
You can also put recurring constraints in your CLAUDE.md so you don't repeat them every prompt. But for one-off requirements, stating them inline is fastest.
# Stack multiple constraints naturally
"Using React Server Components (not client), with Zod validation,
following the existing pattern in src/components/forms/,
add a contact form with name, email, and message fields"
Constraints aren't limitations — they're specifications. The more Claude knows upfront, the less you correct afterward.
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.