Every feature in this catalog so far writes its full operating content directly into a target project's admin\AGENT_INSTRUCTIONS.md — a ◆ SECTION NAME block with the complete Write payload inline. That works well for features relevant in most sessions, but doesn't scale forever — a project with many features installed ends up with a large instructions file, most of which is only relevant a fraction of the time. This section exists because the problem became visible directly this session — a real transcript showed a downstream project's instructions file already substantial after only 10 installed features.
Pointer-style is the alternative for features that are long, detailed, and not needed in most sessions. Instead of the full content going inline, only a short stub goes into admin\AGENT_INSTRUCTIONS.md, and the complete operating content lives in its own file at admin\feature-prompts\[slug].md in the target project — read on demand, only when the feature is actually being invoked.
Pointer stub format (what actually goes into admin\AGENT_INSTRUCTIONS.md in place of the full section):
◆ [FEATURE NAME] — POINTER
Full detail: admin\feature-prompts\[slug].md
Invoke when: [one-line trigger condition — what makes this feature relevant right now]Deciding inline vs. pointer, per feature:
- Stays inline: anything checked or potentially relevant in most or every session — startup behavior, process safeguards, file transfer rules, folder structure, anything a session needs available with zero fetch latency. Most of this catalog's Foundation, Organization, and Continuity features belong here regardless of length; length alone is never the deciding factor.
- Candidate for pointer: long, detailed operating content for something invoked only occasionally — a specific workflow, a specialized system, something a session only touches when a person actually asks for it by name.
First real application (2026-07-21): FTR-34 (Repository Ledger Visualization) is the first feature to actually use this mechanism, three years' worth of catalog-time after it was documented. Its design-derivation logic and full HTML/CSS template are long, and the feature is explicitly invoked only by name ("show me the project ledger") — a clean match for every criterion above. See FTR-34's own file for exactly how the split works: a short stub in admin\AGENT_INSTRUCTIONS.md, full content in admin\feature-prompts\repository-ledger-visualization.md.
What this doesn't change: INSTALL-TIME FILE SAFETY above still applies in full to admin\feature-prompts\[slug].md — read it first if it already exists before writing, same as any other file this catalog touches; a pointer file being scoped to a single feature makes a fresh write usually safe, but "usually" is not "always," and the check still happens. The pointer stub itself, written into admin\AGENT_INSTRUCTIONS.md, follows the exact same additive-merge rule as any other section — it is not a special case.
How a downstream project's own agent learns about this: FTR-01 (Bootstrap Operating Behavior) — Core, installed in every project — now carries a short standing note in its own Write payload: some installed features are pointer-style, check admin\feature-prompts\ for a stub's full detail before assuming a feature isn't installed. This means every project gets pointer-awareness automatically, whether or not that project ever actually installs a pointer-style feature. Ver bumped 1.2 -> 1.3.
Note (added with FTR-31): even though FTR-31's own Write payload is small enough that inlining it never needed pointer-style, this mechanism and FTR-31's own "not a dependency" framing (see Prerequisites above) are worth keeping distinct in your head — pointer-style is about WHERE an installed feature's content lives; the Prerequisites page is about something that isn't a feature at all. Don't conflate the two just because both involve a file outside admin\AGENT_INSTRUCTIONS.md.