Write Claude Code Prompts with Constraints, Acceptance Criteria, and Proof

Quick answer

The best Claude Code prompt defines six things: outcome, context, constraints, acceptance criteria, verification, and handoff. It leaves implementation details open unless a specific design is required. This gives Claude room to explore while making completion objective.

This framework operationalizes Anthropic's Claude Code best practices: be specific, let Claude explore, provide constraints, and give it something objective to verify against.

The O-C-C-A-V-H framework

1. Outcome

Describe the user-visible or system-visible result.

Users whose session expires during checkout should be returned to sign-in and
then resume checkout without losing their cart.

2. Context

Point to reliable starting evidence, not your entire theory.

The flow begins in src/app/checkout/page.tsx. Session refresh is handled under
src/auth/. The existing cart persistence tests are in tests/cart/.

3. Constraints

Name boundaries that protect architecture, security, and scope.

Do not change the session duration, database schema, or public API. Preserve
accessibility and existing analytics events. Do not add dependencies.

4. Acceptance criteria

Write observable statements:

• An expired session redirects to sign-in.
• A successful sign-in returns to the original checkout URL.
• The cart contents remain unchanged.
• Invalid return URLs cannot redirect off-site.
• Existing active-session checkout still works.

5. Verification

Specify proof, not ceremony:

Add a regression test for expiry and an open-redirect security test. Run the
focused tests, typecheck, and the nearest checkout integration suite. Report
commands and results.

6. Handoff

Define the final report:

Summarize root cause, changed files, evidence, and residual risks. Do not claim
success if any required check did not run.

Exploration prompt vs implementation prompt

For risky work, split the phases.

Exploration:

Trace the current password-reset flow. Identify trust boundaries, token storage,
expiry checks, and rate limiting. Cite exact files and symbols. Do not edit.
Return uncertainties and two plausible failure modes.

Implementation after review:

Implement failure mode 1 using the existing token service. Add the regression
test first. Keep the public response indistinguishable for known and unknown
emails. Run the security-focused test suite.

Ask for plans selectively

Planning helps when work spans components, contains migrations, or has destructive risk. It adds overhead for a typo. A useful plan names dependencies, checkpoints, and validation—not a verbose restatement of the request.

Before editing, produce a five-step plan. For each step include the files likely
to change, the invariant protected, and how it will be verified. Flag decisions
that require product input.

Debug with competing hypotheses

Avoid anchoring Claude on your first guess:

The API latency rose after release 2.14. Generate three competing hypotheses.
For each, name the cheapest discriminating observation. Gather evidence in that
order. Do not edit until one hypothesis is materially stronger.

This is faster than implementing three speculative fixes.

Review prompts that find real bugs

Review the current diff against main. Prioritize correctness, security, data
loss, concurrency, and missing tests. For every finding, cite the exact line,
describe a concrete failure scenario, and propose the smallest fix. Skip style
preferences unless they violate repository rules.

Anti-patterns

• “Make it better”: no measurable finish line.
• “Use microservices”: prescribes architecture before evidence.
• “Fix all issues”: unlimited scope and no priority.
• Huge pasted logs: buries the relevant signal.
• “Be 100% sure”: confidence language cannot replace verification.
• Dictating every tool call: prevents the agent from adapting to observations.

Calibrate autonomy to risk

Prompting is also permission design. A low-risk documentation edit can authorize implementation and verification in one turn. A schema migration, production incident, dependency upgrade, or security change should use explicit checkpoints: investigate, review the plan, implement locally, verify, and stop before any remote action. State the escalation boundary in the prompt instead of expecting Claude to infer organizational policy.

For large tasks, ask Claude to maintain a short assumption ledger. Each entry should be labeled verified, decided, or unresolved. This prevents an early guess from quietly becoming architecture. If new evidence invalidates the plan, require an updated plan rather than forcing the code to follow obsolete instructions.

Score a prompt before running it

Give one point for each clear element: observable outcome, reliable starting evidence, boundaries, negative cases, runnable verification, and external-action stop condition. A score below four usually means the agent will spend extra context discovering what “done” means. Do not inflate the prompt with prose to raise the score; add the missing decision-changing fact.

FAQ

Should prompts be long?

Only as long as needed to remove material ambiguity. Dense constraints and clear acceptance criteria beat narrative volume.

Should I ask Claude to think step by step?

Ask for a plan, evidence, tradeoffs, and verification. You need inspectable work products, not hidden reasoning.

What is the single highest-leverage prompt improvement?

Add an objective verification oracle: a failing test, expected output, reproduction command, screenshot, schema, or acceptance checklist.