Knowledge skill instructs reading a _schema.md that is neither shipped nor auto-generated on install

[elhoim]

Summary

The Knowledge skill's instructions repeatedly tell the agent to read MEMORY/KNOWLEDGE/_schema.md before writing or ingesting notes, but that file does not exist on a fresh install and nothing in the shipped install/setup flow creates it. A second reference to MEMORY/KNOWLEDGE/Ideas/pai-knowledge-linking-architecture.md is a plain dangling link with no source anywhere in the repo.

Evidence

LifeOS/install/skills/Knowledge/SKILL.md (commit d1d6240) references _schema.md five times:

• L24 — **Archive schema:** \~/.claude/LIFEOS/MEMORY/KNOWLEDGE/_schema.md``
• L105 — "Create the note with proper frontmatter from _schema.md..."
• L117 — also references MEMORY/KNOWLEDGE/Ideas/pai-knowledge-linking-architecture.md
• L222 — "Determine entity type ... using the classification rules in _schema.md"
• L415 — "Schema enforcement. ... Always read the schema before writing."

On a fresh install, LifeOS/install/LIFEOS/MEMORY/KNOWLEDGE/ doesn't ship at all (the GitHub contents API 404s on that path), so _schema.md isn't present in the payload, and the directory is only created lazily when the first note is written — nothing populates _schema.md inside it.

What _schema.md is supposed to be

It's not meant to be hand-authored — it's a generated doc. LifeOS/install/LIFEOS/TOOLS/GenerateKnowledgeSchemaDoc.ts renders MEMORY/KNOWLEDGE/_schema.md from the real source of truth, LifeOS/install/LIFEOS/TOOLS/KnowledgeSchema.ts. This is also documented explicitly in LifeOS/install/LIFEOS/DOCUMENTATION/Memory/MemorySystem.md (L332): "The contract lives in LIFEOS/TOOLS/KnowledgeSchema.ts (single source of truth); _schema.md is GENERATED from it via GenerateKnowledgeSchemaDoc.ts."

The problem: nothing invokes that generator. A repo-wide search for GenerateKnowledgeSchemaDoc turns up exactly two hits — the tool file itself and the one descriptive mention in MemorySystem.md. It isn't called from install.sh, from any package.json script, from a setup/postinstall hook, or from any Knowledge tool (KnowledgeHarvester.ts, KnowledgeGraph.ts, etc.) on first use. So the generator that's supposed to produce the file the skill tells the agent to read is never run on a real install.

Sibling dangling reference

MEMORY/KNOWLEDGE/Ideas/pai-knowledge-linking-architecture.md (SKILL.md L117) has no generator and isn't shipped either — a repo-wide search for pai-knowledge-linking-architecture returns only the one reference inside Knowledge/SKILL.md itself. Unlike _schema.md, there's no code anywhere that could produce this file; it's a pure broken link. (This is likely made redundant by the fact that SKILL.md already inlines the full "Canonical Linking Requirement" itself at L115-162.)

Actual impact (verified, not assumed)

This is not a hard ingestion blocker. Running /knowledge ingest on an install missing _schema.md, the agent noticed the file was absent and proceeded using the schema described inline in SKILL.md's own body, producing well-formed notes. So the real effect is a missing guardrail: agents write Knowledge notes without ever consulting the intended canonical, code-derived schema doc, which is exactly the kind of drift the repo's own history warns about — MemorySystem.md traces GenerateKnowledgeSchemaDoc.ts back to killing a prior "three dialects" schema-drift problem. Right now that protection is dead code because the generator is never invoked on an actual install.

Suggested fixes (graded)

1. Minimal: wire GenerateKnowledgeSchemaDoc.ts into install.sh (or have the Knowledge skill run it lazily on first invocation when _schema.md is missing) — the generator already exists and works, it's just never called.
2. Alternative: ship a pre-generated _schema.md directly under LifeOS/install/LIFEOS/MEMORY/KNOWLEDGE/_schema.md in the install payload (simpler, but can drift from KnowledgeSchema.ts until someone remembers to regenerate).
3. Fallback: if neither of the above is picked up soon, at least fix the dangling references — inline the schema description directly into SKILL.md (killing the external-file dependency) rather than pointing at a file that may not exist.
4. For the pai-knowledge-linking-architecture.md reference specifically: either author and ship that file, or just drop the dangling pointer at L117 since the linking requirement is already fully inlined in the same document.