Context Engineering Rules for Claude 5 Models

To use Claude models with improved judgment effectively, refining a single prompt sentence is not enough. You need to design the system instructions, project files, tools, memory, conversation history, and execution results that the model will see during a single reasoning process as one information environment.

The core principle is simple.

Rather than prescribing every action in advance, provide a clear objective, safety boundaries, expressive interfaces, and reliable reference materials, and leave detailed judgments to the model.

In this article, Claude 5 refers to the next-generation, high-performance Claude model environment described by the provided materials. The focus is not on specific product specifications or release status, but on context design principles that can be applied to models with improved judgment.

Prompt Engineering and Context Engineering

Prompt Engineering

Prompt engineering is the work of designing how to express the current request. It generally covers the following items.

• Task objective
• Scope of work
• Constraints
• Output format
• Success criteria
• Necessary examples

For example:

Implement payment cancellation in a Next.js API Route.
Reuse the existing service layer and add tests.
Do not change the public API contract, and explain the reasons for the changes.

Context Engineering

Context engineering is the work of selecting and maintaining the entire set of information that enters the model’s reasoning process. In a coding agent such as Claude Code, the context consists roughly of the following elements.

The user’s current request
+ System instructions
+ CLAUDE.md and project instructions
+ Skills
+ Automatic memory
+ Code, specifications, tests, and documentation
+ Tool definitions and MCP resources
+ Conversation history
+ Tool execution results and error logs

Therefore, even a good prompt can become less effective when provided together with outdated memory, duplicated project rules, or massive logs. Conversely, even a short request can be executed accurately enough when accompanied by relevant code, tests, and clear tools.

Why More Context Is Not Always Better

Even as an LLM’s context window grows, the attention available for a task is not unlimited. As the number of low-relevance tokens increases, the following problems can arise.

1. Important requirements become buried in verbose explanations.
2. Similar instructions in different locations conflict in subtle ways.
3. Outdated decisions or failed attempts affect the current task.
4. Examples act like correct answers and constrain alternative solution paths.
5. Logs and tool output take up space needed for code, specifications, and tests.
6. The model spends reasoning effort interpreting instruction priorities rather than performing the actual task.

Anthropic describes how information-use efficiency declines in long contexts and recommends designing agents to retrieve necessary information at the right time and compress outdated history. What matters is not filling the maximum token count, but increasing the proportion of high-signal tokens that affect the result.

What the System Prompt Reduction Case Means

In the provided Anthropic case, the company explains that it reduced the system prompt by at least 80% after reviewing Claude Code’s internal instructions. This figure is not a rule requiring every application’s prompt to be reduced by the same proportion. It should be understood as an example of removing duplicated and excessively detailed behavioral instructions from a particular system.

For example, the following instructions could all appear in a single request.

System instruction: Leave documentation appropriate to the situation.
Skill instruction: Do not add comments.
User request: Make it work like the previous version.

Each sentence may be reasonable on its own, but placing them together creates several interpretation problems.

• Are documentation and code comments in the same category?
• Is the prohibition on comments a rule without exceptions?
• Does the behavior of the previous version also include its comments or documentation structure?
• Which takes priority: the current request or the reusable Skill?

In this case, the model’s coding ability is not the only cause of failure. Another cause is that the information environment created by people contains unnecessary contradictions.

Six New Rules for Context Design

1. Replace Detailed Prohibition Lists with Context-Based Principles

To prevent repeated mistakes by earlier models, rules were sometimes listed at length as follows.

• Do not write comments.
• Do not create multi-paragraph docstrings.
• Do not create planning documents unless requested.
• Do not save intermediate analysis files.

These rules prevent specific failures, but they are not absolute principles that apply in every situation. Complex security validation or concurrent code may require explanations, while comments may instead create noise in self-evident CRUD code.

It is better to provide judgment criteria like the following.

Write code that reads consistently with the surrounding code.
Follow the naming conventions, idioms, and comment density of existing files.
Add only the documentation necessary for logic whose safety or intent would otherwise be unclear.

