Context Engineering Rules for Claude 5 Models ============================================= For Claude models with improved judgment, a clear purpose, well-designed tools, and task-appropriate references matter more than numerous detailed rules. This article explains context design principles and implementation procedures for reducing redundant instructions and providing necessary information at the right time. - Context engineering involves designing not only prompts, but also system instructions, tools, memory, files, conversation history, and execution results together. - Safety, legal, permission, and data integrity rules should remain strict, while style guidelines that vary by situation should be replaced with context-based principles. - Rather than providing all information from the outset, it should be surfaced when needed through search, file reading, Skills, and subagents. - Rather than repeatedly listing examples of tool use, interfaces should be designed with clear names, input schemas, state definitions, and error structures. - CLAUDE.md, automatic memory, code, tests, and specifications should serve distinct roles, and the same instructions should not be duplicated across multiple locations. 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. Category Prompt Engineering Context Engineering Design target Expression of the current request The entire information environment used in reasoning Main question What should be requested, and how? What should the model see, and when? Representative elements Objectives, formats, constraints, examples System instructions, files, tools, memory, history Main failures Ambiguous requests, unclear success criteria Conflicts, duplication, outdated information, excessive logs Improvement method Make requests specific and provide validation criteria Select high-signal information, retrieve it at the right time, and manage its lifecycle 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. Important requirements become buried in verbose explanations. Similar instructions in different locations conflict in subtle ways. Outdated decisions or failed attempts affect the current task. Examples act like correct answers and constrain alternative solution paths. Logs and tool output take up space needed for code, specifications, and tests. 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 Previous Approach Recommended Approach Define detailed behavior through prohibition lists Provide objectives and judgment criteria, and use context Provide many examples of tool calls Design the schema itself to explain how to use the tool Inject all information at the start of the task Disclose information progressively when needed Repeat the same instruction in multiple locations Assign one authoritative storage location to each instruction Store even temporary memories in CLAUDE.md Separate the roles of permanent policies and automatic memory Rely on long Markdown explanations Provide executable materials such as code, tests, HTML, and evaluation rubrics 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 Rule Type Appropriate Handling Security, legal, and authorization Maintain explicit, strong constraints Operations that may cause data loss Control through approval procedures and tool permissions Public contracts and compatibility Validate through tests and schemas Code style and comments Use judgment principles based on surrounding code Temporary order of operations Manage in the current plan or task list 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. Provide the objective, success criteria, and safety boundaries. Find relevant locations through the repository structure or search tools. Read only the necessary files and specifications. After implementation, run relevant tests and static analysis. If a failure occurs, retrieve only the corresponding error and surrounding code. 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. Information Recommended Location Organization-wide safety policies System instructions or permission hierarchy Repository build and test commands Project CLAUDE.md Procedures for a specific task The corresponding Skill Tool inputs and constraints Tool schema and description Public API behavior Code schemas, specifications, and contract tests Current session progress Task list or session state 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. FAQ Q. How do prompt engineering and context engineering differ? A. Prompt engineering deals with how to express the goals, format, and constraints of the current request. Context engineering designs what to show the model and when, including that prompt, system instructions, files, tools, memory, conversation history, and execution results. Q. Does a longer context always improve model performance? A. No. A long context can contain irrelevant information, outdated records, and conflicting instructions. What matters is not the total number of tokens, but the proportion of high-signal information that directly contributes to the current task. Q. Do all existing rules need to be deleted for Claude 5? A. No. Fine-grained rules that vary by situation, such as code style or comments, can be replaced with principles for judgment, but constraints concerning security, personal information, permissions, financial transactions, data deletion, and public API contracts should be retained or enforced more strictly through tools and tests. Q. What content is appropriate for CLAUDE.md? A. Persistent, reviewable instructions are appropriate, such as the project's build and test commands, repository structure, areas that must not be changed, and verification procedures agreed upon by the team. If every temporary status update or personalized discovery is stored, the document can quickly become outdated. Q. Can automatic memory replace CLAUDE.md? A. Not completely. Automatic memory is useful for retaining preferences or exploration information discovered during repeated tasks, but instructions that require auditing and version control, such as security policies and public contracts, should be kept in CLAUDE.md or a separate policy layer. Q. What are the characteristics of a good agent tool interface? A. Its purpose should be evident from the tool's name and input schema alone, and required values and allowed states should be clear. Dangerous write operations should require a preview or approval, and errors should return their causes and recovery methods in a structured format. Q. Does progressive disclosure mean hiding information from the model? A. No. It is an approach that initially provides the goal and an exploration path, then allows the model to retrieve the necessary files, specifications, and logs as it refines the task. The purpose is to reduce unnecessary information injected in advance while preserving access to information. Q. How do you evaluate the effect after reducing context? A. For a representative set of tasks, test pass rates, the number of user corrections, unnecessary changes, tool errors, token usage, and safety policy violations should be compared before and after the change. Success should not be judged solely by a reduction in prompt length. Q. Is it acceptable not to provide any tool usage examples? A. Examples are not always unnecessary. Minimal examples are useful when there are edge cases or ambiguous inputs that are difficult to express through the schema alone. However, the priority should be to make the interface itself clear rather than repeatedly listing normal calls. Sources - Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents - Building effective agents: https://www.anthropic.com/engineering/building-effective-agents - Prompt engineering overview: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview - Claude Code memory documentation: https://docs.anthropic.com/en/docs/claude-code/memory Images - Documents and data icons flowing through a funnel into a central AI network: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzMzMywicHVyIjoiYmxvYl9pZCJ9fQ==--b6a9225f1d5837dd6ca93532a1e1a3388a1cc4fc/ai-e5c0c894.webp - AI workflow with a robot moving through search, files, tools, code, validation, and reporting toward a target: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzMzOSwicHVyIjoiYmxvYl9pZCJ9fQ==--c5e1421a425951ca760407e2d7b6c78654f545e5/ai-8b2296c2.webp --- Category: AI Data Source: https://injoys.com/en/articles/claude-5-context-engineering-rules License: cc_by Translation-Status: reviewed