Skill Unification + Canon Audit — 2026-08-14

Package: mizoki-skill-unification-v1.0 · Branch on install: claude/skill-unification-mcp-v1.0 Status: built and verified in a Cloud session. Not pushed — no repo credentials (see §5).

1. What the open issue actually was

The Aug 14 inventory left one gap: do the 11 custom skills live in the repo, or only at the account level? The answer turned out to matter less than what the investigation found.

The skill bodies were readable from the session's synced cache (/root/.claude/skills/synced/). Reading them surfaced a real defect: miz-oki-platform-expert v3.0 still carries the plan-vintage cell map that the owner corrected on 2026-08-11 and that the v2.2 compliance sweep enshrined as canon. Its own prose states the corrected mapping in four places, while its cell-architecture diagram states the wrong one. A skill that contradicts itself will teach whichever half the reader reaches first.

This is precisely the "skill-delta item for Boss, same-day parity" the compliance prompt anticipated. It could not be found by the repo sweep, because the sweep audits repo files and these skills are account-synced.

2. Findings

Sixteen canon rules were run across all 11 skills, 13,000+ lines. Six HIGH findings, all in miz-oki-platform-expert, all now fixed. Full diff: PATCH_canon_v2.2.diff.

Rule Location Was Now
V4a SKILL.md:171 Cell 28: LII Intent Scoring API (the ORACLE "crystal ball"; formerly Reserved) Cell 28: legacy cell — NEVER intent scoring, never repurposed
V4b SKILL.md:173 Cell 35: Incrementality & Causal Credit Cell 36: intent-causal — incrementality & causal credit
V4c SKILL.md:166 LEARN (… + Cell 34) … (34 = LII intent graph) LEARN (… + Cell 35) … (35 = intent-graph)
V4d SKILL.md:172–175 Cells 34, 36, 37 absent from the directory all three added, incl. Cell 37 Data Injector
V7 SKILL.md:35 Neo4j/TigerGraph (knowledge graphs) Neo4j (knowledge graph)
V1 SKILL.md:1069 Grafana dashboards per SRDAL stage …per SRPVDAL phase

Cell 37 (Data Injector) was absent from every skill in the corpus — the newest cell existed nowhere in the expert layer.

Left for your judgment (not auto-fixed)

10 MEDIUM + 5 LOW findings remain, deliberately:

Two false positives the linter had to learn

Worth recording, because both would have produced exactly the wrong action:

  1. formerly was excusing violations. Cell 28: Intent Scoring (formerly Reserved) is a live claim, not a correction notice. Narrowed to formerly known as|called|named.
  2. Rule V4c did not exist, so (34 = LII intent graph) passed clean. Found by reading the block, not by trusting the tool. The linter is a floor, not a ceiling.

3. The unified channel

One path in, one path out, drift detectable:

skills/<name>/SKILL.md          canonical — the only place you edit
        ↓ skill_sync.py --sync
.claude/skills/<name>/          derived for Claude Code — never edit
skills/registry.yaml            generated index: version, digest, triggers
        ↓
mcp/mizoki_skills_mcp/          same corpus over MCP — Boss agent, ChatGPT, any host

scripts/mizoki_canon.py holds the canon as code — 16 rules plus the positive statement of truth (cell map, SRPVDAL phases, promotion gates, governance hard gates, retired model strings). The audit, the tests, and the MCP server all import that one module, so the canon cannot drift between them.

scripts/skill_sync.py supersedes ontology_skill_sync.py (one skill → whole corpus), keeping the --check contract so existing pre-merge hygiene still works:

Command Purpose
--check parity + registry currency · exit 1 on drift
--sync regenerate derived copies + registry
--audit lint corpus against canon · exit 1 on HIGH
--export DIR portable bundle + manifest.json for non-Claude hosts

4. The MCP server — same capabilities, any host

mizoki-skills-mcp serves the corpus rather than forking it. Skills stay the source of truth; the server is a second doorway to the same room.

Tools (7): skills_list · skills_get (with section filtering to keep context small) · skills_route (task → specialist) · skills_search · canon_rules · canon_check (lint any draft before it ships) · skills_parity_check

Resources (4): mizoki://registry · mizoki://canon · mizoki://skills/{name} · mizoki://skills/{name}/refs/{file}

skills_parity_check is the tool miz-oki-platform-expert already tells the Boss agent to call ("Verify anytime via skills_parity_check"). It now exists.

Router accuracy is tested against 6 probes; each resolves to the correct specialist:

Task →
fix Meta CAPI event match quality meta-programmatic-acquisition
IP warmup schedule for a new sending domain email-deployment-ip-warmup
set up GA4 BigQuery export ga4-expert
entity resolution across the Neo4j graph ontology-kg-virtuoso
Performance Max campaign structure adwords-virtuoso
cap table dilution after the SAFE converts investor-virtuoso

Transports: stdio for local hosts, streamable HTTP (--http --port 8080) for remote. Host configs for Claude Desktop and the repo are in mcp/config/.

This is also the cleanest ChatGPT path. Rather than pasting instructions into Custom GPTs that immediately begin to diverge, point ChatGPT at this server (or serve --export output behind the HTTP transport). One corpus, one canon, every surface.

5. Verification

Gate Result
skill_sync.py --check parity OK — 11 skills, derived match, registry current
skill_sync.py --audit 15 findings, 0 HIGH · exit 0
pytest tests/ 34 passed
MCP --selftest 11 skills loaded, parity true, 16 rules, router OK
Drift injection detected and reported correctly
Orphan derived copy detected and reported correctly

test_corpus_has_no_unreviewed_high_findings is a build gate — it failed before the patch and passes after, so this defect class cannot be silently re-merged.

Not done: nothing is pushed. This Cloud session has no MIZOKICloudRun credentials, and the desktop VM's proxy blocks github.com. See the setup note delivered alongside this report.

6. Scope decisions taken

← All docsView source on GitHub →