Conciseness

The body is lean and every section carries tool-specific facts Claude cannot know (MCP parameter combinations, CLI flags, exit codes, the GNU Parallel name conflict, legacy verb aliases). Not 4: there is no over-explanation of concepts Claude already knows to trim; the parallel MCP/CLI listings cover distinct invocation surfaces rather than padding.

Actionability

All guidance is copy-paste ready: complete CLI commands with flags and expected output shapes ("definition: type name file:line", "exit 0 pass, 1 fail, 2 could not decide"), MCP calls with concrete parameter values ("query: 'X', mode: 'context'"), and a worked ASCII-tree example. Not 4: the examples cover the common cases completely.

Workflow Clarity

Task-to-command mappings are unambiguous via two tables, with an explicit precedence rule ('If the agent has the sem MCP server... call those instead of running sem in a shell'), fallback behavior, and an install-conflict check. The skill is a lookup/reference skill with no destructive or batch operations, so no validation checkpoints are required. Not 4: the decision flow (MCP first, CLI fallback, version check) is fully explicit.

Progressive Disclosure

Sections are well-organized (questions table, MCP routing, CLI reference, output-formatting rules, install check) and nothing is a wall of text, but there are no bundle files or references at all — the full CLI syntax reference is inlined in a ~130-line SKILL.md. Not 5: the body exceeds the under-50-line simple-skill exception and the CLI reference block could live in a references file; not 3: structure is clear and content is appropriately dense, with nothing misfiled.

Specificity

The description names five concrete actions with their commands ("sem find, sem grep", "sem impact", "sem check", "sem certify") covering all four capability areas, matching the anchor 'Lists multiple specific concrete actions; comprehensive coverage'. Not 4: coverage is comprehensive rather than having minor gaps.

Completeness

It explicitly answers what ("entity-level (function/class/method) code questions in any Git repo. Four questions, four verbs...") and when ("Trigger whenever the user asks where something is defined or called...") with concrete trigger phrases. Not 4: the 'when' clause is fully explicit, not merely present.

Trigger Term Quality

Natural phrases users would say are covered with synonyms: "where something is defined or called", "what a change breaks or which tests to run", "whether a change is correct", "what changed in a commit or PR", "what to review", plus proactive contexts ("before refactors and in code review"). Not 4: no common variation is noticeably missing.

Distinctiveness Conflict Risk

The niche (entity-level semantic code analysis, contrasted with 'line-level git output is noisy') is mostly distinct, but broad triggers like "what changed in a commit or PR" and "what to review" overlap with generic git/code-review skills. Not 5: minor overlap risk with closely related skills remains; not 3: the tool and its verbs are clearly differentiated.