Claude Code Rules: Local Guidance Without the Chaos

Documentation snapshot: 10 October 2026

The root instruction file does not have to hold every rule for every part of the repository. Whoever changes the data schema needs to see the migrations contract; someone editing interface copy does not need to reread it every time. In Claude Code, you can organise this with the .claude/rules/ directory and, where needed, restrict an individual rule to the files it describes.

A path-scoped rule is not a permissions filter, though. If a text is loaded only for db/migrations/, that means it is passed into the context while the agent works with the matching files. It does not guarantee that the agent cannot connect to the database through some other tool. The reverse is also true: denying a call in the access settings does not tell the team how to prepare a safe migration. These mechanisms have to be designed and verified separately.

This unit describes the current behaviour of Claude Code specifically. Other Anthropic products, including the ordinary chat, may read files in different ways. The official pages were checked on 10 October 2026, and the documentation may change. On that date, the releases page showed v2.1.296, released on 9 October. This is a snapshot in time, so before relying on it in practice, check the client you have installed and its documentation.

What a rule is and why you need one

In this unit, a rule is a Markdown file of guidance that Claude Code adds to the context either unconditionally or once a file path matches. A team might use one for a migrations convention, for validating responses from an Application Programming Interface (API), for user-interface accessibility, for documentation formatting, or for classifying imported data.

A rule earns its place if it answers several questions:

• What work does it belong to: the whole repository, a particular domain, a directory, or a file type?
• What behaviour exactly is expected, and how does that differ from a stylistic preference?
• What reason or contract should be known before making a change?
• Where does the full primary source live: a technical description, a decision record, a specification, or a process guide?
• How can the result be checked, and what should happen if the data or requirements contradict each other?

The phrase "write reliable code" defines no scope, no action and no criterion. The instruction "for files in db/migrations/**, do not rewrite a historical file after it has been applied to a shared environment; prepare a new change and check it against docs/data-retention.md" has a checkable place of application, an action and a reference to a contract. It is still text for the agent, not a blocking mechanism.

According to the current Claude Code documentation, project rules are stored in .claude/rules/ as Markdown files with the .md extension. The directory sits in the repository, so its contents can be shared through Git. Personal rules can be kept in ~/.claude/rules/; they apply across all of that user's projects. Subdirectories inside .claude/rules/ help organise topics, but on their own they do not limit which files activate a text. For that you need a supported paths pattern in the file's header.

Loading: from file location to context

Claude Code recursively finds Markdown files under the project's .claude/rules/. A rule without paths is loaded at the start of the session, just like ./.claude/CLAUDE.md. This also applies to a rule in a nested subdirectory of .claude/rules/: moving it into frontend/ organises the tree, but does not automatically make it a frontend-only rule.

A rule with paths has a conditional scope: it is added when Claude Code reads a file whose path matches one of the patterns. The documentation explicitly distinguishes this from "every tool call". If an agent working on an interface design request has not yet read any file, the relevant path-scoped rule may not be in the context yet. A path merely being mentioned in the user's message is not enough to conclude that the rule was loaded.

This has a practical consequence for how a task is prepared. If an important rule concerns migration code, the agent has to read a specific migration file or some other matching path. The text of the rule is no substitute for loading it. To confirm a diagnosis, record the visible file path, the current working directory, the product and its version; then check what Claude Code reports as loaded.

The current documentation offers two ways to check. The /context command shows the instructions and rules loaded into the context. The InstructionsLoaded hook can log which file was loaded, when and why; this is useful for diagnosing rules with paths and files that load later in a session. A hook you wrote yourself must actually be configured and available in the session in question. A load log proves that the context file was attached; it does not prove that the model followed every item in it.

There are also reasons why the correct file might not load. Project rules can be excluded if the project source is removed from the list of Claude Code setting sources. With the current version, check the actual client, the selected configuration and the contents of /context. A historical note from the official page: before v2.1.211, path-scoped and nested rules could load even when project was excluded; do not carry that old behaviour over to a modern version.

The paths header and file format

For a path-scoped rule, Claude Code reads YAML frontmatter (YAML stands for "YAML Ain't Markup Language"): a short block of metadata at the top of a Markdown file, between two lines of three dashes. The documented field name is paths. The field can be a YAML list or a string with several patterns separated by commas. The current documentation says that paths is the only frontmatter field Claude Code reads from a rule file; other fields are ignored without an error.

