Claude Rules Best Practices

This page distills every rule list in the Claude Rules & Best Practices section into one standalone checklist - the positive, enforceable version of each rule, grouped by category, meant to be worked through during a production readiness review or a periodic team audit.

How to Use This Checklist

• Work through it by category, not top to bottom by number - a team adopting these rules for the first time usually starts with A and D before tackling the rest.
• Treat each checkbox as something you can point to evidence for - a config value, a lint rule, a review comment, or an ADR - not just a belief.
• Use it as a production-readiness gate before a Claude-powered feature reaches real users or real budget.
• Revisit the whole list on a fixed cadence, and immediately after any incident whose root cause traces back to a missing rule.

A - Model Selection

• Match model tier to task complexity by default. Classification and extraction start at Haiku, general work at Sonnet, hard multi-step reasoning at Opus, and the most demanding long-horizon agentic work at Fable.
• Require evidence before escalating to a heavier tier. A tier change is backed by a failed sample review or a measured quality gap, not a hunch.
• De-escalate proven routes on a regular cadence. Any route where a cheaper tier has matched quality across a representative sample gets moved down and monitored.
• Keep synchronous, user-facing paths off the heaviest tier unless the UX can tolerate the latency. Latency-tolerant heavy reasoning moves to async or batch processing instead.
• Document the tier decision for every production route. A config entry or comment naming the model and the reason prevents silent, unreviewed changes later.

B - Prompt and Context Hygiene

• Structure every prompt into clearly labeled sections. Role, task, constraints, and output format each get their own block rather than blending into unstructured prose.
• Require an owner and a reason for every system prompt addition. Prompts that grow by unreviewed accretion degrade in ways nobody can trace back to a specific change.
• Trim context proactively, not reactively. Stale tool results and superseded turns are dropped before they degrade response quality, not after a user notices something is wrong.
• Keep output format consistent for the same task type across every call site. A parser written for one route should work for every route producing that same kind of output.
• Prune instructions nobody can currently justify. If no one on the team can explain why a line is in the system prompt, that's a signal to test removing it, not to leave it indefinitely.

C - Tool Design

• Scope every tool to exactly one well-defined action. A tool doing several unrelated things is split until each piece can be reasoned about and permissioned independently.
• Name tools for what they do, not how they're implemented. Naming stays consistent across the toolset so the model's tool selection is predictable.
• Validate tool inputs and outputs separately, both before they cross a trust boundary. Bad input reaches real systems; bad output corrupts the model's next turn - both need their own check.
• Gate destructive or irreversible tool calls behind confirmation. Deletions, payments, and production writes never execute automatically without a human step or a reviewed exception.
• Review the full toolset for overlapping purpose, not just each tool alone. Ambiguity between two tools that can both accomplish a task gets resolved before it causes inconsistent behavior in production.

D - Cost Control

• Cache stable prompt prefixes behind a breakpoint. System prompts and tool definitions that don't vary per-request are positioned so they can actually be reused.
• Route non-latency-sensitive bulk work through the Batches API. Real-time pricing is reserved for requests that genuinely need a synchronous response.
• Set a tracked, alertable token budget per team. Every team consuming the Claude API has a spend ceiling someone gets paged about before it's exceeded, not after the invoice arrives.
• Measure actual token usage against pre-call estimates. Cost assumptions are checked against usage fields regularly enough to catch drift while it's still small.
• Re-evaluate cost levers whenever the model lineup changes. A caching or batching strategy tuned for one model generation is re-verified against the next.

E - Security Guardrails

• Apply least privilege to every credential a Claude-powered system can reach. No tool, MCP server, or integration holds broader access than its task strictly requires.
• Treat model output as untrusted input everywhere it touches a real system. Generated text and tool arguments are validated and parameterized, never interpolated directly into a command, query, or path.
• Log every sensitive tool call independent of the conversation transcript. Destructive or data-touching calls have an audit trail that survives even if the transcript is edited, truncated, or lost.
• Keep secrets out of prompts, system messages, and memory files entirely. Credentials live in a vault or environment variable, never in text the model can read back.
• Isolate untrusted external content from operator-level instructions. Retrieved documents and web content are structurally separated from system-level authority so an embedded instruction can't masquerade as one.

F - Governance and Team Practice

• Assign an explicit owner for the team's Claude rules. Rules degrade into inconsistency the moment no one is accountable for keeping them current.
• Turn every incident's root cause into a rule, not just a one-off fix. A mistake that isn't captured as an enforceable rule tends to recur in a different call site written by a different engineer.
• Review rule sets on a fixed cadence, not only after something breaks. A quarterly pass catches rules that have gone stale as the model lineup or the product has changed.
• Make deviations from a rule an explicit, reviewed exception. A default that's silently overridden in one place is decision drift; a default that's deliberately overridden with a documented reason is a judgment call.
• Keep the rule set small enough that the team can actually hold it in their heads. A rule set too large to remember gets ignored, which is functionally the same as having no rules at all.

FAQs

Related

• How Opinionated Rules Prevent Claude Production Incidents - the mental model behind why every item on this page is written as an enforceable rule.
• The Core Claude Rules: A Quick-Reference List - the same rule set organized by category with links to full detail.
• Security Guardrail Rules Every Tech Lead Should Enforce - the full detail behind category E.
• Cost Control Rules: Caching, Batching, and Token Budget Discipline - the full detail behind category D.

Stack versions: Written against the Claude model lineup current as of ~June 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (the default), and Claude Haiku 4.5 - and the official anthropic Python SDK (latest 0.x release). Model names, pricing, and SDK versions move quickly - verify current specifics at platform.claude.com/docs before relying on them.