These notes are injected into AI context mid-task, repeatedly, across every project, indefinitely. Every section that doesn't earn its place is a recurring token tax. The governing rule:
> **The burden of proof is on inclusion. A section exists only if you can name a consumer who acts differently because it's there.**
This applies to every template section decision and every authoring choice.
**Implementation note:** The Layer 2 "agent" requires an invocation mechanism decision before Plan B Phase 3 is built. See Plan B (`10-sb-findability-plan.md`) Phase 3 prerequisite note. Until this decision is made and built, Layer 1 is the primary write path.
*These sections are illustrative starting points. The Step 2 template-design process applies the injection-economics filter — any section that can't pass "a named consumer acts differently because this is here" gets cut. The Step 2 output is authoritative.*
*These sections are illustrative starting points. The Step 2 template-design process applies the injection-economics filter — any section that can't pass "a named consumer acts differently because this is here" gets cut. The Step 2 output is authoritative.*
Location: `cc-os/plugins/memory/skills/memory-template/SKILL.md` — alongside the existing skills (`memory-vault`, `memory-write`, `memory-project`, `memory-reorganize`). It is Graphify-indexed in the cc-os project graph, not the vault graph.
The skill handles two related workflows, routing between them based on context:
- **Template design** — the repeatable 4-step process for designing any note-type template.
- **New-type creation** — the full lifecycle of adding a new type to the vault, from recognizing the need through to a working template (delegates to the template-design flow for the template itself).
1.**Model the consumers** — write who reads this type and the one action each takes. Grab or construct one exemplar (N=1, even synthetic, is enough — the process doesn't require a corpus).
2.**Extract the minimal body shape** — name 2–4 body sections ordered action-first → why/when → caveats-last. For each candidate section, write one line: "*[consumer] acts differently because this is here.*" No line = cut the section. Add a subtype variant only if a real variant needs a genuinely different core shape.
3.**Draft the fillable skeleton** — fixed frontmatter block + H1 + each section as a header with a one-line inline instruction (what goes here + target density) + an abbreviated filled example showing target density.
4.**Dogfood and cut** — fill the template with the exemplar. Cut any empty or padded section; tighten any ambiguous instruction; re-fill. Done when the exemplar fills it with no empty sections and no padding.
The new-type-creation workflow the skill documents:
1. Recognize the trigger — what signals a type gap? (SessionEnd catch-all surfacing something that doesn't fit; repeated in-session workarounds for the same structural problem; N≥3 real instances exist that share structure)
2. Collect N≥3 real examples (or construct synthetic ones)
Key design decisions baked in to the template-design flow:
- Frontmatter (`summary` + tags) already serves the scanning human and the recall AI. The body only needs to serve two consumers: the injected AI mid-task and the executing human. Both want actionable core up front; they differ only in how far they read. One artifact, progressive disclosure, different stopping points.
- One shared spine (frontmatter → H1 → actionable core → why/when → caveats), three type-specific body shapes. Subtypes are body variants within a template — never separate templates.
- Anti-patterns the process must guard against: section inflation ("for completeness"), vague headers (`## Notes`, `## Details`), body duplicating frontmatter, paper-good/practice-ignored structure (caught by the dogfood step), convention stated without its boundary, smuggling project narrative (episodic content belongs in memsearch, not SB).
**Step 2b — Write the three template files**
Location: `~/Documents/SecondBrain/_templates/`
Apply the Step 2a process (from the `memory-template` skill) to each type in this order:
1.`howto.md` — first, because the template-design flow dogfoods it
2.`convention.md`
3.`reference.md` — include the sub-template variant selector in the body
Use these existing notes as exemplars for the dogfood step:
| `howto/airtable-mcp-setup.md` | `update_note` field was undocumented; Step 3 leaks project-specific scaffolding | `update_note` is now documented in the schema above; add inline comment flagging Step 3 as a project-customization point |
| `vault-conventions.md` | Two contradictory frontmatter schemas coexist | Reconcile — see Phase 1 Step 1 |
---
## Migration Candidate Pool
High-priority candidates from real project files, ordered by cross-project value. Not
