Conciseness

Dense, GitNexus-specific operational guidance with no padding and no explanations of concepts Claude already knows (e.g., 'Bind once per session using a confirmed registry name/path... Call `list_repos {}` when the target is not yet known, not before every question'). Falls short of 5 because a few rules are repeated three to four times across sections — index-freshness reporting and 'read a process resource only when needed' each appear in the workflow, the evidence section, the checklist, and the example.

Actionability

Concrete, near copy-paste tool calls with exact parameter shapes ('query({search_query: "payment processing", repo: "my-app", limit: 3, max_symbols: 3})'), a runnable re-index command ('node .gitnexus/run.cjs analyze'), resource URIs, and a fully worked end-to-end example. Not 5 because the secondary tools `trace` and `read_file` are recommended ('Use `trace` for a known A→B path', 'prefer `read_file` with a small 0-based `startLine`/`endLine` window') without call syntax, leaving minor gaps.

Workflow Clarity

A numbered workflow, a checklist, explicit validation checkpoints (hot-tool staleness with a decision rule 'Re-analyze only for `behind` or `diverged`', reading `response_filter`, `warning`, `partial`, `truncated`, `epistemic` and `staleness` metadata), and feedback loops for error recovery (remove filters when broader evidence is needed; 'narrow the request rather than treating a cut response as complete'; 'stop and ask' on ambiguity). This matches the anchor with explicit validation steps, feedback loops, and a checklist.

Progressive Disclosure

A single-file skill with no bundle files (no references/, scripts/, or assets/ exist), organized into clear sections (When to Use, Bind the repository, Workflow, evidence guidance, Checklist, Resources table, Tools, Example) with nothing buried or nested. Not 5 because the ~131-line body keeps all reference-style material (Resources/Tools) inline rather than splitting any out, though at this size that is only a minor organization gap; not 3 because no content that clearly belongs in a separate file is inlined and navigation is easy.

Specificity

Phrases like 'trace execution flows', 'understand architecture', and 'explore unfamiliar parts of the codebase' list several specific actions in the code-exploration domain, reinforced by concrete example queries ('What calls this function?'). Not 5 because the stated actions are user intents rather than the skill's concrete capabilities (what it actually does is never stated); not 3 because multiple distinct actions are named rather than just one or two.

Completeness

The 'when' is explicit and concrete ('Use when the user asks how code works...'), but the 'what' is never explicitly stated — the description only enumerates user intents and never says what the skill does (e.g., query an indexed repository for symbols and call relationships). This matches anchor 3 (what only weakly implied) rather than 4, which requires both explicitly; not 2 because the enumerated intents and example queries convey far more than a bare 'Use when' clause.

Trigger Term Quality

Includes natural phrases a user would say verbatim — 'How does X work?', 'What calls this function?', 'Show me the auth flow' — plus synonyms across the clause ('how code works', 'understand architecture', 'trace execution flows', 'explore'). Coverage of natural trigger phrasing is comprehensive, matching the top anchor rather than the 'a few natural terms missing' anchor below it.

Distinctiveness Conflict Risk

Triggers like 'What calls this function?' and 'Show me the auth flow' are specific to codebase exploration and mostly distinct, with only minor overlap risk against closely related code-analysis or code-review skills. Not 5 because 'asks how code works' and 'explore unfamiliar parts of the codebase' are broad enough to overlap with other general code skills.