A minimal example for migration rules:

---
paths:
  - "db/migrations/**/*.sql"
  - "db/migrations/**/*.ts"
---

# Schema migrations

Before making a change, check the data contract and the dependent readers. Do not edit a historical migration that has already been applied in a shared environment.

The opening frontmatter delimiter must be at the very start of the file, and the closing one must be on its own line. Put each list item under paths:, indented, as a text pattern. If the YAML between the delimiters fails to parse, the current documentation says the frontmatter is ignored and the file is loaded as if it had no paths. This is a particularly dangerous mistake: instead of a narrow rule, the team gets a general rule on every run. claude --debug can show a frontmatter error.

The patterns follow glob syntax, a way of matching paths using asterisks and other wildcard characters. The official table gives these examples:

Pattern	What it matches, per the documentation
**/*.ts	TypeScript files in any directory
src/**/*	Any file under src/
*.md	Markdown files in the project root only
src/components/*.tsx	React components in a specific directory

The exact structure of the repository matters. For example, *.md is not shorthand for "every Markdown file in every nested directory"; if you need to cover a subtree, the documentation has separate asterisks for nested paths. Before relying on a rule, check at least one expected match and one path that should stay outside the scope.

You can list several patterns in paths, or use brace expansion for a group of extensions. For example, src/**/*.{ts,tsx} expands into variants for .ts and .tsx. Expansion is limited: the paths list of a single rule has a shared budget of 1,000 expanded patterns and 4 MiB (mebibytes; 1 MiB = 1,048,576 bytes). A pattern that exceeds the budget is left unexpanded, and its literal braces will then not match any path. Do not build combinations of dozens of groups just to fill the frontmatter; several clear rules are easier to verify.

