delorenj Frontmatter Enrichment
The third link in the triage pipeline. folder-curator types a file, domain-triage routes it to its entity, then this fills the frontmatter — the base skeleton plus the context-aware values that only the driving agent's memory can supply ("why does this file exist, what is its role in the plan").
Operating principles
- Base first, then context. Stamp the declared base schema (idempotent, non-clobbering), then set the interpolated values on top.
- Never clobber, never fabricate. Preserve existing values; use
unknown/unconfirmedrather than inventing. Memory-grounded values beat guesses. - The editor is
frontmatters, not hand-edits. It preserves key order and writes atomically; hand-editing YAML risks the order/format corruption the tool exists to avoid. - Memory is the differentiator. The rich fields come from the repo's Hermes PM context — recent activity, decisions, and the Hindsight bank — not from the file alone.
- No new agent. The repo's Hermes PM drives this; its memory is the context.
Quick navigation
| Task | Read |
|---|---|
| The enrichment procedure (step by step) | references/enrichment-procedure.md |
| Declaring/resolving the base schema per repo | references/base-schema.md |
| Deriving context-aware values from memory | references/context-interpolation.md |
| Sharp edges | references/gotchas.md |
The tool (frontmatters)
The editor is the extended frontmatters CLI (repo: ~/code/frontmatters; also an MCP mode):
frontmatters apply-base FILE --schema <base> # add missing base keys (no clobber), order per schema
frontmatters set FILE key=value [key=value...] # set arbitrary values (type-coerced), order-preserved
frontmatters validate FILE --schema <base> # required keys + enum check; exit 1 if invalid
<base> is a schema file OR a dir containing .curator/taxonomy.yaml. See references/base-schema.md.
Procedure
Preconditions: the file is already typed (has category/kind) and entity-routed (domain-triage set
the entity label + moved it). Then:
- Apply the base skeleton.
frontmatters apply-base FILE --schema <repo-base>— stamps every base key, keeps what's there. - Gather context from the driving PM's memory: recent activity (
llr/mtime), the decisions ledger, andhindsight memory recall <bank> "<file topic>". This answers why the file exists and its role in the plan. See references/context-interpolation.md. - Interpolate the context-aware values —
title,description,tags,summary,domain, and a plan-context field (e.g.why/context) — grounded in step 2, not invented. - Write them:
frontmatters set FILE title="…" description="…" tags="[…]" why="…". - Validate:
frontmatters validate FILE --schema <repo-base>; fix any missing required keys.
Base schema is per-repo (so any repo extends it)
The tool is schema-agnostic: each repo points --schema at its own base+extension. The DeLoDocs vault
uses its metadata-first contract (_vault/Settings/frontmatter-category-map.json); other repos declare
a .curator/taxonomy.yaml frontmatter: block or a plain base.yaml. See references/base-schema.md
for the resolution order and the two-convention caveat.
Out of scope
- Type classification (category/kind/
plan) →folder-curator. - Entity detection & routing (which company/client/repo, moving the file) →
domain-triage. This node runs after it and assumes the entity is already set. - Memory retain/recall/bank mechanics →
hindsight. This skill consumes recall; it doesn't manage banks. - Authoring the frontmatter schemas themselves (defining a repo's base/extension) → that's a contract-authoring task; this skill applies an existing schema.
- The vault Inbox classifier→specialist pipeline →
_vault/Workflows/in DeLoDocs. - Extending the
frontmatterstool itself → its own repo (~/code/frontmatters).