{"content_id":"yihyxok0ch","slug":"claude-5-context-engineering-rules","locale":"en","schema_type":"TechArticle","category":"ai_data","category_name":"AI Data","title":"Context Engineering Rules for Claude 5 Models","summary":"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.","author":{"name":"Injoys Editorial Team","url":"https://injoys.com/ko/about"},"key_points":["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."],"content_markdown":"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.\n\nThe core principle is simple.\n\n\u003e 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.\n\nIn 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.\n\n## Prompt Engineering and Context Engineering\n\n### Prompt Engineering\n\nPrompt engineering is the work of designing how to express the current request. It generally covers the following items.\n\n- Task objective\n- Scope of work\n- Constraints\n- Output format\n- Success criteria\n- Necessary examples\n\nFor example:\n\n```text\nImplement payment cancellation in a Next.js API Route.\nReuse the existing service layer and add tests.\nDo not change the public API contract, and explain the reasons for the changes.\n```\n\n### Context Engineering\n\nContext 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.\n\n```text\nThe user’s current request\n+ System instructions\n+ CLAUDE.md and project instructions\n+ Skills\n+ Automatic memory\n+ Code, specifications, tests, and documentation\n+ Tool definitions and MCP resources\n+ Conversation history\n+ Tool execution results and error logs\n```\n\nTherefore, 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.\n\n| Category | Prompt Engineering | Context Engineering |\n|---|---|---|\n| Design target | Expression of the current request | The entire information environment used in reasoning |\n| Main question | What should be requested, and how? | What should the model see, and when? |\n| Representative elements | Objectives, formats, constraints, examples | System instructions, files, tools, memory, history |\n| Main failures | Ambiguous requests, unclear success criteria | Conflicts, duplication, outdated information, excessive logs |\n| Improvement method | Make requests specific and provide validation criteria | Select high-signal information, retrieve it at the right time, and manage its lifecycle |\n\n## Why More Context Is Not Always Better\n\nEven 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.\n\n1. Important requirements become buried in verbose explanations.\n2. Similar instructions in different locations conflict in subtle ways.\n3. Outdated decisions or failed attempts affect the current task.\n4. Examples act like correct answers and constrain alternative solution paths.\n5. Logs and tool output take up space needed for code, specifications, and tests.\n6. The model spends reasoning effort interpreting instruction priorities rather than performing the actual task.\n\nAnthropic 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.\n\n## What the System Prompt Reduction Case Means\n\nIn 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.\n\nFor example, the following instructions could all appear in a single request.\n\n```text\nSystem instruction: Leave documentation appropriate to the situation.\nSkill instruction: Do not add comments.\nUser request: Make it work like the previous version.\n```\n\nEach sentence may be reasonable on its own, but placing them together creates several interpretation problems.\n\n- Are documentation and code comments in the same category?\n- Is the prohibition on comments a rule without exceptions?\n- Does the behavior of the previous version also include its comments or documentation structure?\n- Which takes priority: the current request or the reusable Skill?\n\nIn 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.\n\n## Six New Rules for Context Design\n\n| Previous Approach | Recommended Approach |\n|---|---|\n| Define detailed behavior through prohibition lists | Provide objectives and judgment criteria, and use context |\n| Provide many examples of tool calls | Design the schema itself to explain how to use the tool |\n| Inject all information at the start of the task | Disclose information progressively when needed |\n| Repeat the same instruction in multiple locations | Assign one authoritative storage location to each instruction |\n| Store even temporary memories in CLAUDE.md | Separate the roles of permanent policies and automatic memory |\n| Rely on long Markdown explanations | Provide executable materials such as code, tests, HTML, and evaluation rubrics |\n\n### 1. Replace Detailed Prohibition Lists with Context-Based Principles\n\nTo prevent repeated mistakes by earlier models, rules were sometimes listed at length as follows.\n\n- Do not write comments.\n- Do not create multi-paragraph docstrings.\n- Do not create planning documents unless requested.\n- Do not save intermediate analysis files.\n\nThese 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.\n\nIt is better to provide judgment criteria like the following.\n\n```text\nWrite code that reads consistently with the surrounding code.\nFollow the naming conventions, idioms, and comment density of existing files.\nAdd only the documentation necessary for logic whose safety or intent would otherwise be unclear.\n```\n\nHowever, not every rule should be weakened. The following items should remain explicit constraints or tool-level controls.\n\n- Approval for production deployments and data deletion\n- Restrictions on processing personal and confidential information\n- Authentication and authorization validation\n- Idempotency and audit records for financial transactions\n- Database migration policies\n- Compliance with laws, licenses, and regulations\n- Immutable public API contracts\n\n| Rule Type | Appropriate Handling |\n|---|---|\n| Security, legal, and authorization | Maintain explicit, strong constraints |\n| Operations that may cause data loss | Control through approval procedures and tool permissions |\n| Public contracts and compatibility | Validate through tests and schemas |\n| Code style and comments | Use judgment principles based on surrounding code |\n| Temporary order of operations | Manage in the current plan or task list |\n\n### 2. Design Expressive Tools Instead of Providing Many Examples\n\nContinuously 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.\n\n```text\nTodoWrite\nPurpose: Create and update the task list for the current session\n\nstatus:\n- pending\n- in_progress\n- completed\n\nConstraint:\n- Only one task may be in_progress at a time\n```\n\nA good agent tool has the following characteristics.\n\n- Its name alone reveals the action and target.\n- Required and optional fields are distinguished.\n- Enums restrict permitted values.\n- Reading and writing, as well as previewing and execution, are separated.\n- Errors return the cause and recovery method in a structured format.\n- Dangerous operations require a confirmation token or approval step.\n- If results are excessively long, the tool provides summaries and pagination.\n\nExamples should be added only to explain exceptions or ambiguous inputs that are difficult to express through the interface.\n\n### 3. Do Not Include All Information from the Start; Disclose It Progressively\n\nYou 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.\n\nThe recommended flow is as follows.\n\n1. Provide the objective, success criteria, and safety boundaries.\n2. Find relevant locations through the repository structure or search tools.\n3. Read only the necessary files and specifications.\n4. After implementation, run relevant tests and static analysis.\n5. If a failure occurs, retrieve only the corresponding error and surrounding code.\n6. After completion, compress or remove outdated logs and intermediate reasoning.\n\nProgressive 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.\n\n### 4. Remove Duplicate Instructions and Establish Authoritative Locations\n\nIf 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.\n\n| Information | Recommended Location |\n|---|---|\n| Organization-wide safety policies | System instructions or permission hierarchy |\n| Repository build and test commands | Project CLAUDE.md |\n| Procedures for a specific task | The corresponding Skill |\n| Tool inputs and constraints | Tool schema and description |\n| Public API behavior | Code schemas, specifications, and contract tests |\n| Current session progress | Task list or session state |\n\nIf duplication is unavoidable, it is safer to point to the authoritative location or generate the content automatically rather than copying it.\n\n### 5. Separate the Roles of CLAUDE.md and Automatic Memory\n\nCLAUDE.md is suitable for persistent instructions that project members can review and manage through version control.\n\n- Standard build and test commands\n- Essential explanations of the repository structure\n- Areas the team has agreed must not be changed\n- Project-specific validation procedures\n- Rules that are difficult to infer using general tools\n\nBy contrast, the following information is more appropriate for automatic memory or session state.\n\n- Personalized preferences discovered through repeated tasks\n- Exploration paths that proved useful in recent tasks\n- Temporary characteristics of the development environment\n- Progress in the current session\n\nAutomatic 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.\n\n### 6. Prioritize Executable Reference Materials over Explanatory Documents\n\nNatural-language specifications are useful for explaining intent, but they may not fully represent actual behavior. When possible, provide the following materials together.\n\n- Existing implementations similar to the current code\n- Unit tests and integration tests\n- API schemas and type definitions\n- Actual HTML or design deliverables\n- Database migration files\n- Example input and output data\n- Evaluation rubrics and automated scoring criteria\n\nConflicts 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.\n\n## Practical Context Configuration Template\n\nThe following structure is an example of organizing the information needed for a coding task concisely.\n\n```text\nObjective\n- Add a payment cancellation API.\n\nSuccess criteria\n- Reuse the existing payment service layer.\n- Cancel only once even when duplicate requests are received.\n- Pass the relevant contract tests.\n\nStrong constraints\n- Do not change the public response schema.\n- Do not access production data.\n\nReference materials\n- src/payments/capture.ts\n- tests/contracts/payment-cancel.test.ts\n- openapi/payments.yaml\n\nJudgment principles\n- Follow the error handling and naming conventions of the surrounding payment code.\n- Ask before implementation if there are unsafe assumptions.\n\nValidation\n- Targeted unit tests\n- Contract tests\n- Type checking\n```\n\nThis format does not attempt to list every situation in advance. Instead, it separates the objective, success conditions, immutable boundaries, authoritative materials, and validation methods.\n\n## Procedure for Cleaning Up Existing Context\n\n### Step 1: Inventory the Sources of All Instructions\n\nReview 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.\n\n### Step 2: Classify Each Instruction\n\n- Required for safety or legal reasons\n- Required by the product contract\n- A persistent team convention\n- An explanation needed only for a specific tool\n- A temporary rule intended to prevent mistakes by earlier models\n- A rule whose basis is currently unclear\n\n### Step 3: Find Duplication and Conflicts\n\nGroup sentences that express the same behavior differently. In particular, review expressions such as `always`, `never`, `must`, and `do not` first.\n\n### Step 4: Move Rules into Tests or Permissions\n\nItems that can be verified more reliably through automation than through natural-language warnings should be moved into the following layers.\n\n- Tests and linters\n- Type systems and schemas\n- Least-privilege tools\n- Approval procedures\n- Sandboxes\n- CI policies\n\n### Step 5: Evaluate with Real Tasks\n\nDo not measure prompt length alone. Compare the following metrics across a representative set of tasks.\n\n- Success rate and test pass rate\n- Number of unnecessary file changes\n- Number of user corrections\n- Tool call failure rate\n- Time and tokens required for completion\n- Whether safety policies were violated\n\n### Step 6: Address Only the Causes of Failure, Minimally\n\nDo 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.\n\n## Instructions That Must Not Be Removed\n\nSimplification 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.\n\n- Would a violation cause data loss or financial harm?\n- Does it relate to legal, privacy, or licensing obligations?\n- Is it an organizational policy that the model cannot infer from the code alone?\n- Does it determine the compatibility of a public API or data format?\n- Is human approval required before executing the task?\n- Is it difficult to fully detect violations through automated tests alone?\n\n## Common Failure Patterns\n\n### Adding a New Rule After Every Failure\n\nIf a single error is generalized into a permanent rule, exceptions and conflicts accumulate. First add an evaluation case and verify whether the failure recurs.\n\n### Using Long Examples as De Facto Templates\n\nIf 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.\n\n### Preserving Entire Logs Unchanged\n\nTool 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.\n\n### Using Automatic Memory as a Policy Repository\n\nAutomatic 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.\n\n### Evaluating Context Reduction as Mere Token Savings\n\nShorter 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.\n\n## Final Checklist\n\n- Are the objective and success criteria of the current request separated?\n- Are safety rules distinguished from style preferences?\n- Is the same instruction duplicated in multiple locations?\n- Does the tool schema explain how to use the tool without long examples?\n- Can relevant files be retrieved when needed?\n- Is there a way to remove outdated memory and execution logs?\n- Can natural-language rules be enforced through tests or permissions?\n- Is the priority among reference materials clear?\n- Are there evaluation tasks for comparing performance before and after instruction changes?\n\n## Conclusion\n\nContext 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.\n\nThe most practical principle can be summarized as follows.\n\n\u003e Enforce security and contracts strongly, leave style to context, provide information when it is needed, and validate results with executable tests.","content_html":"\u003cp\u003eTo 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.\u003c/p\u003e\n\u003cp\u003eThe core principle is simple.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eRather 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.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eIn this article, \u003ccode\u003eClaude 5\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#prompt-engineering-and-context-engineering\" class=\"anchor\" id=\"prompt-engineering-and-context-engineering\"\u003e\u003c/a\u003ePrompt Engineering and Context Engineering\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#prompt-engineering\" class=\"anchor\" id=\"prompt-engineering\"\u003e\u003c/a\u003ePrompt Engineering\u003c/h3\u003e\n\u003cp\u003ePrompt engineering is the work of designing how to express the current request. It generally covers the following items.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eTask objective\u003c/li\u003e\n\u003cli\u003eScope of work\u003c/li\u003e\n\u003cli\u003eConstraints\u003c/li\u003e\n\u003cli\u003eOutput format\u003c/li\u003e\n\u003cli\u003eSuccess criteria\u003c/li\u003e\n\u003cli\u003eNecessary examples\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eFor example:\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eImplement payment cancellation in a Next.js API Route.\n\u003c/span\u003e\u003cspan\u003eReuse the existing service layer and add tests.\n\u003c/span\u003e\u003cspan\u003eDo not change the public API contract, and explain the reasons for the changes.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003ch3\u003e\n\u003ca href=\"#context-engineering\" class=\"anchor\" id=\"context-engineering\"\u003e\u003c/a\u003eContext Engineering\u003c/h3\u003e\n\u003cp\u003eContext 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.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eThe user’s current request\n\u003c/span\u003e\u003cspan\u003e+ System instructions\n\u003c/span\u003e\u003cspan\u003e+ CLAUDE.md and project instructions\n\u003c/span\u003e\u003cspan\u003e+ Skills\n\u003c/span\u003e\u003cspan\u003e+ Automatic memory\n\u003c/span\u003e\u003cspan\u003e+ Code, specifications, tests, and documentation\n\u003c/span\u003e\u003cspan\u003e+ Tool definitions and MCP resources\n\u003c/span\u003e\u003cspan\u003e+ Conversation history\n\u003c/span\u003e\u003cspan\u003e+ Tool execution results and error logs\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eTherefore, 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eCategory\u003c/th\u003e\n\u003cth\u003ePrompt Engineering\u003c/th\u003e\n\u003cth\u003eContext Engineering\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Category\"\u003eDesign target\u003c/td\u003e\n\u003ctd data-label=\"Prompt Engineering\"\u003eExpression of the current request\u003c/td\u003e\n\u003ctd data-label=\"Context Engineering\"\u003eThe entire information environment used in reasoning\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Category\"\u003eMain question\u003c/td\u003e\n\u003ctd data-label=\"Prompt Engineering\"\u003eWhat should be requested, and how?\u003c/td\u003e\n\u003ctd data-label=\"Context Engineering\"\u003eWhat should the model see, and when?\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Category\"\u003eRepresentative elements\u003c/td\u003e\n\u003ctd data-label=\"Prompt Engineering\"\u003eObjectives, formats, constraints, examples\u003c/td\u003e\n\u003ctd data-label=\"Context Engineering\"\u003eSystem instructions, files, tools, memory, history\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Category\"\u003eMain failures\u003c/td\u003e\n\u003ctd data-label=\"Prompt Engineering\"\u003eAmbiguous requests, unclear success criteria\u003c/td\u003e\n\u003ctd data-label=\"Context Engineering\"\u003eConflicts, duplication, outdated information, excessive logs\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Category\"\u003eImprovement method\u003c/td\u003e\n\u003ctd data-label=\"Prompt Engineering\"\u003eMake requests specific and provide validation criteria\u003c/td\u003e\n\u003ctd data-label=\"Context Engineering\"\u003eSelect high-signal information, retrieve it at the right time, and manage its lifecycle\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#why-more-context-is-not-always-better\" class=\"anchor\" id=\"why-more-context-is-not-always-better\"\u003e\u003c/a\u003eWhy More Context Is Not Always Better\u003c/h2\u003e\n\u003cp\u003eEven 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.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eImportant requirements become buried in verbose explanations.\u003c/li\u003e\n\u003cli\u003eSimilar instructions in different locations conflict in subtle ways.\u003c/li\u003e\n\u003cli\u003eOutdated decisions or failed attempts affect the current task.\u003c/li\u003e\n\u003cli\u003eExamples act like correct answers and constrain alternative solution paths.\u003c/li\u003e\n\u003cli\u003eLogs and tool output take up space needed for code, specifications, and tests.\u003c/li\u003e\n\u003cli\u003eThe model spends reasoning effort interpreting instruction priorities rather than performing the actual task.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eAnthropic 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#what-the-system-prompt-reduction-case-means\" class=\"anchor\" id=\"what-the-system-prompt-reduction-case-means\"\u003e\u003c/a\u003eWhat the System Prompt Reduction Case Means\u003c/h2\u003e\n\u003cp\u003eIn 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.\u003c/p\u003e\n\u003cp\u003eFor example, the following instructions could all appear in a single request.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eSystem instruction: Leave documentation appropriate to the situation.\n\u003c/span\u003e\u003cspan\u003eSkill instruction: Do not add comments.\n\u003c/span\u003e\u003cspan\u003eUser request: Make it work like the previous version.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eEach sentence may be reasonable on its own, but placing them together creates several interpretation problems.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAre documentation and code comments in the same category?\u003c/li\u003e\n\u003cli\u003eIs the prohibition on comments a rule without exceptions?\u003c/li\u003e\n\u003cli\u003eDoes the behavior of the previous version also include its comments or documentation structure?\u003c/li\u003e\n\u003cli\u003eWhich takes priority: the current request or the reusable Skill?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIn 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#six-new-rules-for-context-design\" class=\"anchor\" id=\"six-new-rules-for-context-design\"\u003e\u003c/a\u003eSix New Rules for Context Design\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003ePrevious Approach\u003c/th\u003e\n\u003cth\u003eRecommended Approach\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Previous Approach\"\u003eDefine detailed behavior through prohibition lists\u003c/td\u003e\n\u003ctd data-label=\"Recommended Approach\"\u003eProvide objectives and judgment criteria, and use context\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Previous Approach\"\u003eProvide many examples of tool calls\u003c/td\u003e\n\u003ctd data-label=\"Recommended Approach\"\u003eDesign the schema itself to explain how to use the tool\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Previous Approach\"\u003eInject all information at the start of the task\u003c/td\u003e\n\u003ctd data-label=\"Recommended Approach\"\u003eDisclose information progressively when needed\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Previous Approach\"\u003eRepeat the same instruction in multiple locations\u003c/td\u003e\n\u003ctd data-label=\"Recommended Approach\"\u003eAssign one authoritative storage location to each instruction\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Previous Approach\"\u003eStore even temporary memories in CLAUDE.md\u003c/td\u003e\n\u003ctd data-label=\"Recommended Approach\"\u003eSeparate the roles of permanent policies and automatic memory\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Previous Approach\"\u003eRely on long Markdown explanations\u003c/td\u003e\n\u003ctd data-label=\"Recommended Approach\"\u003eProvide executable materials such as code, tests, HTML, and evaluation rubrics\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#1-replace-detailed-prohibition-lists-with-context-based-principles\" class=\"anchor\" id=\"1-replace-detailed-prohibition-lists-with-context-based-principles\"\u003e\u003c/a\u003e1. Replace Detailed Prohibition Lists with Context-Based Principles\u003c/h3\u003e\n\u003cp\u003eTo prevent repeated mistakes by earlier models, rules were sometimes listed at length as follows.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eDo not write comments.\u003c/li\u003e\n\u003cli\u003eDo not create multi-paragraph docstrings.\u003c/li\u003e\n\u003cli\u003eDo not create planning documents unless requested.\u003c/li\u003e\n\u003cli\u003eDo not save intermediate analysis files.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThese 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.\u003c/p\u003e\n\u003cp\u003eIt is better to provide judgment criteria like the following.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eWrite code that reads consistently with the surrounding code.\n\u003c/span\u003e\u003cspan\u003eFollow the naming conventions, idioms, and comment density of existing files.\n\u003c/span\u003e\u003cspan\u003eAdd only the documentation necessary for logic whose safety or intent would otherwise be unclear.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eHowever, not every rule should be weakened. The following items should remain explicit constraints or tool-level controls.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eApproval for production deployments and data deletion\u003c/li\u003e\n\u003cli\u003eRestrictions on processing personal and confidential information\u003c/li\u003e\n\u003cli\u003eAuthentication and authorization validation\u003c/li\u003e\n\u003cli\u003eIdempotency and audit records for financial transactions\u003c/li\u003e\n\u003cli\u003eDatabase migration policies\u003c/li\u003e\n\u003cli\u003eCompliance with laws, licenses, and regulations\u003c/li\u003e\n\u003cli\u003eImmutable public API contracts\u003c/li\u003e\n\u003c/ul\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eRule Type\u003c/th\u003e\n\u003cth\u003eAppropriate Handling\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Rule Type\"\u003eSecurity, legal, and authorization\u003c/td\u003e\n\u003ctd data-label=\"Appropriate Handling\"\u003eMaintain explicit, strong constraints\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Rule Type\"\u003eOperations that may cause data loss\u003c/td\u003e\n\u003ctd data-label=\"Appropriate Handling\"\u003eControl through approval procedures and tool permissions\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Rule Type\"\u003ePublic contracts and compatibility\u003c/td\u003e\n\u003ctd data-label=\"Appropriate Handling\"\u003eValidate through tests and schemas\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Rule Type\"\u003eCode style and comments\u003c/td\u003e\n\u003ctd data-label=\"Appropriate Handling\"\u003eUse judgment principles based on surrounding code\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Rule Type\"\u003eTemporary order of operations\u003c/td\u003e\n\u003ctd data-label=\"Appropriate Handling\"\u003eManage in the current plan or task list\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#2-design-expressive-tools-instead-of-providing-many-examples\" class=\"anchor\" id=\"2-design-expressive-tools-instead-of-providing-many-examples\"\u003e\u003c/a\u003e2. Design Expressive Tools Instead of Providing Many Examples\u003c/h3\u003e\n\u003cp\u003eContinuously 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.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTodoWrite\n\u003c/span\u003e\u003cspan\u003ePurpose: Create and update the task list for the current session\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003estatus:\n\u003c/span\u003e\u003cspan\u003e- pending\n\u003c/span\u003e\u003cspan\u003e- in_progress\n\u003c/span\u003e\u003cspan\u003e- completed\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eConstraint:\n\u003c/span\u003e\u003cspan\u003e- Only one task may be in_progress at a time\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eA good agent tool has the following characteristics.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eIts name alone reveals the action and target.\u003c/li\u003e\n\u003cli\u003eRequired and optional fields are distinguished.\u003c/li\u003e\n\u003cli\u003eEnums restrict permitted values.\u003c/li\u003e\n\u003cli\u003eReading and writing, as well as previewing and execution, are separated.\u003c/li\u003e\n\u003cli\u003eErrors return the cause and recovery method in a structured format.\u003c/li\u003e\n\u003cli\u003eDangerous operations require a confirmation token or approval step.\u003c/li\u003e\n\u003cli\u003eIf results are excessively long, the tool provides summaries and pagination.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eExamples should be added only to explain exceptions or ambiguous inputs that are difficult to express through the interface.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#3-do-not-include-all-information-from-the-start-disclose-it-progressively\" class=\"anchor\" id=\"3-do-not-include-all-information-from-the-start-disclose-it-progressively\"\u003e\u003c/a\u003e3. Do Not Include All Information from the Start; Disclose It Progressively\u003c/h3\u003e\n\u003cp\u003eYou 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.\u003c/p\u003e\n\u003cp\u003eThe recommended flow is as follows.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eProvide the objective, success criteria, and safety boundaries.\u003c/li\u003e\n\u003cli\u003eFind relevant locations through the repository structure or search tools.\u003c/li\u003e\n\u003cli\u003eRead only the necessary files and specifications.\u003c/li\u003e\n\u003cli\u003eAfter implementation, run relevant tests and static analysis.\u003c/li\u003e\n\u003cli\u003eIf a failure occurs, retrieve only the corresponding error and surrounding code.\u003c/li\u003e\n\u003cli\u003eAfter completion, compress or remove outdated logs and intermediate reasoning.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eProgressive 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#4-remove-duplicate-instructions-and-establish-authoritative-locations\" class=\"anchor\" id=\"4-remove-duplicate-instructions-and-establish-authoritative-locations\"\u003e\u003c/a\u003e4. Remove Duplicate Instructions and Establish Authoritative Locations\u003c/h3\u003e\n\u003cp\u003eIf 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.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eInformation\u003c/th\u003e\n\u003cth\u003eRecommended Location\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Information\"\u003eOrganization-wide safety policies\u003c/td\u003e\n\u003ctd data-label=\"Recommended Location\"\u003eSystem instructions or permission hierarchy\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Information\"\u003eRepository build and test commands\u003c/td\u003e\n\u003ctd data-label=\"Recommended Location\"\u003eProject CLAUDE.md\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Information\"\u003eProcedures for a specific task\u003c/td\u003e\n\u003ctd data-label=\"Recommended Location\"\u003eThe corresponding Skill\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Information\"\u003eTool inputs and constraints\u003c/td\u003e\n\u003ctd data-label=\"Recommended Location\"\u003eTool schema and description\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Information\"\u003ePublic API behavior\u003c/td\u003e\n\u003ctd data-label=\"Recommended Location\"\u003eCode schemas, specifications, and contract tests\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Information\"\u003eCurrent session progress\u003c/td\u003e\n\u003ctd data-label=\"Recommended Location\"\u003eTask list or session state\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eIf duplication is unavoidable, it is safer to point to the authoritative location or generate the content automatically rather than copying it.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#5-separate-the-roles-of-claudemd-and-automatic-memory\" class=\"anchor\" id=\"5-separate-the-roles-of-claudemd-and-automatic-memory\"\u003e\u003c/a\u003e5. Separate the Roles of CLAUDE.md and Automatic Memory\u003c/h3\u003e\n\u003cp\u003eCLAUDE.md is suitable for persistent instructions that project members can review and manage through version control.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eStandard build and test commands\u003c/li\u003e\n\u003cli\u003eEssential explanations of the repository structure\u003c/li\u003e\n\u003cli\u003eAreas the team has agreed must not be changed\u003c/li\u003e\n\u003cli\u003eProject-specific validation procedures\u003c/li\u003e\n\u003cli\u003eRules that are difficult to infer using general tools\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBy contrast, the following information is more appropriate for automatic memory or session state.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePersonalized preferences discovered through repeated tasks\u003c/li\u003e\n\u003cli\u003eExploration paths that proved useful in recent tasks\u003c/li\u003e\n\u003cli\u003eTemporary characteristics of the development environment\u003c/li\u003e\n\u003cli\u003eProgress in the current session\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eAutomatic 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#6-prioritize-executable-reference-materials-over-explanatory-documents\" class=\"anchor\" id=\"6-prioritize-executable-reference-materials-over-explanatory-documents\"\u003e\u003c/a\u003e6. Prioritize Executable Reference Materials over Explanatory Documents\u003c/h3\u003e\n\u003cp\u003eNatural-language specifications are useful for explaining intent, but they may not fully represent actual behavior. When possible, provide the following materials together.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eExisting implementations similar to the current code\u003c/li\u003e\n\u003cli\u003eUnit tests and integration tests\u003c/li\u003e\n\u003cli\u003eAPI schemas and type definitions\u003c/li\u003e\n\u003cli\u003eActual HTML or design deliverables\u003c/li\u003e\n\u003cli\u003eDatabase migration files\u003c/li\u003e\n\u003cli\u003eExample input and output data\u003c/li\u003e\n\u003cli\u003eEvaluation rubrics and automated scoring criteria\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eConflicts 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#practical-context-configuration-template\" class=\"anchor\" id=\"practical-context-configuration-template\"\u003e\u003c/a\u003ePractical Context Configuration Template\u003c/h2\u003e\n\u003cp\u003eThe following structure is an example of organizing the information needed for a coding task concisely.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eObjective\n\u003c/span\u003e\u003cspan\u003e- Add a payment cancellation API.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eSuccess criteria\n\u003c/span\u003e\u003cspan\u003e- Reuse the existing payment service layer.\n\u003c/span\u003e\u003cspan\u003e- Cancel only once even when duplicate requests are received.\n\u003c/span\u003e\u003cspan\u003e- Pass the relevant contract tests.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eStrong constraints\n\u003c/span\u003e\u003cspan\u003e- Do not change the public response schema.\n\u003c/span\u003e\u003cspan\u003e- Do not access production data.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eReference materials\n\u003c/span\u003e\u003cspan\u003e- src/payments/capture.ts\n\u003c/span\u003e\u003cspan\u003e- tests/contracts/payment-cancel.test.ts\n\u003c/span\u003e\u003cspan\u003e- openapi/payments.yaml\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eJudgment principles\n\u003c/span\u003e\u003cspan\u003e- Follow the error handling and naming conventions of the surrounding payment code.\n\u003c/span\u003e\u003cspan\u003e- Ask before implementation if there are unsafe assumptions.\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eValidation\n\u003c/span\u003e\u003cspan\u003e- Targeted unit tests\n\u003c/span\u003e\u003cspan\u003e- Contract tests\n\u003c/span\u003e\u003cspan\u003e- Type checking\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eThis format does not attempt to list every situation in advance. Instead, it separates the objective, success conditions, immutable boundaries, authoritative materials, and validation methods.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#procedure-for-cleaning-up-existing-context\" class=\"anchor\" id=\"procedure-for-cleaning-up-existing-context\"\u003e\u003c/a\u003eProcedure for Cleaning Up Existing Context\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-1-inventory-the-sources-of-all-instructions\" class=\"anchor\" id=\"step-1-inventory-the-sources-of-all-instructions\"\u003e\u003c/a\u003eStep 1: Inventory the Sources of All Instructions\u003c/h3\u003e\n\u003cp\u003eReview 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-2-classify-each-instruction\" class=\"anchor\" id=\"step-2-classify-each-instruction\"\u003e\u003c/a\u003eStep 2: Classify Each Instruction\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003eRequired for safety or legal reasons\u003c/li\u003e\n\u003cli\u003eRequired by the product contract\u003c/li\u003e\n\u003cli\u003eA persistent team convention\u003c/li\u003e\n\u003cli\u003eAn explanation needed only for a specific tool\u003c/li\u003e\n\u003cli\u003eA temporary rule intended to prevent mistakes by earlier models\u003c/li\u003e\n\u003cli\u003eA rule whose basis is currently unclear\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-3-find-duplication-and-conflicts\" class=\"anchor\" id=\"step-3-find-duplication-and-conflicts\"\u003e\u003c/a\u003eStep 3: Find Duplication and Conflicts\u003c/h3\u003e\n\u003cp\u003eGroup sentences that express the same behavior differently. In particular, review expressions such as \u003ccode\u003ealways\u003c/code\u003e, \u003ccode\u003enever\u003c/code\u003e, \u003ccode\u003emust\u003c/code\u003e, and \u003ccode\u003edo not\u003c/code\u003e first.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-4-move-rules-into-tests-or-permissions\" class=\"anchor\" id=\"step-4-move-rules-into-tests-or-permissions\"\u003e\u003c/a\u003eStep 4: Move Rules into Tests or Permissions\u003c/h3\u003e\n\u003cp\u003eItems that can be verified more reliably through automation than through natural-language warnings should be moved into the following layers.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eTests and linters\u003c/li\u003e\n\u003cli\u003eType systems and schemas\u003c/li\u003e\n\u003cli\u003eLeast-privilege tools\u003c/li\u003e\n\u003cli\u003eApproval procedures\u003c/li\u003e\n\u003cli\u003eSandboxes\u003c/li\u003e\n\u003cli\u003eCI policies\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-5-evaluate-with-real-tasks\" class=\"anchor\" id=\"step-5-evaluate-with-real-tasks\"\u003e\u003c/a\u003eStep 5: Evaluate with Real Tasks\u003c/h3\u003e\n\u003cp\u003eDo not measure prompt length alone. Compare the following metrics across a representative set of tasks.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eSuccess rate and test pass rate\u003c/li\u003e\n\u003cli\u003eNumber of unnecessary file changes\u003c/li\u003e\n\u003cli\u003eNumber of user corrections\u003c/li\u003e\n\u003cli\u003eTool call failure rate\u003c/li\u003e\n\u003cli\u003eTime and tokens required for completion\u003c/li\u003e\n\u003cli\u003eWhether safety policies were violated\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#step-6-address-only-the-causes-of-failure-minimally\" class=\"anchor\" id=\"step-6-address-only-the-causes-of-failure-minimally\"\u003e\u003c/a\u003eStep 6: Address Only the Causes of Failure, Minimally\u003c/h3\u003e\n\u003cp\u003eDo 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#instructions-that-must-not-be-removed\" class=\"anchor\" id=\"instructions-that-must-not-be-removed\"\u003e\u003c/a\u003eInstructions That Must Not Be Removed\u003c/h2\u003e\n\u003cp\u003eSimplification does not mean unconditional deletion. If the answer to any of the following questions is \u003ccode\u003eyes\u003c/code\u003e, the instruction should be retained or moved to a stronger control.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWould a violation cause data loss or financial harm?\u003c/li\u003e\n\u003cli\u003eDoes it relate to legal, privacy, or licensing obligations?\u003c/li\u003e\n\u003cli\u003eIs it an organizational policy that the model cannot infer from the code alone?\u003c/li\u003e\n\u003cli\u003eDoes it determine the compatibility of a public API or data format?\u003c/li\u003e\n\u003cli\u003eIs human approval required before executing the task?\u003c/li\u003e\n\u003cli\u003eIs it difficult to fully detect violations through automated tests alone?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#common-failure-patterns\" class=\"anchor\" id=\"common-failure-patterns\"\u003e\u003c/a\u003eCommon Failure Patterns\u003c/h2\u003e\n\u003ch3\u003e\n\u003ca href=\"#adding-a-new-rule-after-every-failure\" class=\"anchor\" id=\"adding-a-new-rule-after-every-failure\"\u003e\u003c/a\u003eAdding a New Rule After Every Failure\u003c/h3\u003e\n\u003cp\u003eIf a single error is generalized into a permanent rule, exceptions and conflicts accumulate. First add an evaluation case and verify whether the failure recurs.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#using-long-examples-as-de-facto-templates\" class=\"anchor\" id=\"using-long-examples-as-de-facto-templates\"\u003e\u003c/a\u003eUsing Long Examples as De Facto Templates\u003c/h3\u003e\n\u003cp\u003eIf 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#preserving-entire-logs-unchanged\" class=\"anchor\" id=\"preserving-entire-logs-unchanged\"\u003e\u003c/a\u003ePreserving Entire Logs Unchanged\u003c/h3\u003e\n\u003cp\u003eTool 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#using-automatic-memory-as-a-policy-repository\" class=\"anchor\" id=\"using-automatic-memory-as-a-policy-repository\"\u003e\u003c/a\u003eUsing Automatic Memory as a Policy Repository\u003c/h3\u003e\n\u003cp\u003eAutomatic 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.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#evaluating-context-reduction-as-mere-token-savings\" class=\"anchor\" id=\"evaluating-context-reduction-as-mere-token-savings\"\u003e\u003c/a\u003eEvaluating Context Reduction as Mere Token Savings\u003c/h3\u003e\n\u003cp\u003eShorter 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.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#final-checklist\" class=\"anchor\" id=\"final-checklist\"\u003e\u003c/a\u003eFinal Checklist\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eAre the objective and success criteria of the current request separated?\u003c/li\u003e\n\u003cli\u003eAre safety rules distinguished from style preferences?\u003c/li\u003e\n\u003cli\u003eIs the same instruction duplicated in multiple locations?\u003c/li\u003e\n\u003cli\u003eDoes the tool schema explain how to use the tool without long examples?\u003c/li\u003e\n\u003cli\u003eCan relevant files be retrieved when needed?\u003c/li\u003e\n\u003cli\u003eIs there a way to remove outdated memory and execution logs?\u003c/li\u003e\n\u003cli\u003eCan natural-language rules be enforced through tests or permissions?\u003c/li\u003e\n\u003cli\u003eIs the priority among reference materials clear?\u003c/li\u003e\n\u003cli\u003eAre there evaluation tasks for comparing performance before and after instruction changes?\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2\u003e\n\u003ca href=\"#conclusion\" class=\"anchor\" id=\"conclusion\"\u003e\u003c/a\u003eConclusion\u003c/h2\u003e\n\u003cp\u003eContext 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.\u003c/p\u003e\n\u003cp\u003eThe most practical principle can be summarized as follows.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eEnforce security and contracts strongly, leave style to context, provide information when it is needed, and validate results with executable tests.\u003c/p\u003e\n\u003c/blockquote\u003e\n","tags":["Prompt Engineering","Context Engineering","AI Agents","Claude Code","Claude"],"faqs":[{"question":"How do prompt engineering and context engineering differ?","answer":"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."},{"question":"Does a longer context always improve model performance?","answer":"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."},{"question":"Do all existing rules need to be deleted for Claude 5?","answer":"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."},{"question":"What content is appropriate for CLAUDE.md?","answer":"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."},{"question":"Can automatic memory replace CLAUDE.md?","answer":"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."},{"question":"What are the characteristics of a good agent tool interface?","answer":"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."},{"question":"Does progressive disclosure mean hiding information from the model?","answer":"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."},{"question":"How do you evaluate the effect after reducing context?","answer":"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."},{"question":"Is it acceptable not to provide any tool usage examples?","answer":"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":[{"url":"https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents","title":"Effective context engineering for AI agents","type":"source"},{"url":"https://www.anthropic.com/engineering/building-effective-agents","title":"Building effective agents","type":"source"},{"url":"https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview","title":"Prompt engineering overview","type":"source"},{"url":"https://docs.anthropic.com/en/docs/claude-code/memory","title":"Claude Code memory documentation","type":"source"}],"images":[{"id":303,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzMzMywicHVyIjoiYmxvYl9pZCJ9fQ==--b6a9225f1d5837dd6ca93532a1e1a3388a1cc4fc/ai-e5c0c894.webp","is_representative":true,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"문서와 데이터 아이콘이 깔때기를 거쳐 중앙 AI 네트워크로 모이는 일러스트","caption":"다양한 컨텍스트가 선별·구조화되어 AI 모델에 연결되는 과정을 표현한다.","description":null},"en":{"alt":"Documents and data icons flowing through a funnel into a central AI network","caption":"The illustration shows varied context being filtered and structured for an AI model.","description":null},"ja":{"alt":"文書やデータのアイコンが漏斗を通って中央のAIネットワークに集まる図","caption":"多様なコンテキストを選別・構造化してAIモデルにつなぐ流れを表している。","description":null},"es":{"alt":"Iconos de documentos y datos pasan por un embudo hacia una red de IA central","caption":"La ilustración representa cómo se filtra y estructura el contexto para un modelo de IA.","description":null},"id":{"alt":"Ikon dokumen dan data mengalir melalui corong menuju jaringan AI pusat","caption":"Ilustrasi ini menunjukkan konteks yang disaring dan disusun untuk model AI.","description":null},"pt":{"alt":"Ícones de documentos e dados passam por um funil até uma rede central de IA","caption":"A ilustração mostra diferentes contextos sendo filtrados e estruturados para um modelo de IA.","description":null},"zh-hant":{"alt":"文件與資料圖示經漏斗匯入中央AI網路","caption":"插圖呈現多種脈絡經篩選與結構化後連接至AI模型的流程。","description":null}}},{"id":304,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzMzOSwicHVyIjoiYmxvYl9pZCJ9fQ==--c5e1421a425951ca760407e2d7b6c78654f545e5/ai-8b2296c2.webp","is_representative":false,"generation_method":"ai_image","license":"ai_generated","mime_type":"image/webp","translations":{"ko":{"alt":"로봇이 검색, 파일, 도구, 코드, 검증, 보고서 단계를 거쳐 목표로 향하는 AI 워크플로","caption":"보안 경계 안에서 컨텍스트와 도구를 단계별로 처리하는 AI 워크플로를 보여준다.","description":null},"en":{"alt":"AI workflow with a robot moving through search, files, tools, code, validation, and reporting toward a target","caption":"The diagram shows an AI processing context and tools step by step within a secure boundary.","description":null},"ja":{"alt":"ロボットが検索、ファイル、ツール、コード、検証、レポートを経て目標へ進むAIワークフロー","caption":"安全な境界内でコンテキストとツールを段階的に処理するAIワークフローを示している。","description":null},"es":{"alt":"Flujo de IA con un robot que pasa por búsqueda, archivos, herramientas, código, validación e informes","caption":"El diagrama muestra una IA que procesa contexto y herramientas por etapas dentro de un entorno seguro.","description":null},"id":{"alt":"Alur kerja AI dengan robot melalui pencarian, berkas, alat, kode, validasi, dan laporan menuju sasaran","caption":"Diagram ini menunjukkan AI yang memproses konteks dan alat secara bertahap dalam batas aman.","description":null},"pt":{"alt":"Fluxo de IA com robô passando por busca, arquivos, ferramentas, código, validação e relatório até o alvo","caption":"O diagrama mostra uma IA processando contexto e ferramentas em etapas dentro de um limite seguro.","description":null},"zh-hant":{"alt":"機器人依序經過搜尋、檔案、工具、程式碼、驗證與報告並朝目標前進的 AI 工作流程","caption":"圖中呈現 AI 在安全邊界內分階段處理情境資訊與工具的工作流程。","description":null}}}],"published_at":"2026-07-27T05:12:07+09:00","updated_at":"2026-07-27T05:12:07+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant"],"url":"https://injoys.com/en/articles/claude-5-context-engineering-rules"}