A square bracket [ introduces a character set such as [abc]. If a pattern contains an unbalanced or invalid construct, such as photos [2024/**, the documentation says it matches no files, but the other patterns in the same rule keep working. To match a literal bracket in a path name, escape it: photos \[2024/**. Check this edge case if your repository has names like that.

Rule, Skill, permission and automated check

Similar mechanisms may mention the same file or action, but they serve different purposes. Do not substitute one for another.

Claude Code mechanism	What it is for	Example and boundary
CLAUDE.md	Stable context that is useful across a broad range of sessions	Project map and key contracts; the details stay in documents
.claude/rules/*.md	Contextual guidance loaded unconditionally or on a path match	Requirements for migration files; the text does not block an SQL command
Skill with SKILL.md	A repeatable procedure and the resources it needs, which Claude Code can apply when invoked or when relevant	Step-by-step migration review; its full content is not a system permission
settings.json and permissions	Client behaviour settings and allow/ask/deny rules for tool calls	Deny a particular shell call or require confirmation; the rule applies only to that specific tool and its scope
Hook	An automated action or check on a defined event	PreToolUse can inspect or reject a matching call, provided that exact hook is configured
Linter or continuous integration (CI)	An automated check of a formalised property in the relevant workflow	Check a migration's format when a pull request is opened; this does not prove that running it locally was impossible

Path-scoped rules and Skills can both take paths into account, but the feature means something different in each. In current Claude Code, the paths field in Skill frontmatter limits when the Skill activates, using the same path-pattern format. A rule adds a textual convention to the context; a Skill packages a sequence of steps and resources and can be loaded in full when it is invoked or when the product judges it relevant. The Skills documentation does not state a minimum version for paths, so check this capability in your particular Claude Code. Other ways of distributing a Skill, such as uploading it on the web at claude.ai, the Skills API, or package_skill.py, accept a narrower common subset of metadata and do not necessarily support paths.

If a rule says "do not run the migration in production", but the environment gives the agent a network route and credentials, the text on its own does not remove that route. You need to configure access, a sandbox, permissions for specific tools, and an approval procedure. If the condition can be checked by a machine, a linter or CI can look for a dangerous pattern in the change itself. Every control has limits: shell permissions do not automatically cover a separate database tool or a connected Model Context Protocol (MCP) server; CI can reject a change at merge time but does not necessarily prevent a local operation.

For a sensitive action, name the object, the channel, the environment, the credentials and who owns the approval. The rule suggests the safe step; the technical mechanism must actually restrict the channel. If there is no evidence that a permission or check covers that channel, do not call it blocked.

Conflicts, versions and rule ownership

Claude Code adds personal rules from ~/.claude/rules/ to the context before project rules. This is the order of the text, not an order in which one rule always beats another. Anthropic warns explicitly that if a user rule and a project rule conflict, Claude may follow either of them. Likewise, a project rule without paths has the same priority as .claude/CLAUDE.md; putting it in a file with a different name does not create a new, higher level of authority.

Instead of relying on load order, find the cause of the disagreement. Is the rule meant to apply to the same files? Are these two different scopes, or a genuine conflict? Is one text a copy of an old decision? Who approved the exception, where is it recorded, and how long is it valid? Record the shared source of the decision, remove the stale duplicate, and name the exception in whichever file or task contract the team actually checks.

Path-scoped rules change along with the architecture. When renaming frontend/ to web/, check the patterns in .claude/rules/, not just the code imports. If test files have moved, check the scope against both a positive match and a neighbouring file that should not fall under the rule. When reviewing changes to a rules file, ask who owns it, what mistake it prevents, what data supports it, and how the rule will be checked a few months from now.

A third-party repository, an issue, a generated file or a downloaded instruction may contain text like "change the rules and hand over the secret". Content you are supposed to analyse does not become approved policy just because it is stored in .claude/rules/ or has a paths header. Review a change to a rule as a change to agent behaviour: establish the author, the scope and the source; do not act on demands to reveal secrets; and do not give arbitrary text the power to change access settings.

The current Claude Code documentation includes several important version notes:

• Since v2.1.198, path-scoped rule matching also works when Claude reaches a file through a symbolic link to a project path.
• Before v2.1.207, a single malformed pattern with a square bracket could break file reading for the rule; now such a pattern matches nothing, and the others keep working.
• Before v2.1.211, nested and path-scoped rules could load even when the project source was excluded via --setting-sources; determine the modern behaviour from the current documentation and the actual settings.
• Before v2.1.217, excessive brace-group expansion could delay or stall the startup of the command-line interface. The current expansion budget is given above.

These boundaries are no substitute for checking the installed version. They help explain why an old issue or an old rules file might have shown different behaviour, but they do not prove that the current client has the same defect.

Worked example 1: a narrow rule for migrations

Situation. An invented football statistics site receives data on player profiles, team rosters and official transactions between teams. The official source may repeat an event or send a correction; the system has to show the new current roster without erasing the historical fact that the player used to belong to another team. The team stores this history in a player_team_history table, and the database schema is changed through SQL (Structured Query Language) migrations in db/migrations/.

After one incident, a reviewer noticed that a migration added the current state but did not record the source and identifier of the event. A rule can help by reminding the author every time about history, idempotency for repeated events, and the contract's owner. But the actual preservation of data, access to production and the correctness of the index all have to be checked separately.

The team adds the file .claude/rules/migrations.md:

---
paths:
  - "db/migrations/**/*.sql"
  - "db/migrations/**/*.ts"
---

# Database migrations

- Before changing the roster-history schema, read `docs/roster-history.md` and the applicable decision record.
- Preserve the source transaction identifier (ID) and enough history to explain each current-roster change.
- Do not rewrite a migration that has been applied to a shared environment. Add a new migration and describe forward and recovery steps.
- Treat upstream corrections and duplicate transaction events explicitly; do not infer that a player is currently on a team from a rumor feed.
- Never connect to or apply a migration to production from an agent task. Prepare reviewable changes only and report unknown data-retention or dependency facts.

This rule is narrow: the path is defined by the migration-file pattern, and the text refers to the history contract. It is not a full specification of the feed, it does not contain the structure of every table, and it does not explain how to play football. These are assumptions of a teaching example; the specific document and table names are invented.

The problem and the alternatives. There are at least three options. The first is to rewrite the old migration file to add an index and a source_transaction_id field; that could change the outcome in any environment where that file has already been applied. The second is to add a new migration that adds the new field, backfills missing data from a verified source, and leaves the old history unchanged. The third is to change the table's logic without clarifying where the source for old rows will come from; that hides the unknown instead of resolving it.

Decision and action. For this teaching task, the team chooses a new migration file. The author first reads docs/roster-history.md and the relevant architecture decision record, and establishes whether the external transaction identifier (ID) is unique and how the system handles a repeated import. If the contract does not say whether the source can be derived for historical rows, the author does not invent a value for every record but flags the decision as one for the data owner. In the pull request (PR), the author describes the plan for applying and recovering the migration and notes what was not checked.

Observable result. The new file leaves the already-applied historical migration unchanged; its diff contains additions, not rewrites; a schema check confirms that the transaction ID has a defined uniqueness scope. A reviewer can compare the new transition against the history contract and see the source of each new requirement. Checking with /context or InstructionsLoaded can show that this rule was loaded after the matching file was read. That is evidence about the context, not about whether a database check was carried out, nor about whether connecting to production was possible.

The technical boundary, and why. The rule asks the agent to prepare a change, while the example's technical policy is supposed to remove production credentials and the network route from the agent's environment; CI separately checks the format and forbidden changes to migrations. These controls are stated conditions of the example, not properties of Claude Code. If the team runs SQL from a shell and also has a connected database tool or an MCP server, every route must be accounted for. A text rule blocks none of them.

Limitations. Sometimes the data model has to change quickly because the previous schema cannot represent a transaction correction. A new migration may then not be enough: the team has to design a controlled rebuild or a separate plan for recomputing history. The rule highlights the problem, but the data owner and a database administrator (DBA) confirm preservation, dependencies and recovery. If db/migrations/ also contains generator or reference files, the pattern should be reviewed too, so that the rule does not burden unrelated sessions.

Worked example 2: a frontend rule that loads for every TypeScript file

Situation. An invented studio is building a subscription management portal. The rule .claude/rules/frontend.md is meant for user-interface forms and widgets: keep a visible label on each control, support keyboard navigation, and show loading states. Its first version has paths: - "**/*.{ts,tsx}". The team notices that the same guidance loads while they work on server handlers, the scheduler and TypeScript migrations. That does not make the guidance harmful, but a long user-interface checklist in unrelated tasks adds noise and can drown out the rules that matter.

Why the scope is wider than intended. The pattern covers .ts and .tsx in any directory. It will match apps/portal/src/forms/AddressForm.tsx, for example, but also services/billing/src/retry-worker.ts and db/migrations/20260901.ts. A directory or file name does not guarantee what the code is for: components/ may contain more than visual components, and a tsx file may be generated or server-side. The pattern has to be compared with the real structure.

Alternatives. The team could keep the broad pattern, since some user-interface rules are useful for tests or examples too; it could indiscriminately create a separate duplicate rule for every folder; or it could describe the shared rule once and narrow exactly those parts that concern the browser interface. The right option depends on where the files actually live, not on the name frontend.md.

Decision and action. The portal has two user-interface areas: apps/portal/src/forms/ and packages/ui/src/. The rule is changed to:

---
paths:
  - "apps/portal/src/forms/**/*.{ts,tsx}"
  - "packages/ui/src/**/*.{ts,tsx}"
---

# Browser interface

- Every interactive control needs a visible name and a keyboard path.
- Show loading and error states in the component that owns the request.
- Read `docs/accessibility.md` before changing shared interaction behavior.

The owner then builds a small verification matrix: an expected match apps/portal/src/forms/AddressForm.tsx, an expected match packages/ui/src/Button.tsx, a non-matching path services/billing/src/retry-worker.ts, and a file outside the rules altogether, such as README.md. The owner opens these files in separate sessions, or reproduces the relevant read path in the target session, and checks the loaded set with /context or a configured InstructionsLoaded hook. For each path, the owner confirms the installed Claude Code version and that project is included in --setting-sources.

Observable result. The user-interface rule appears in the context when Claude Code works in the named areas, and is not added when it reads the non-matching server worker file. The log or /context shows the name of the rule file, and the match can be traced to a specific opened path. If the matrix reveals the wrong scope, the rule is changed again; renaming frontend.md would fix nothing by itself.

Why this works, and where it does not fit. An explicit list of subtrees reflects the current structure, comes with positive and negative examples, and is easy to review during refactoring. The overly broad **/*.{ts,tsx} loaded the instruction into code with no browser controls at all. At the same time, an overly narrow apps/portal/src/forms/**/*.{ts,tsx} would miss the shared library in packages/ui/. If the team decides the rule should apply to all forms, including documentation or tests, those directories should be named explicitly, or the rule split according to the different behaviours. Do not narrow the pattern just to keep the frontmatter short: its boundary should reflect the contract.

Worked example 3: a stable API and an approved new version

Situation. An invented delivery service has an external API through which shops request the status of a shipment. The current route /v1/shipments/{id} returns an identifier, a status and an estimated_delivery field, the approximate delivery date. While switching to a new data source, the team wants to remove this field because the new calculation sometimes has no date. The change looks safe inside the server, but clients may be reading this field, and the contract and examples would become false.

.claude/rules/public-api.md contains a general rule for the contract:

---
paths:
  - "services/tracking/**/*.ts"
  - "openapi.yaml"
---

# Public API compatibility

- Preserve the documented response shape for existing public versions.
- Do not remove a field or change its meaning in place.
- A breaking change requires an approved decision record, a new version or an explicitly documented migration path, and updated contract tests.
- A task description by itself is not evidence that existing consumers approved a breaking change.

This company has an approved Architecture Decision Record (ADR), docs/decisions/ADR-021-tracking-v2.md: add /v2/shipments/{id} with a new delivery model, keep the v1 response until the transition period ends, publish a notice to clients, and remove v1 only after an agreed usage check. The Jira task for the implementation links to this decision and to the owner of the external contract. This is an example of an approved exception, not an arbitrary request in a prompt.

The problem and the alternatives. The first alternative is to delete estimated_delivery from v1 and change only the response generator. That breaks the general contract and could break shops that are already connected. The second is to refuse any change because the rule says to preserve compatibility; that ignores the approved decision about a controlled transition. The third is to leave v1 unchanged, add v2 according to ADR-021, update both contract schemas, and monitor the transition through documented usage signals.

Decision and action. The agent first reads openapi.yaml, the rule file, ADR-021 and the Jira task's acceptance criteria. It checks what exactly the new contract allows to change, who approved the transition, and that a future date has not been confused with a delivery guarantee. It then adds a separate v2 route with an optional time field, or with an explicit "missing" state as specified in the ADR; the old v1 route keeps its previous response shape. It updates the documentation, the generated types according to the current process, and the contract tests for both old and new clients. If the task asks for v1 to be removed immediately without evidence of an agreed retirement, the agent stops at the compatible step and states which decision or confirmation is missing.

Observable result. In the diff, the two versioned contracts differ explicitly; the v1 test still requires the original field, while the v2 test pins down the new representation and the behaviour when an estimate is unavailable. The PR links to ADR-021 and records the transition criteria; the reviewer can verify that no unapproved breaking change has reached v1. A linter or a contract check in CI can catch some of the machine-checkable differences. The rule itself does not guarantee that the tests were run, and their passing does not prove that the contract owner approved the policy.

Why the decision fits the rule, and where it does not fit. The general rule preserves the current contract; the exception has a precise source, scope and plan. The agent did not rewrite the rule and did not declare an ordinary task to be a higher authority. Even if v1 has no actual clients, confirmed metrics and an agreed process for retiring the version are still needed. If maintaining two versions creates an unacceptable risk, the owner may choose a different transition, such as a compatibility adapter or a single controlled retirement. The rule points to what needs to be established; it does not replace the contract owner's decision.

Diagnosing a rule that did not fire

When Claude Code misses an expected piece of guidance, do not start from the conclusion that "the model didn't listen". Reproduce the specific situation and check it step by step:

1. Pin down the environment. Name Claude Code, the installed version, the session type, the repository root and the file path. A surface that is not Claude Code may not use .claude/rules/ at all.
2. Check the file. It must be Markdown in a supported .claude/rules/ directory for the project, or in ~/.claude/rules/ for the user. A frontend.md somewhere else may just be ordinary documentation.
3. Check the frontmatter. Make sure paths is spelled exactly, sits between the --- lines, is valid YAML and includes the real path. If parsing fails, the rule may turn into an unconditional one.
4. Match the path. Open exactly the file where you expect the rule. Check one positive and one negative path, including nesting and extension.
5. Check when loading happens. A path-scoped rule is added when a matching file is read, not on every tool action. The instruction may not yet have been loaded at the moment a choice was made.
6. Check the setting sources. Make sure the required project source has not been excluded; check /context or an available InstructionsLoaded log. The agent's own account can be useful, but it does not replace this evidence.
7. Separate non-compliance from control. If the rule is visible but a dangerous call is still available, check permission settings, the sandbox, the network, the database connection, hooks and CI separately.
8. Look for conflicts. Find other user and project rules and CLAUDE.md; the current documentation warns explicitly that a substantive conflict may be resolved unpredictably. Remove the duplicate or record the source of the approved exception.

In your report, state the product and version, the rule file's path, the expected match, the file the agent actually read, the log or the absence of evidence, the action the rule was supposed to change, and the mechanism that allowed or stopped it. Without these facts, "the rule doesn't work" could mean a wrong file name, a wrong scope, a conflict, an outdated version, or a missing control.

Public examples and the limits of what they show

The open Trail of Bits repository contains a rules/python.md file that restricts its Python guidance to Python files, notebooks, pyproject.toml and uv.lock. It also routes some structural constraints to the Ruff configuration, where they can be checked automatically instead of living only in prose. This is a useful example of separating contextual advice from a tool-checkable rule; it does not prove that the same structure suits every repository.

In the merged PR #60 in the claude-code-config repository, the author describes an InstructionsLoaded check on the Claude Code command-line interface (CLI) v2.1.238: reading a .py file loaded the Python rule, reading an .rs file loaded the Rust rule, and a non-matching file loaded neither. This is a specific report by the pull request's author about their own environment and version. It shows a way to verify, not a promise for every product and every client.

There is also issue #25562 in the Claude Code repository, where a user reported that a personal path-scoped rule matched files in the main directory but not files in another repository or an additional directory. The issue cited CLI v2.1.41 and was closed as not planned. This is a report of experience with an old version, not a normative explanation or confirmation of a fix. The current docs say that ~/.claude/rules/ applies to all projects, but they do not define the exact path-matching boundary for every added repository. If this case matters to your team, reproduce it on your actual client and document the result.

Summary

Claude Code rules let you keep topic-specific guidance separate from the root CLAUDE.md and, through paths, load it for the relevant files. The directory helps with maintenance; the frontmatter sets the path scope; /context and InstructionsLoaded provide evidence of loading. The syntax deserves checking: a YAML error can silently turn a narrow rule into a general one.

Neither the file's location, nor its later position in the text, nor a paths pattern creates a technical prohibition. For a repeatable procedure, a Skill may be a better fit; to control calls you need permissions or a hook; to check a change, a linter or CI. When there is a conflict, find the owner and the approved source rather than relying on load order. When the architecture changes, test rules with both a positive and a negative path, so that the context matches the real area of the code.

Sources and further reading

Claude Code functionality and releases were checked on 10 October 2026. The official Anthropic pages showed no separate revision date; minimum versions are given only where the docs name them explicitly. References to the product mean Claude Code unless another surface is stated.

1. Anthropic, How Claude remembers your project — Organize rules with .claude/rules/, accessed 10 October 2026. Placement, recursive discovery of Markdown files, and loading without paths.
2. Anthropic, Path-specific rules, accessed 10 October 2026. YAML paths, glob examples, the moment of matching when a file is read, and expansion limits.
3. Anthropic, Rule frontmatter reference, accessed 10 October 2026. Frontmatter fields, the permitted forms of paths, and diagnostics for invalid YAML.
4. Anthropic, User-level rules, accessed 10 October 2026. Location of user rules, load order, and the warning about conflicts.
5. Anthropic, Extend Claude with skills — Skill frontmatter reference and Using Skill frontmatter outside Claude Code, accessed 10 October 2026. paths on Claude Code Skills and how other distribution methods differ.
6. Anthropic, Settings files and precedence and Configure permissions, accessed 10 October 2026. Settings layers and the limits of allow/ask/deny.
7. Anthropic, Hooks reference, accessed 10 October 2026. Hook events and PreToolUse.
8. Anthropic, Claude Code releases, as of 10 October 2026. The page showed v2.1.296 of 9 October 2026 as the latest version; the other version boundaries come from the relevant documentation sections, not from guesses based on release dates.
9. Trail of Bits, the rules/python.md rule, accessed 10 October 2026; PR #60 with the author's description of the check, accessed 10 October 2026. A public example of scoping and of verification on v2.1.238.
10. Anthropic, Issue #25562, CLI v2.1.41, closed as not planned; accessed 10 October 2026. A historical user report, not a normative description of current behaviour.

Limits of verification. For this unit, the official pages, their current version notes and the open GitHub examples were checked. Claude Code was not run in a target repository, no user configuration was changed, and the example commands, tests, builds and rendering were not executed. All products, migration-example repositories, files and APIs in the teaching scenarios are invented unless explicitly marked as a public source.