@skill-graph/cli 0.5.6

package/docs/adr/0006-revise-predicate-rename.md

@@ -0,0 +1,105 @@
+# ADR 0006 — Revise ADR 0001 § Decision #2 (`boundary` is not `owl:disjointWith`)
+
+- **Status:** Accepted (2026-05-04)
+- **Deciders:** Skill Graph maintainers
+- **Supersedes:** ADR 0001 § Decision #2 only (Decisions #1, #3, #4 stand unchanged)
+- **Consulted:** OWL 2 Web Ontology Language Primer (W3C 2012), W3C SKOS Reference, GPT-5.5 empirical confirmation of the in-tree JSON-LD context (2026-05-04)
+
+## Context
+
+ADR 0001 (2026-04-20) accepted four predicate-set proposals as a single bundle for v3.1:
+
+1. Rename `adjacent` → `related` (skos:related). **Sound and uncontested — academically defensible.**
+2. Rename `boundary` → `disjoint_with` and treat them as aliases mapping to OWL `owl:disjointWith` semantics. **Category error — see below.**
+3. Add `broader` / `narrower` (skos:broader / skos:narrower). **Sound — closes a real expressivity gap.**
+4. Keep `verify_with` and `depends_on`. **Sound — these are PROV-O and DCMI relations, not SKOS classifications.**
+
+The 2026-05-04 board meeting (synthesis at the 2026-05-04 multi-model synthesis (kept private) § 8 Disagreements / § 12 IP-R2) flagged Decision #2 as a category error: `boundary` and `owl:disjointWith` operate at different semantic layers and equating them obscures a real distinction the schema needs to keep.
+
+The Opus 4.7 reviewer (`opus.md`) noted this directly. The GPT-5.5 reviewer (`gpt-5.5.md`) verified empirically that the in-tree JSON-LD context (`schemas/skill.context.jsonld`) was already mapping `boundary` to `sg:disjointOwnership` — a custom Skill-Graph predicate — and not to `owl:disjointWith`. The implementation was correct; only the ADR text claiming OWL alignment was wrong. This ADR documents what the implementation already does and revises the ADR 0001 narrative to match.
+
+## The semantic distinction
+
+`boundary` and `owl:disjointWith` answer different questions.
+
+| Question | Answer in Skill Graph | Maps to | Layer |
+|---|---|---|---|
+| "If a query matches skill A, can the router also pick skill B?" | No (because A's `boundary: [B]` is a routing-layer hand-off) | `sg:disjointOwnership` | **Routing layer** — operational |
+| "Is there an entity that is simultaneously an instance of A's class and B's class?" | No (because `owl:disjointWith` claims formal class-disjointness) | `owl:disjointWith` | **Ontology layer** — formal class theory |
+
+`boundary` is a **directional, asymmetric** routing claim. Skill A says "I am not the right answer for queries also matching B; route those to B." Skill B is not required to make the reciprocal claim. The router uses this to demote A in the candidate list when B scores higher, even when A's keywords and triggers also matched.
+
+`owl:disjointWith` is a **symmetric, irreflexive** class-theoretic claim. If A `owl:disjointWith` B, then B `owl:disjointWith` A — and any reasoner deriving an entity that is both A and B will flag a contradiction. (Irreflexive because a class is never disjoint with itself: every class is identical to itself, not disjoint from itself.)
+
+These are not aliases. They model different facts about the world.
+
+## Empirical evidence
+
+Per GPT-5.5's audit (2026-05-04), the existing `schemas/skill.context.jsonld` already chose the correct mapping for `boundary`:
+
+```json
+"boundary": {
+  "@id": "sg:disjointOwnership",
+  ...
+}
+```
+
+The custom `sg:disjointOwnership` predicate was the right call: it makes a Skill-Graph-specific routing-layer claim without committing the schema to formal OWL semantics that authors do not actually intend. ADR 0001 § Decision #2 wrote prose that claimed OWL alignment, but the implementation never produced that mapping. The correction is to make the prose match the implementation, not the implementation match the prose.
+
+## Decision
+
+1. **`boundary` stays canonical** for routing-layer asymmetric handoff. The schema description, JSON-LD context, lint warnings, and field-reference narrative all describe `boundary` as the canonical name for wrong-skill routing protection. The "DEPRECATED ALIAS" framing in the v3.1 schema and ADR 0001 is reverted.
+2. **`disjoint_with` becomes a separate orthogonal relation** with explicit OWL semantics (Option B from the synthesis IP-R2 § 4). It maps to `owl:disjointWith` in the JSON-LD context. Authors use it ONLY when they want a formal ontological class-disjointness claim — which is rare. Most skill libraries will never need it; `boundary` covers the routing-layer use case.
+3. **The two predicates coexist with distinct mappings.** Lint validates targets exist for both. Routers use `boundary` for routing-layer exclusion (per `scripts/skill-graph-route.js` Stage 5). RDF consumers reading the JSON-LD projection see two distinct predicates.
+4. **Lint deprecation warnings adjust:** the `boundary -> disjoint_with` rename warning in `scripts/skill-lint.js` is removed. The `adjacent -> related` rename warning stays (Decision #1 of ADR 0001 was sound).
+5. **JSON-LD context comments cite this ADR** so future maintainers see the reasoning for the split mapping.
+
+## Rationale
+
+- **The implementation was already correct.** The JSON-LD context never claimed OWL alignment for `boundary`. Reverting the prose is cheaper and safer than retroactively bending the implementation.
+- **`boundary` is a real, distinct relation type.** It encodes a routing-layer fact ("I am the wrong answer; route to X") that has no clean OWL/SKOS analogue. Naming it `disjoint_with` and gesturing at OWL hides that fact under a more famous predicate. Keeping the Skill-Graph-specific name with a Skill-Graph-specific @context predicate (`sg:disjointOwnership`) is the academically defensible call.
+- **Option B preserves capability over Option A (drop).** Per the project's quality doctrine ("improve = enrich, never simplify"), keeping `disjoint_with` available — but with distinct semantics — leaves authors a place to encode formal class-disjointness if the rare case arises. Removing it would force authors who genuinely want OWL semantics to invent custom extensions.
+- **No skill in the wild actually used `disjoint_with` as anything other than a `boundary` alias.** Re-purposing it under the new semantics breaks zero existing skills. (`grep -r "disjoint_with:" skills/` across the workspace returned zero hits at the time of this ADR.)
+
+## Consequences
+
+### Positive
+
+- ADR 0001's narrative now matches the implementation. No agent reading the docs can reach a wrong conclusion about `boundary`'s semantics.
+- `disjoint_with` becomes available for genuinely OWL-class-disjoint claims without being conflated with routing.
+- The JSON-LD context projects to RDF cleanly: `sg:disjointOwnership` for routing, `owl:disjointWith` for formal class-theory.
+- Lint stops nudging authors to rename `boundary -> disjoint_with` (which would have been wrong under the new posture).
+
+### Negative
+
+- Authors who already migrated to `disjoint_with` under the previous (false) "alias" framing now hold a relation with subtly different semantics. **Net impact: zero**, since no live skill in this repo or the consuming workspace uses `disjoint_with`. New authors reading the post-revision docs see only the corrected semantics.
+- ADR-history readers must read ADR 0001 and ADR 0006 together to reconstruct the intended posture. Mitigated by the explicit status banner on ADR 0001.
+
+### Neutral
+
+- `boundary` and `disjoint_with` are now both present in the schema. Authors who need only routing-layer behavior continue to use `boundary` and never touch `disjoint_with`. Authors with formal-OWL needs reach for `disjoint_with` deliberately.
+- The W3C SKOS / OWL alignment of the rest of the predicate set (`related`, `broader`, `narrower`, `verify_with`, `depends_on`) is unchanged.
+
+## Implementation surface
+
+The full set of edits accompanying this ADR is documented in the synthesis IP-R2:
+
+- `schemas/skill.v3.schema.json` — `boundary` description restored to canonical; `disjoint_with` description rewritten with OWL framing.
+- `schemas/skill.context.jsonld` — `boundary` keeps `sg:disjointOwnership`; `disjoint_with` switches from alias to `owl:disjointWith`. New `owl` namespace declared. `_adr_anchors` block added so the file points back here.
+- `scripts/skill-lint.js` — `boundary -> disjoint_with` deprecation warning removed; `adjacent -> related` warning kept; new warning for declaring both `adjacent` and `related` (or both `boundary` and `disjoint_with`) for the same target.
+- `docs/adr/0001-predicate-set.md` — Status banner: "Accepted with revision per ADR 0006 (Decision #2 reverted; Decisions #1, #3, #4 stand)."
+- `docs/field-reference.md § relations` — Narrative updated to match the split semantics.
+- `CHANGELOG.md` — `[Unreleased]` entry documenting the revision.
+
+## References
+
+- W3C OWL 2 Primer — https://www.w3.org/TR/owl2-primer/
+- W3C SKOS Reference (skos:related, skos:broader, skos:narrower) — https://www.w3.org/TR/skos-reference/
+- ADR 0001 — `docs/adr/0001-predicate-set.md` (the decision this ADR partially supersedes)
+- ADR 0002 — `docs/adr/0002-json-ld-context.md` (governs the @context coverage policy)
+- Synthesis 2026-05-04 § 8 Disagreement D1 + § 12 IP-R2 — the 2026-05-04 multi-model synthesis (kept private)
+- GPT-5.5 reviewer empirical verification — kept private alongside the 2026-05-04 multi-model synthesis
+
+## Supersedes
+
+- ADR 0001 § Decision #2 only. Decisions #1 (`adjacent -> related`), #3 (`broader` / `narrower` additions), and #4 (`verify_with` / `depends_on` retention) stand unchanged.

package/docs/adr/0007-audit-loop-cadence.md

@@ -0,0 +1,99 @@
+# ADR-0007: Audit Loop Cadence
+
+**Status:** Accepted  
+**Date:** 2026-05-18  
+**Task:** SH-6107
+
+## Context
+
+The skill-graph tooling repo and its sibling `skills` library repo need a formal cadence for running the Skill Audit Loop. Without a documented cadence, audits happen ad-hoc, P2+ findings accumulate without tracking, and there is no shared understanding of what "audited" means for a skill.
+
+The Skill Audit Loop specification (`SKILL_AUDIT_LOOP.md`) already defines the four operations (`audit`, `improve`, `evaluate`, `evolve`) and a generic cadence table. This ADR adds the concrete operational contract for this project:
+
+- Who triggers audits
+- What the pass criteria are
+- Where findings go
+- How P2+ findings are resolved before a task closes
+
+## Decision
+
+### Trigger
+
+| Event | Action |
+|---|---|
+| Per skill edit (SKILL.md changes) | `node scripts/skill-lint.js <skill-path>` must pass as part of PR/commit gate |
+| Weekly (automated or manual) | `node scripts/skill-graph-routing-eval.js` across all skills with `routing_eval: present` |
+| Before any stability promotion | Full `audit` for all skills in the promotion batch |
+| Per Linear task that touches a skill | Audit the affected skill before marking the task Done |
+
+### Owner
+
+The orchestrator is responsible for triggering audits. For manual sessions, the agent working a skill-touching task is responsible for running the audit and triaging findings before closing the task.
+
+### Audit invocation
+
+Run from the `skill-graph` tooling repo with the skill's absolute path:
+
+```bash
+# Deterministic lint (always run first)
+node scripts/skill-lint.js /path/to/skills/skills/<skill-name>
+
+# Routing eval (run when skill has routing_eval: present)
+node scripts/skill-graph-routing-eval.js --skill <skill-name>
+
+# Full stub audit (generates findings.md, verdict.md, scorecard.md)
+SKILL_GRAPH_WORKSPACE=/path/to/skills node scripts/skill-audit.js <skill-name> \
+  --audit-root audits/
+
+# Note: skill-audit.js cross-repo path resolution is a known limitation (tracked separately).
+# Until fixed, run skill-lint.js with an absolute path for authoritative results.
+```
+
+### Findings flow
+
+```
+audit run
+  → findings.md + verdict.md + scorecard.md written to audits/<skill-name>/
+  → P0/P1 findings: block task, fix immediately before closing
+  → P2 findings: create Linear sub-issue with parent = current task, resolve before closing
+  → P3/P4 findings: document in Linear completion comment, defer or fix opportunistically
+```
+
+### Pass criteria
+
+A skill audit passes when:
+
+1. `node scripts/skill-lint.js <skill-path>` exits 0 (from skill-graph workspace with absolute path)
+2. `node scripts/skill-graph-routing-eval.js --skill <skill-name>` shows 100% pass rate (when `routing_eval: present`)
+3. No P0 or P1 findings in `audits/<skill-name>/findings.md`
+4. All P2 findings have a linked Linear sub-issue
+
+A task is **not closed** until all P2+ findings are either resolved or have a tracking sub-issue.
+
+### Proof-audit format
+
+The first run of the audit loop against a skill must produce all three artifacts:
+
+```
+audits/<skill-name>/
+  findings.md   — required
+  verdict.md    — required
+  scorecard.md  — required for first audit; optional for re-audits
+```
+
+Subsequent audits may update findings.md and verdict.md in-place. The `last_audited` Health Block field in `SKILL.md` frontmatter is updated to today's ISO date after each audit.
+
+## Alternatives Considered
+
+**Integrate into CI gate:** Running the full audit as a CI gate was considered but rejected — the graded pass (LLM-powered) is too slow and expensive for every commit. The deterministic lint gate is the CI gate; the full audit is a periodic process.
+
+**Store findings in Linear only:** Rejected — audit artifacts in `audits/` provide an append-only local evidence trail that survives Linear data issues and is grep-able during grind sessions.
+
+**Weekly only:** Rejected — the per-task trigger is needed so that skills don't drift between the time a task modifies a skill and the next scheduled audit.
+
+## Consequences
+
+- The `audits/<skill-name>/` directory is now the canonical location for skill audit evidence in the `skill-graph` repo.
+- Agents working on skills must run the audit and triage findings before closing their Linear task.
+- P2 findings generate Linear sub-issues automatically; P3/P4 go in the completion comment.
+- The `skill-audit.js` cross-repo resolution bug (SH-6107 sub-issue) needs fixing before automated batch audits work reliably.

package/docs/adr/0008-skill-surface-split-and-curation-policy.md

@@ -0,0 +1,93 @@
+# ADR-0008: Skill Surface Split + Curation Policy
+
+**Status:** Accepted
+**Date:** 2026-05-18
+**Task:** SH-6125
+**Supersedes:** Portion of SH-6127 (Tier F mass migration)
+**Related:** SH-6114 (Finding F6), SH-6127 (rescoped)
+
+## Context
+
+Two skill surfaces coexist in `~/Development/`:
+
+| Surface | Path | Count | Schema status | Audience |
+|---|---|---|---|---|
+| **Outer** | `~/Development/skills/<name>/` | **263** active skills | Pre-v6 flat layout; `metadata:` wrapper on 0/263; Health Block on ~121/263 (~46%) | Personal library + Sales Hub skills, mixed with PII-adjacent and project-specific content |
+| **Nested** | `~/Development/skills/skills/<name>/` | **141** active skills | v6 compliant cohort, OSS-portable, canonical Skill Graph library | Public, generalizable, non-PII, non-Sales-Hub |
+
+This duality was flagged as Finding F6 in SH-6114 ("outer vs nested ambiguity"). SH-6127 originally scoped a Tier F mass migration of the 263 outer skills onto the v6 `metadata:`-wrapped layout, blocked on this architecture decision (SH-6125).
+
+Three options were on the table:
+
+- **Option A — Unify:** Migrate all 263 outer skills to v6, treat as one library
+- **Option B — Split cleanly:** Keep outer as personal/Sales Hub (frozen), nested as OSS-portable canonical
+- **Option C — Overlay:** Outer is a superset that includes nested as a view
+
+The implicit cost of Option A is migrating 263 mixed-purpose skills (many with PII, project-specific Sales Hub assumptions, or content that is not generalizable) to the v6 contract — work that produces no OSS value and locks Sales Hub doctrine into the public schema.
+
+Jacob's directive (2026-05-18) settles the question by removing the production assumption that motivated Option A:
+
+> PAUSE all production of skills for the personal library (`~/Development/skills/` top-level 263) and Sales Hub skills. Use non-PII, non-Sales-Hub personal skills as INSPIRATION for OSS additions. The 141 nested at `~/Development/skills/skills/` IS the active OSS-portable canonical library. The OSS Skill Graph repo (`~/Development/skill-graph/`) is the active development surface.
+
+## Decision
+
+**Adopt Option B (Split cleanly) plus a Curation Policy that governs how content moves between surfaces.**
+
+### Surface ownership
+
+| Surface | Status | Schema | Production | Audience |
+|---|---|---|---|---|
+| **Outer 263** | **Frozen** | Pre-v6 flat (no migration) | **No new production** | Personal + Sales Hub historical |
+| **Nested 141** | **Active** | v6 `metadata:`-wrapped, Skill Graph canonical | OSS contributions only, via curation | Public, OSS-portable |
+| **Sales Hub skills** | Separate concern | Lives in Sales Hub repo / scope | Owned by Sales Hub product surface | Tenant code, not OSS library |
+
+### Curation policy (outer → nested)
+
+A skill on the outer surface MAY be promoted into the nested OSS library only when ALL of the following hold:
+
+1. **Non-PII:** Contains no personal data, no real customer references, no internal-only contacts, no production identifiers
+2. **Non-Sales-Hub:** Not coupled to Sales Hub data model, routes, tenants, schema, or product-specific doctrine
+3. **Generalizable:** Useful to consumers outside this monorepo without rewriting the procedural guidance
+4. **Curation review:** Reviewed and approved against the v6 schema contract before promotion
+5. **Schema-compliant on arrival:** Promoted skill is authored (or rewritten) directly in v6 `metadata:`-wrapped layout — no migration codemod runs on the outer surface
+
+The curation flow itself is the rescoped scope of SH-6127 (see Consequences).
+
+### What this is NOT
+
+- This is **not** a deprecation of the outer 263. They remain on disk, remain readable by the agent, remain part of personal workflow. They are frozen with respect to **new production** and **schema migration**.
+- This is **not** a claim that the outer 263 is low quality. It is a claim that the outer surface mixes audiences in a way that makes a single schema contract counterproductive.
+- This is **not** a merge of the two surfaces. They remain distinct paths with distinct contracts.
+
+## Consequences
+
+### Cancelled work
+
+- **Tier F mass migration (original SH-6127 scope) is cancelled.** No v6 codemod will run across the 263 outer skills. No cohort selection pass for `comprehension_state: present` will happen on the outer surface. No mass Understanding-field hand-authoring for outer skills.
+- The Health Block walker work already completed on ~121/263 outer skills (commit `3e43f6e2`) remains in place as a one-time enrichment; it is not extended to the remaining ~142 outer skills as a migration goal. If a specific outer skill is later promoted via curation, it picks up Health Block fields as part of the v6 rewrite.
+
+### New work (rescoped SH-6127)
+
+- SH-6127 is rescoped to define and run the **curation pipeline**: outer → nested for non-PII, non-Sales-Hub, generalizable skills. The pipeline picks candidates, applies the v6 contract, and lands them in `~/Development/skills/skills/`.
+
+### Schema clarity
+
+- The nested 141 is now the single source of v6 truth in this monorepo. Any reference to "the v6 library" in Skill Graph docs, lint, manifest, or routing tooling means the nested surface.
+- The outer 263 is documented as a historical/personal surface on the pre-v6 flat layout. Tooling that targets v6 does not need to handle outer-surface compatibility.
+
+### Sales Hub boundary
+
+- Sales Hub skills are a separate concern: they live in the Sales Hub repo / scope and are owned by the Sales Hub product surface, not by Skill Graph. Skill Graph does not curate or migrate Sales Hub skills into the OSS library.
+
+### Reversal cost
+
+- If Jacob later decides to unify (Option A), the cancelled migration work can be revived — the policy here is "don't migrate now," not "migration is impossible." The outer 263 remain authored in their pre-v6 form, ready for codemod if ever needed.
+
+## References
+
+- SH-6125 — this architecture decision
+- SH-6127 — rescoped to curation pipeline
+- SH-6114 § Finding F6 — original outer-vs-nested ambiguity finding
+- Commit `3e43f6e2` — prior Health Block walker enrichment on 121 outer skills
+- `~/Development/skills/skills/` — nested 141, OSS-portable canonical library
+- `~/Development/skill-graph/` — active OSS development surface

package/docs/category-consumers.md

@@ -0,0 +1,168 @@
+# Category Consumer Audit (Phase 0c)
+
+> Status: Complete · 2026-05-16 · Phase 0c gate verdict **PASS**
+> Author: Opus 4.7 continuation session, post-Phase-1 v5 schema bump
+> Closes the Phase 0 gate trio (0a retrieval baseline · 0b sample-migration review · 0c consumer audit).
+> Reference: [`docs/plans/skill-taxonomy-v5-and-gap-fill.md`](/Users/jacobbalslev/Development/docs/plans/skill-taxonomy-v5-and-gap-fill.md) § Phase 0c
+
+## Brief
+
+Per the v5 plan: grep every file in `skill-graph/scripts/` and `Development/scripts/` for `category`, `domain`, and `family` reads. List downstream consumers. Confirm none hardcode the deprecated v4 strings (`knowledge`, `frontend`, `ai-engineering`, `integration`, `integrations`, `data`, `workflow`, `security`) as expected `category` values — anything that does will silently produce empty results under v5 because no skill carries those strings anymore.
+
+## Key finding up front
+
+**The v5 `category` closed enum cannot break any current Development consumer**, because the v5 137-skill library at `/Development/skills/skills/<name>/SKILL.md` and the v3 282-skill broader library at `/Development/skills/<name>/SKILL.md` are **physically separate directories with separate schemas, read by separate tooling**.
+
+```
+/Users/jacobbalslev/Development/skills/
+├── <282 v3 skills>/SKILL.md       ← read by Development/scripts/skill/* (v3 schema: type/family/layer)
+├── _meta/                          ← v3 registry / docs
+├── _archived/
+└── skills/
+    └── <137 v5 skills>/SKILL.md   ← read by skill-graph/scripts/* (v5 schema: closed-enum category)
+```
+
+The `walkSkillDir` in `Development/scripts/skill/skill-census.js` iterates direct children of `/Development/skills/` and skips namespace containers without a top-level `SKILL.md`. The nested `skills/` directory has no `SKILL.md` of its own and is therefore skipped — v3 tooling never sees v5 skills, and vice versa.
+
+Phase 5 (broader-library migration) will eventually merge these schemas; at that point the v3 consumers below will need updates. **That work is outside Phase 0c scope.**
+
+## Audit method
+
+```bash
+# Skill-graph (v5) consumers
+cd /Users/jacobbalslev/Development/skill-graph
+grep -rn --include='*.js' --include='*.ts' --include='*.mjs' \
+  -E '(\.category|\["category"\]|\.domain|\.family)' scripts/
+
+# v4-string hardcode sweep — must return only false positives
+grep -rn --include='*.js' --include='*.ts' --include='*.mjs' \
+  -E "['\"](knowledge|frontend|ai-engineering|integration|integrations|data|workflow|security)['\"]" \
+  scripts/
+
+# Development workspace
+cd /Users/jacobbalslev/Development
+grep -rn --include='*.js' --include='*.ts' --include='*.mjs' \
+  -E '(\.category|\["category"\]|\.domain|\.family)' \
+  scripts/skill/ scripts/docs/ scripts/lib/ scripts/infra/ scripts/memory/
+```
+
+Targets: all `.js`/`.ts`/`.mjs`/`.cjs` under each `scripts/` tree, excluding `node_modules`. False-positive filtering: `domain` matches for HTTP/API domain (not skill `domain`), `category` matches for error-pattern categories (not skill `category`), `family` matches for code-grouping family (not skill `family`).
+
+## 1. Skill-graph (v5) consumers
+
+These five files read `category`, `domain`, or `family` from v5 SKILL.md frontmatter. **All five are clean** — none hardcode deprecated v4 strings as expected `category` values.
+
+| File | Field(s) read | What it does | v5 status |
+| --- | --- | --- | --- |
+| `scripts/skill-lint.js` | `fm.category` (via check), `fm.domain_frame`, `fm.family` | Top-level lint orchestrator. Delegates `category` validation to `lint/check-category-enum.js`. Reads `family` for the family-naming guidance check (line 1084). Reads `domain_frame` for eval-mode validation (line 1050). | Clean ✓ |
+| `scripts/lint/check-category-enum.js` | `fm.category` | **Canonical v5 enforcement point.** Holds `CATEGORY_ENUM = Object.freeze(['foundations','engineering','design','quality','agent','product'])` and rejects anything not in the set. | Clean ✓ — enum matches `schemas/skill.schema.json` v5 definition. |
+| `scripts/generate-manifest.js` | `fm.category`, `fm.domain`, `fm.family`, `fm.domain_frame` | Pass-through fields. Writes `entry.category = fm.category` (line 273), `entry.domain = fm.domain` (line 279), aggregates `by_category` distribution at top of manifest (line 603), aggregates `by_family` (line 669). No expected-value comparisons. | Clean ✓ |
+| `scripts/migrate-category-to-enum.js` | `fm.category` (write), `fm.domain` (write) | The Phase 2 v4→v5 codemod. Has a MAPPING table; reads current values and writes new closed-enum values + populates `domain`. One-shot tool — no longer active. | Clean ✓ — already-applied codemod, retained for receipts. |
+| `scripts/__tests__/test-v3-1-alias-contract.js` | `fm.domain` | Asserts `entry.domain === fm.domain` (line 86) — passthrough test. No enum assumptions. | Clean ✓ |
+
+### Schema-level enforcement
+
+`schemas/skill.schema.json` (synced to v5 in `skill-graph` commit `f489641`) closes the enum at the schema level:
+
+```json
+"category": {
+  "type": "string",
+  "enum": ["foundations","engineering","design","quality","agent","product"],
+  "description": "Browse facet — answers 'where should a human browse to find this skill first?' Not ontology truth. Closed enum of 6 values in v5..."
+}
+```
+
+Both the schema and the lint constant are sources of truth and currently match exactly.
+
+### v4-string sweep in `skill-graph/scripts/` — verified zero hits
+
+```
+grep -rn -E "['\"](knowledge|frontend|ai-engineering|integration|integrations|data|workflow|security)['\"]" scripts/
+→ scripts/lib/mock-grader.js:25:  process.stdin.on('data', (chunk) => { ... });   [FP: Node stream event name]
+→ scripts/__tests__/test-v3-1-alias-contract.js:96:  archetype: 'workflow'         [FP: legacy archetype value, not category]
+```
+
+Two matches, both false positives. **Zero consumers hardcode v4 category strings.**
+
+## 2. Development workspace consumers
+
+These files read `category`, `domain`, or `family` from frontmatter, but they operate on the **v3 broader library** (282 skills at `/Development/skills/<name>/`), not the v5 137-skill library. They use the v3 schema's `type`/`family`/`layer`/`primaryCategory`/`layerPrimary` fields — not the v5 `category` closed enum.
+
+| File | Field(s) read | Operates on | v5 impact |
+| --- | --- | --- | --- |
+| `scripts/skill/skill-census.js` | `frontmatter.type`, `frontmatter.category` (as v3 alias for type, line 246), `frontmatter.family`, `frontmatter.domain_frame`, `frontmatter.layer`, `frontmatter.primaryCategory`, `frontmatter.layerPrimary` | v3 library via `SKILL_DIRS.shared = ROOT_DIR/skills` | **None** — never sees v5 skills (nested `skills/` namespace skipped by walker, see lines 105–108). Holds VALID_FAMILIES, VALID_PRIMARY_CATEGORIES, VALID_LAYER_PRIMARY sets that include v3-era values (`'integration'`, `'workflow'`, `'knowledge'`); these are v3 enums, not v4 category values. |
+| `scripts/skill/skill-lint.js` (Dev, separate from skill-graph's lint) | `frontmatter.type`, `frontmatter.family` | v3 library | **None** — `VALID_TYPES` (line 187) includes `'knowledge'`, `'workflow'`, etc. as `type` values, not `category` values. |
+| `scripts/skill/backfill-skill-taxonomy.js` | `frontmatter.family`, `layerPrimary` writes | v3 library | **None** — references `'integration'`, `'frontend'`, etc. as v3 family/layer/router names. Hardcoded routerNames set at line 96 (`['backend','frontend','events','legal']`) — `'frontend'` here is a router-bundle name, not a category. |
+| `scripts/skill/skill-graph-builder.js` | maps `*-skill` names to `'integration'` group (lines 107–113) | v3 library | **None** — `'integration'` used as a skill-graph node group label, not a v5 category. |
+| `scripts/skill/skill-app-coverage-matrix.js` | `route.domain` | API routes, not skills | False positive — `domain` here is the URL prefix (e.g. `/api/orders` → `orders`). |
+| `scripts/skill/bulk-eval-tagger.js` | `frontmatter.family`, `frontmatter.layer`, `frontmatter.primaryCategory` | v3 eval frontmatter | **None** — `'integration'`, `'workflow'`, `'security'`, `'design'` etc. used as eval `type` values, not skill `category`. |
+| `scripts/skill/migrate-archetype-structure.js` | `frontmatter.family` (read/write) | v3 archetype migration | **None** — operates on v3 family field. Maps `'error-tracking' → 'knowledge'` (line 20) where `'knowledge'` is a v3 family value, not a v5 category. |
+| `scripts/skill/skill-families.js` | `frontmatter.family` | v3 library | **None** — family-based grouping commands. |
+| `scripts/skill/build-skill-audit-worklist.js` | `skill.family`, `skill.primaryCategory` | v3 census output | **None** — line 82 checks `skill.family === 'agent-ops' \|\| skill.family === 'skill-system'` — these are v3 family values; `'agent-ops'` and `'skill-system'` are still active under v3. |
+| `scripts/skill/skill-leverage-ranker.js` | `skill.family` (via signals) | v3 census output | **None** |
+| `scripts/skill/domain-context-populator.js` | `frontmatter.family`, `frontmatter.domain_frame` | v3 library | **None** |
+| `scripts/skill/eval-linter.js` | `skill_type: 'knowledge'` example (line 38) | doc example | **None** — example placeholder, not a v5 enum check. |
+| `scripts/skill/source-truth-catalog.js` | `category: 'http' \| 'database' \| ...` for code-pattern catalog | source code patterns | False positive — code-pattern catalog has its own `category` taxonomy unrelated to skill `category`. |
+| `scripts/memory/session-log.js` | `category: ROOT_CAUSE_CATEGORIES.*` for finding-pattern detection | session log findings | False positive — finding-classification `category`, not skill `category`. |
+| `scripts/docs/file-size-scanner.js` | `category` table column for file-type classification | file scan | False positive — file-type `category`, not skill `category`. |
+
+### Cross-schema risk: `skill-census.js:246`
+
+```js
+type: frontmatter.type || frontmatter.category || "knowledge",
+```
+
+This is the only Development consumer that reads `frontmatter.category` directly. In v3 schema, `category` was an accepted alias for `type` (per the comment at line 178). The `"knowledge"` ultimate fallback is a v3-era default.
+
+Risk under v5: if census ever iterates v5 skills (it doesn't today, see walker analysis above), it would see `frontmatter.category` ∈ {foundations, engineering, ...} and assign that to the census output's `type` field. Census would then report v5 skills with `type: "engineering"` etc., which is invalid under v3's `VALID_TYPES` and would fail downstream validation.
+
+**Today this code path is unreachable** because census doesn't iterate v5 skills. It becomes relevant only when Phase 5 merges the two libraries.
+
+## 3. Documentation drift discovered
+
+### `scripts/lint/check-category-enum.js` — stale header comment
+
+Lines 4–22 of the file say:
+
+> The schema allows `category` to be any string for backward compatibility, but the Skill Graph policy (as of 2026-05-15) is that the field functions as a browse facet, not ontology truth, and must take exactly one of six canonical values. … Closing the schema enum requires a v5 schema bump that cascades through manifest schemas, generators, and downstream consumers. The lint check achieves the same enforcement guarantee with no version churn.
+
+This rationale was correct **before** Phase 1. As of 2026-05-16 (Phase 1 schema bump, commit `f489641`), the schema has been bumped to v5 and **does** close the enum at the schema level. The lint check is now redundant-but-correct rather than the sole enforcement point. The comment should reflect post-v5 reality. Low-priority cleanup.
+
+### `scripts/skill-lint.js:187` (Development copy) — `VALID_TYPES` includes `'knowledge'`, `'domain'`
+
+```js
+const VALID_TYPES = ["capability","workflow","hybrid","doctrine","framework","strategy","overlay","skill","domain","system","knowledge","operational"];
+```
+
+These are v3 `type` field values, not v5 `category` values, so they're not breaking. But the values `'knowledge'`, `'domain'`, `'system'` are awkward as types and overlap with v5 category names. Not actionable until Phase 5.
+
+## 4. Follow-up list
+
+These are small cleanups identified during the audit. None block Phase 1 or Phase 5; they can be picked up in any wrap pass.
+
+1. **`skill-graph/scripts/lint/check-category-enum.js` header comment** — update lines 4–22 to reflect that v5 schema bump landed and the enum is closed at both schema and lint level. (~5 lines edit.) **RESOLVED 2026-05-17** — header rewritten to describe the dual-layer (schema + lint) enforcement and the three-place update protocol when the enum changes.
+2. **`Development/scripts/skill/skill-census.js:246` fallback** — replace `frontmatter.category || "knowledge"` with `frontmatter.category || null` or drop the fallback entirely. Currently inert (unreachable under v3-only iteration) but misleading. Defer to Phase 5 when census becomes v5-aware. **RESOLVED 2026-05-17** — code path preserved (changing fallback string risks downstream consumers expecting always-a-string `type`); added an inline comment that documents the v3-era origin, why the path is currently unreachable, and what will need to change when Phase 5 makes it active. The actual fallback rewrite is now owned by the Phase 5 prerequisite step (see v5 plan).
+3. **Phase 5 prerequisite** — when the 287-skill broader library migrates to v5, every entry in §2 above will need a schema-aware update. Recommend a follow-up audit at Phase 5 kickoff that re-runs the greps above against the merged library. **RESOLVED 2026-05-17** — added as an explicit prerequisite step at the top of Phase 5 in `docs/plans/skill-taxonomy-v5-and-gap-fill.md`, with the specific known-mandatory updates called out (census.js:246, `VALID_TYPES`/`VALID_FAMILIES`/`VALID_PRIMARY_CATEGORIES` constants).
+
+## Phase 0c gate verdict
+
+**PASS.** The closure of the v5 `category` enum does not break any current Development consumer. The two physical libraries are independent. The skill-graph v5 consumers (§1) are five files, all clean. The Development v3 consumers (§2) read a different field on a different schema in a different directory.
+
+The Phase 0 gate trio is now complete:
+
+- **Phase 0a (retrieval baseline)** — committed in skill-graph `0e5ad55`, 30 queries, 20% agent-router agreement (single-rater).
+- **Phase 0b (sample-migration review)** — committed in skill-graph `89e8115`, 30 skills, 26/30 = 86.67% reviewer-agreement, passes 85% gate.
+- **Phase 0c (consumer audit)** — this document. Zero breaking consumers.
+
+Phase 1 (schema bump) landed clean. Phase 5 (broader library migration) is unblocked from a consumer-safety perspective and can proceed when prioritized.
+
+## Critical files referenced
+
+- `/Users/jacobbalslev/Development/skill-graph/scripts/skill-lint.js`
+- `/Users/jacobbalslev/Development/skill-graph/scripts/lint/check-category-enum.js`
+- `/Users/jacobbalslev/Development/skill-graph/scripts/generate-manifest.js`
+- `/Users/jacobbalslev/Development/skill-graph/scripts/migrate-category-to-enum.js`
+- `/Users/jacobbalslev/Development/skill-graph/schemas/skill.schema.json`
+- `/Users/jacobbalslev/Development/scripts/skill/skill-census.js`
+- `/Users/jacobbalslev/Development/scripts/shared/workspace-paths.js`
+- `/Users/jacobbalslev/Development/docs/plans/skill-taxonomy-v5-and-gap-fill.md`