The Core Claude Rules: A Quick-Reference List
This page condenses every enforceable rule this site distills for shipping Claude in production - model selection, prompt and context hygiene, tool design, cost control, and security guardrails - onto one page you can scan during a code review or an incident retro.
It intentionally has no long explanations.
Each row links out to the article that covers the full reasoning, examples, and edge cases.
How to Use This List
- Keep this page open during pull request review for any code that calls the Claude API.
- Treat each rule as a default, not an absolute - deviations should be a deliberate, reviewed exception, not a silent one.
- Revisit this page whenever the model lineup changes (new Opus, Sonnet, Haiku, or Fable release) - several rules are model-tier specific.
- Use the category tables to onboard a new engineer to the team's Claude conventions in one sitting.
- Pair this page with Claude Rules Best Practices, which restates every rule here as an enforceable checklist item.
Model Selection Rules
| Rule | Default | Full detail |
|---|---|---|
| Match model tier to task complexity | Haiku for classification/extraction, Sonnet for general work, Opus for hard multi-step reasoning, Fable for the most demanding long-horizon agentic work | Model Selection Rules |
| Never default to the most capable model "to be safe" | Start at the cheapest tier that meets the quality bar, escalate only with evidence | Model Selection Rules |
| Re-evaluate tier choice on every model launch | A rule pinned to a model's old cost/latency profile can become stale overnight | Model Selection Rules |
| Route latency-sensitive paths away from the heaviest tier | Opus and Fable trade latency for depth; do not put them on a synchronous user-facing path without a reason | Model Selection Rules |
Prompt and Context Hygiene Rules
| Rule | Default | Full detail |
|---|---|---|
| Structure prompts with explicit sections | Role, task, constraints, and output format each get their own clearly labeled block | Prompt and Context Hygiene |
| Keep system prompts append-only in review, not append-only in practice | Every addition needs a named owner and a reason; prune instructions nobody can justify anymore | Prompt and Context Hygiene |
| Trim context before every request, not after it breaks | Drop stale tool results and superseded turns rather than letting the transcript grow unbounded | Prompt and Context Hygiene |
| Keep output format consistent across call sites | The same task type should produce parseable output the same way everywhere it's requested | Prompt and Context Hygiene |
Tool Design Rules
| Rule | Default | Full detail |
|---|---|---|
| Scope tools narrowly | One tool, one well-defined action - not a general-purpose "do anything" tool | Tool Design Rules |
| Name tools for what they do, not how they're implemented | refund_order, not call_billing_endpoint | Tool Design Rules |
| Validate every tool input before it executes | Never trust the model's arguments as pre-sanitized | Tool Design Rules |
| Validate every tool output before it re-enters context | A malformed or unexpectedly large result should be caught, not silently passed back to the model | Tool Design Rules |
| Gate destructive or irreversible tool calls behind confirmation | Deletions, payments, and production writes are never fire-and-forget | Tool Design Rules |
Cost Control Rules
| Rule | Default | Full detail |
|---|---|---|
| Cache stable prompt prefixes | System prompts and tool definitions that don't change per-request belong behind a cache breakpoint | Cost Control Rules |
| Batch non-latency-sensitive requests | Use the Batches API for bulk work instead of paying real-time pricing | Cost Control Rules |
| Set a per-team token budget | Every team consuming the Claude API gets a tracked, alertable spend ceiling | Cost Control Rules |
| Measure actual token usage, don't estimate it | Compare usage fields against pre-call estimates to catch drift early | Cost Control Rules |
Security Guardrail Rules
| Rule | Default | Full detail |
|---|---|---|
| Scope API and tool permissions tightly | Least privilege applies to every credential a Claude-powered system can reach | Security Guardrail Rules |
| Validate model output before acting on it | Treat generated text and tool arguments as untrusted input, not a trusted instruction | Security Guardrail Rules |
| Log every sensitive tool call | Destructive or data-touching calls need an audit trail independent of the conversation transcript | Security Guardrail Rules |
| Never place secrets in a prompt or memory file | Credentials belong in a vault or environment variable, never in text the model can read back | Security Guardrail Rules |
FAQs
Is this page a replacement for the full rule articles?
No. It is a scanning aid - each row exists to remind you a rule exists and point you to the article with the full reasoning, examples, and exceptions.
Why does this page substitute for a section basics page?
Because this section is a rules/checklist cookbook rather than a tutorial section, a single condensed reference serves the role a "basics" intro would in a code-recipe section - it is the page a reader lands on first to get oriented.
Which rule category should a new team read first?
Model Selection Rules, because the model tier choice affects the cost and latency profile of every other decision on this page. Cost Control Rules is the natural second stop.
How often should this page be revisited?
At minimum whenever the model lineup changes, and any time an incident review surfaces a rule that this page is missing or has wrong.
Are these rules mandatory, or defaults?
Defaults. Every row can be overridden with a deliberate, reviewed reason - the point is that deviations are explicit decisions, not accidents.
What's the difference between this page and Claude Rules Best Practices?
This page groups rules by category with a one-line default and a link out. Claude Rules Best Practices restates every rule as a standalone checkbox item you can tick off during review, without needing the category grouping.
Why is tool input validation listed separately from tool output validation?
Because they fail differently. Unvalidated input lets a malformed or malicious argument reach your systems; unvalidated output lets a bad tool result silently corrupt the model's next turn. Both need a check, and conflating them tends to mean only one gets built.
Does "scope tools narrowly" conflict with giving an agent enough capability to be useful?
No - narrow scope means each individual tool does one well-defined thing, not that the agent has few tools overall. An agent with ten narrow tools is safer and more debuggable than one with two broad ones that each do several unrelated things.
Why does cost control include a rule about measuring actual usage?
Because a cost model that's never checked against real usage fields drifts silently - caching, batching, and budgets all assume you can tell when they stop working, and the only way to tell is to measure.
Is prompt caching worth it for every request?
No - it pays off only when a stable prefix is reused across enough requests to offset the cache-write cost. See Cost Control Rules for the break-even math.
What counts as a "sensitive" tool call that needs logging?
Anything that reads or writes data outside the conversation itself - database writes, payments, emails sent, files deleted, or any call to a system with its own audit requirements. See Security Guardrail Rules for the full list.
Should this page be the only rules document a team maintains?
It's a starting point, not a ceiling. Teams with domain-specific risks (regulated data, financial transactions) should extend these categories with their own rules rather than treating this list as exhaustive.
Related
- How Opinionated Rules Prevent Claude Production Incidents - the reasoning behind why this page exists in condensed form.
- Model Selection Rules: When to Use Opus, Sonnet, or Haiku - the full model-selection rule set.
- Cost Control Rules: Caching, Batching, and Token Budget Discipline - the full cost-control rule set.
- Claude Rules Best Practices - the same rules restated as a standalone checklist.
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
anthropicPython 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.