However, not every rule should be weakened. The following items should remain explicit constraints or tool-level controls.

• Approval for production deployments and data deletion
• Restrictions on processing personal and confidential information
• Authentication and authorization validation
• Idempotency and audit records for financial transactions
• Database migration policies
• Compliance with laws, licenses, and regulations
• Immutable public API contracts

2. Design Expressive Tools Instead of Providing Many Examples

Continuously adding examples of valid and invalid calls to a tool’s description expands the context and may cause the model to imitate the surface form of the examples. A better approach is to make the tool name, input fields, and state transitions reveal how the tool should be used.

TodoWrite
Purpose: Create and update the task list for the current session

status:
- pending
- in_progress
- completed

Constraint:
- Only one task may be in_progress at a time

A good agent tool has the following characteristics.

• Its name alone reveals the action and target.
• Required and optional fields are distinguished.
• Enums restrict permitted values.
• Reading and writing, as well as previewing and execution, are separated.
• Errors return the cause and recovery method in a structured format.
• Dangerous operations require a confirmation token or approval step.
• If results are excessively long, the tool provides summaries and pagination.

Examples should be added only to explain exceptions or ambiguous inputs that are difficult to express through the interface.

3. Do Not Include All Information from the Start; Disclose It Progressively

You should not inject the entire repository, every policy, and long logs from the start merely because an agent might need them for the task. First provide the minimum information needed for exploration, then have the agent read relevant materials as the task becomes more specific.

The recommended flow is as follows.

1. Provide the objective, success criteria, and safety boundaries.
2. Find relevant locations through the repository structure or search tools.
3. Read only the necessary files and specifications.
4. After implementation, run relevant tests and static analysis.
5. If a failure occurs, retrieve only the corresponding error and surrounding code.
6. After completion, compress or remove outdated logs and intermediate reasoning.

Progressive disclosure does not mean hiding information. It means providing retrieval paths and a clear file structure so that the model can discover the information it needs.

4. Remove Duplicate Instructions and Establish Authoritative Locations

If the same rule is copied into the system prompt, CLAUDE.md, a Skill, and tool descriptions, the wording may diverge over time. One authoritative storage location should be established for each type of instruction.

If duplication is unavoidable, it is safer to point to the authoritative location or generate the content automatically rather than copying it.

5. Separate the Roles of CLAUDE.md and Automatic Memory

CLAUDE.md is suitable for persistent instructions that project members can review and manage through version control.

• Standard build and test commands
• Essential explanations of the repository structure
• Areas the team has agreed must not be changed
• Project-specific validation procedures
• Rules that are difficult to infer using general tools

By contrast, the following information is more appropriate for automatic memory or session state.

• Personalized preferences discovered through repeated tasks
• Exploration paths that proved useful in recent tasks
• Temporary characteristics of the development environment
• Progress in the current session

Automatic memory should not be assumed to be always accurate or permanent. It should be possible to revise or remove outdated items, and it should not be used as the sole repository for security policies and public contracts.

6. Prioritize Executable Reference Materials over Explanatory Documents

Natural-language specifications are useful for explaining intent, but they may not fully represent actual behavior. When possible, provide the following materials together.

• Existing implementations similar to the current code
• Unit tests and integration tests
• API schemas and type definitions
• Actual HTML or design deliverables
• Database migration files
• Example input and output data
• Evaluation rubrics and automated scoring criteria

Conflicts can also arise among reference materials, so their priority should be stated. For example, contract tests can be designated as the authoritative standard for the public API, while the README is treated as explanatory material.

Practical Context Configuration Template

The following structure is an example of organizing the information needed for a coding task concisely.

Objective
- Add a payment cancellation API.

Success criteria
- Reuse the existing payment service layer.
- Cancel only once even when duplicate requests are received.
- Pass the relevant contract tests.

Strong constraints
- Do not change the public response schema.
- Do not access production data.

Reference materials
- src/payments/capture.ts
- tests/contracts/payment-cancel.test.ts
- openapi/payments.yaml

