Claude Instruction Scopes, Content Boundaries and Schema Design

1.Where Claude Code gets its standing instructions

When you build on Claude Code, the text you type in a turn is only part of what Claude reads. Every session also loads persistent context from two places. The first is CLAUDE.md files, which you write. The second is auto memory, which Claude writes itself from your corrections. So the first design question is not what to say. It is where to put it, because the location decides who receives the instruction.

Local instructions are for personal, project-specific details such as sandbox URLs or preferred test data. You add the file to .gitignore so it never reaches teammates. Auto memory is different in two ways: Claude writes it, and it is scoped per repository and shared across worktrees. Only its first 200 lines or 25KB load into each session. Whatever the scope, write concrete instructions. The docs contrast "Use 2-space indentation" with "Format code properly", and "Run npm test before committing" with "Test your changes".

Sources1

2.AGENTS.md and path-scoped rules

Many repositories already have an AGENTS.md. Claude Code can read it, but by default it treats AGENTS.md as a fallback, not an addition. If a CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md exists in your working directory or any directory above it, Claude reads the CLAUDE.md files and skips AGENTS.md. A CLAUDE.md that imports AGENTS.md pulls it in through the import. Three files never count against AGENTS.md: your user file, the managed file, and rules files.

It reads their CLAUDE.md files only, because CLAUDE.local.md counts as one of them. To load both, set the instructionFiles option to claude-md-and-agents-md. Each directory's CLAUDE.md files then load first and its AGENTS.md after them. Other values are claude-md (never AGENTS.md) and managed-only. Some files are never read at all: AGENTS.local.md, AGENTS.override.md, and anything under a .agents/ directory. Subagents that skip project instructions also skip AGENTS.md.

To keep instructions from spreading into unrelated work, use .claude/rules/. A rule file can carry a paths field of glob patterns, so it applies only to matching files:

---
paths:
  - "src/api/**/*.ts"
---

# API Development Rules

- All API endpoints must include input validation
- Use the standard error response format
- Include OpenAPI documentation comments

Sources1

3.Content boundaries: guidance versus enforcement

A CLAUDE.md tells Claude how to behave. It is not a lock. When an organisation needs a boundary that holds, such as a tool Claude may not use or an isolated sandbox, the docs send that concern to managed settings, not to the managed CLAUDE.md.

Boundaries also work in the other direction: they can keep instructions out. In a monorepo, claudeMdExcludes takes glob patterns, such as another team's CLAUDE.md or its .claude/rules/ folder, so their conventions don't load into your sessions.

Sources1

4.Schema design with structured outputs

An application that parses Claude's output needs output it can trust. Prompting alone can still produce invalid JSON, missing required fields or inconsistent types. Structured outputs address this with constrained decoding, and they come as two features you can use separately or together in one request. JSON outputs, set with output_config.format, shape the response. Strict tool use, set with strict: true, validates tool names and inputs.

    output_config={
        "format": {
            "type": "json_schema",
            "schema": {
                "type": "object",
                "properties": {
                    "name": {"type": "string"},
                    "email": {"type": "string"},
                    "plan_interest": {"type": "string"},
                    "demo_requested": {"type": "boolean"},
                },
                "required": ["name", "email", "plan_interest", "demo_requested"],
                "additionalProperties": False,
            },
        }
    },

The response comes back as valid JSON in the text content block. You don't have to write raw schemas by hand. In Python, client.messages.parse() takes a Pydantic model and returns parsed_output. In TypeScript, zodOutputFormat() does the same job for Zod schemas. The API supports only part of JSON Schema, so the Python, TypeScript, Ruby and PHP SDKs rewrite your schema before sending it. They remove unsupported constraints such as minimum, maxLength and similar, and restate each one in the field's description. They also add additionalProperties: false to every object and drop string formats the API doesn't support. Then they validate the response against your original schema. A Pydantic field with minimum: 100 reaches Claude as a plain integer whose description says "Must be at least 100".

Sources2

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Adding "never run rm -rf" to the managed CLAUDE.md reliably blocks that command for everyone in the organisation.Why is that wrong?

   The managed CLAUDE.md carries behavioural guidance. Blocking tools, commands or file paths is a managed-settings concern, configured with permissions.deny.

   Covered in Content boundaries: guidance versus enforcement

2. 2.Claude Code always loads AGENTS.md next to any CLAUDE.md in the repository.Why is that wrong?

   By default, AGENTS.md loads only when there is no CLAUDE.md, .claude/CLAUDE.md or CLAUDE.local.md in the working directory or above it. To load both, set instructionFiles to claude-md-and-agents-md.

   Covered in AGENTS.md and path-scoped rules

3. 3.Constraints such as minimum or maxLength in a Pydantic model are enforced by constrained decoding, so the SDK doesn't need to check them.Why is that wrong?

   The SDK removes unsupported constraints before sending the schema and restates them in the field descriptions. It then validates the response against the original schema, so the enforcement happens in your code.

   Covered in Schema design with structured outputs