Skills

How the skill set stays coherent as it grows. This is the rule most likely to be forgotten by a future session, and the one whose absence is hardest to detect — nothing breaks, output just gets quietly worse.

Skills do not call each other

They compose through typed artefacts and the pipeline order is code. Skills invoking skills produces a graph nobody can debug, and it puts routing decisions inside a model where they cannot be inspected. Each skill has a narrow contract: consumes X, produces Y, both schema-validated.

But they are conceptually co-dependent

This is the part that bites. Introduce a skill defining awareness levels, and the copy skills must defer to it rather than carrying their own quietly diverging version. Introduce an angle-definition skill, and copy and script both need to know that angles are now a defined artefact rather than a loose idea.

Nothing enforces this by itself. Two skills each carrying a reasonable-but-different account of the same concept is how output degrades in a way nobody can trace: each file reads fine on its own, and together they contradict.

The rule: one owner per concept

Every skill declares in its frontmatter:

owns:
  - script-structure      # this skill is the source of truth
references:
  - awareness             # used here, defined elsewhere

• owns — concepts this skill defines. Exactly one skill may own a concept.
• references — concepts it uses but must not redefine. If a skill needs to explain a referenced concept, it explains *just enough to use it* and points at the owner.

Concepts that are authoritative but do not live in a skill file — the format catalogue, the taste principles — are declared in skills/system-owned.json, so the graph stays complete instead of quietly tolerating a dangling reference.

Enforced, not remembered

src/lib/agents/skill-graph.test.ts fails the build when:

• a skill declares no owned concept
• two skills own the same concept
• a skill references a concept nothing owns
• a skill references a concept it owns itself

The failure arrives at the moment of introduction, which is the whole point — the alternative is discovering it months later as unexplainable output drift.

It found a real gap the first time it ran: two skills referenced creative-formats, which no skill owned, because the catalogue lives in the database.

When adding a skill

1. Decide what it owns. If another skill already owns it, extend that skill instead.
2. Decide what it references, and go and read those owners.
3. Update the existing skills that should now defer to it. This is the step that gets skipped. A new skill is not finished when its own file is written — it is finished when the skills whose territory it took have been updated to point at it.
4. Run the tests.

Concepts still without an owner

Tracked in the test so they cannot be forgotten: market-research, insight-synthesis, angle-definition, format-selection. When each is written, its skill claims the concept and the duplicate-owner check starts enforcing it for real.