Judgment principles
- Follow the error handling and naming conventions of the surrounding payment code.
- Ask before implementation if there are unsafe assumptions.

Validation
- Targeted unit tests
- Contract tests
- Type checking

This format does not attempt to list every situation in advance. Instead, it separates the objective, success conditions, immutable boundaries, authoritative materials, and validation methods.

Procedure for Cleaning Up Existing Context

Step 1: Inventory the Sources of All Instructions

Review the system prompt, CLAUDE.md, Skills, automatic memory, tool descriptions, and CI configuration together. Looking at only one document makes it difficult to identify actual conflicts.

Step 2: Classify Each Instruction

• Required for safety or legal reasons
• Required by the product contract
• A persistent team convention
• An explanation needed only for a specific tool
• A temporary rule intended to prevent mistakes by earlier models
• A rule whose basis is currently unclear

Step 3: Find Duplication and Conflicts

Group sentences that express the same behavior differently. In particular, review expressions such as always, never, must, and do not first.

Step 4: Move Rules into Tests or Permissions

Items that can be verified more reliably through automation than through natural-language warnings should be moved into the following layers.

• Tests and linters
• Type systems and schemas
• Least-privilege tools
• Approval procedures
• Sandboxes
• CI policies

Step 5: Evaluate with Real Tasks

Do not measure prompt length alone. Compare the following metrics across a representative set of tasks.

• Success rate and test pass rate
• Number of unnecessary file changes
• Number of user corrections
• Tool call failure rate
• Time and tokens required for completion
• Whether safety policies were violated

Step 6: Address Only the Causes of Failure, Minimally

Do not immediately add a new prohibition rule whenever a failure occurs. First determine whether the cause was an ambiguous objective, insufficient reference materials, or an incorrect tool schema.

Instructions That Must Not Be Removed

Simplification does not mean unconditional deletion. If the answer to any of the following questions is yes, the instruction should be retained or moved to a stronger control.

• Would a violation cause data loss or financial harm?
• Does it relate to legal, privacy, or licensing obligations?
• Is it an organizational policy that the model cannot infer from the code alone?
• Does it determine the compatibility of a public API or data format?
• Is human approval required before executing the task?
• Is it difficult to fully detect violations through automated tests alone?

Common Failure Patterns

Adding a New Rule After Every Failure

If a single error is generalized into a permanent rule, exceptions and conflicts accumulate. First add an evaluation case and verify whether the failure recurs.

Using Long Examples as De Facto Templates

If an example is too specific, the model may prioritize it over the current codebase. Keep examples to the minimum size needed to explain the principle.

Preserving Entire Logs Unchanged

Tool output and build logs quickly consume context. It is better to retain only the cause of the failure, the relevant stack, and the changed state in a structured format.

Using Automatic Memory as a Policy Repository

Automatic memory is convenient, but its review, deployment, and audit systems may be weak. Mandatory organizational policies should be stored in version-controlled instructions or a permission hierarchy.

Evaluating Context Reduction as Mere Token Savings

Shorter context is not always better. Removing necessary tests, safety rules, or specifications worsens results. The goal is not the fewest tokens, but the minimum set of high-signal tokens.

Final Checklist

• Are the objective and success criteria of the current request separated?
• Are safety rules distinguished from style preferences?
• Is the same instruction duplicated in multiple locations?
• Does the tool schema explain how to use the tool without long examples?
• Can relevant files be retrieved when needed?
• Is there a way to remove outdated memory and execution logs?
• Can natural-language rules be enforced through tests or permissions?
• Is the priority among reference materials clear?
• Are there evaluation tasks for comparing performance before and after instruction changes?

Conclusion

Context engineering for high-performance Claude models is not a technique for reducing instructions indiscriminately. It is information design that clarifies the objectives, safety boundaries, and evidence the model needs to judge the current task, while removing irrelevant information and conflicting rules.

The most practical principle can be summarized as follows.

Enforce security and contracts strongly, leave style to context, provide information when it is needed, and validate results with executable tests.