Conciseness

Every token carries measured, non-obvious, repo-specific facts Claude cannot know — "costs roughly 4,700 additional modules (measured; re-measure with `--verbose`)", "takes `tsc --noEmit` from 12.6s to 8m07s — a 38x regression", "the registry contains one (`stt_deepgram_v2`)", "a few hundred tools are versioned". No padding, no generic concept explanations; rationale sentences exist only to prevent specific regressions (e.g., the .json-import cleanup trap). Fits the 5 anchor: lean, assumes competence, every token earns its place.

Actionability

Fully executable, copy-paste-ready guidance throughout: exact commands (`bun run generate:tool-metadata`, `bun run check:tool-metadata`, `bun run check:tool-registry-boundary` with `--verbose`, `--check`, `--update-baseline`), exact module paths in the import table with sizes, and a concrete test-mocking snippet (`vi.mocked(getToolMetadata).mockImplementation(toolsMetadataMock.getToolMetadata)`). Matches the 5 anchor: specific examples cover the common cases.

Workflow Clarity

Multi-step processes are clearly sequenced with explicit validation checkpoints and feedback loops: regeneration ends in "what CI runs; fails if stale"; guard failure has recovery guidance ("do not add the entry to an allowlist — there isn't one. Find the symbol the offending file actually needs and move it"); mock verification uses a sentinel check ("change a fixture value to a sentinel and confirm the test fails"); edge verification ends with "Compare the reachable module count before and after". Matches the 5 anchor: clear sequence, explicit validation, error-recovery loops.

Progressive Disclosure

A single ~96-line file with no bundle files and well-organized sections (rule, import table, generated artifacts, testing, guard/baseline, verification, new-caller policy). All content is core operational guidance needed nearly every time the skill fires; nothing clearly belongs in a separate file, and splitting it would add indirection without token savings. Navigation via headers and the decision table is easy. Fits the 5 anchor's spirit (content appropriately placed) even though no external references are warranted.

Specificity

Lists multiple specific concrete actions — "when to read `@/tools/metadata` instead of `getTool`, how to measure whether an import edge pulls the registry, and how to regenerate the metadata artifacts" — with comprehensive coverage of the skill's capabilities, matching the anchor for multiple specific concrete actions. Not 4: there are no gaps in action coverage; every capability of the skill is named.

Completeness

Explicitly answers both: the "what" ("Keep the executable tool registry out of client-reachable module graphs", when to read metadata instead of getTool, how to measure, how to regenerate) and the "when" ("Use when touching `apps/sim/tools/registry.ts`, `tools/utils.ts`, `tools/params.ts`, or anything that calls `getTool`") with concrete trigger phrases. Exact match for the 5 anchor.

Trigger Term Quality

The trigger set is precise and natural for this codebase — "Use when touching `apps/sim/tools/registry.ts`, `tools/utils.ts`, `tools/params.ts`, or anything that calls `getTool`" — but misses common natural phrasings such as "adding or changing a tool" (which requires regeneration) and the CI check names. Fits the 4 anchor (good keyword coverage; a few natural terms missing) better than 5 (comprehensive coverage including synonyms).

Distinctiveness Conflict Risk

Clear niche with distinct triggers — "executable tool registry", "client-reachable module graphs", specific file paths and the `getTool` function name — making it highly unlikely to fire for any other skill. Minimal conflict risk; matches the 5 anchor.