Every content file declares a type: in frontmatter. The type determines which category directory the file lives in, how the installer handles it, and which type-specific frontmatter fields are required.
Quick table
type: |
Category dir | Install target | Autoload |
|---|---|---|---|
|
|
|
Yes |
|
|
|
No |
|
|
|
No |
|
|
|
No |
|
|
|
No |
|
|
Deep-merge into |
n/a |
|
|
|
n/a |
|
|
|
Anthropic |
|
|
|
Per session, gated by safety |
Type-specific frontmatter requirements
settings-fragment
Body must contain exactly one JSON code block under a ## fragment heading. The validator rejects entries that touch top-level keys outside permissions.{allow, deny, ask} and env. See Settings-fragments concept for deep-merge semantics.
project-claude-md
Frontmatter must declare project-type: (e.g. ruby-gem, jekyll-docs, rails-app, generic) for picker filtering. Body is the literal CLAUDE.md content — frontmatter is stripped on install and the body is written to <project>/CLAUDE.md. Body length capped at 200 lines.
path-rule
Frontmatter must include a non-empty paths: list of glob patterns. Each glob is syntax-checked. Example:
paths:
- Gemfile
- Gemfile.devel
- "*.gemspec"
Anthropic’s .claude/rules/ mechanism loads the file only when at least one matching file is in the working set.
hook (v2 only)
Reserved for v2. Mandatory safety: object field declaring which side effects the hook performs. See SAFETY.md and the hooks-deferred concept page.
Memory subtypes
The four memory-* types differ only by frontmatter category — install target and behaviour are identical. Use them to signal what kind of content the file holds, which helps reviewers and the future-generated catalogue.
-
memory-feedback— corrections, behavioural preferences, incident history. -
memory-reference— facts, data tables, look-up information. -
memory-project— project-state notes, in-flight work context. -
memory-user— user profile, work-domain facts, identity data (with care — secrets never go here).
See also
-
SCHEMA.md— full frontmatter contract with type-specific requirements. -
Validator rules — what the validator enforces per type.
-
Instructions vs memory — operational distinction.