Conciseness

The instructional content itself is lean and assumes competence — finding definitions, the demolition test, and report structure are all stated without padding — but decorative nautical metaphor is sprinkled throughout ("A surveyor charts the reef; the captain decides whether to dredge", "weight the walk toward the yard's busy water", "the captain reads one card, not the whole reef", "it simply sinks"), and each instance costs tokens without adding instruction. Not a 2 because no section explains concepts Claude already knows and the body is short; not a 4 because the metaphorical padding recurs in nearly every section and could be cut.

Actionability

The guidance is concretely executable for an instruction-only skill: a three-step procedure, mechanically checkable heuristics ("a boundary crossed by exactly one adapter with no second caller; checkable by counting callers"), a falsifiable demolition test applied to every suspect, and a fully specified report format (evidence at file:line, one-sentence deepening move, risk note, top recommendation). Not a 5 because there is no worked example of a finding or a sample candidate card, which would make the report contract unambiguous.

Workflow Clarity

The sequence is clear and ordered: read principles and seam vocabulary → walk the module graph (with an explicit weighting rule via commit history) → classify findings → apply the demolition test filter → rank by leverage against risk → report → handoff. The demolition test acts as a per-suspect checkpoint and the completion definition ("report exists with evidence, rankings, and risk notes — and no file was modified") is an explicit end-state check. Not a 5 because there are no feedback loops or mid-survey error-recovery steps, though the skill is non-destructive so the validation cap does not apply.

Progressive Disclosure

This is a compact single-purpose skill (~50 lines) with no bundle files (no references/, scripts/, or assets/ exist), and the body is organized into six well-labeled sections (When to survey, The survey, The report, Handoff, Non-goals, Completion definition) that are easy to navigate. The only file paths mentioned (CLAUDE.md, ADRs, docs/standards/architecture.md) are artifacts of the repo being surveyed, not skill-bundle references, so no nesting or splitting is needed.

Specificity

The description lists several concrete actions — "walks the module graph", "reports ranked deepening candidates" — and enumerates the three finding classes ("shallow modules, hypothetical seams, logic behind the wrong seam") plus an explicit boundary ("it never refactors on its own"). It stops short of a 5 because the actions are stated in domain jargon rather than operational terms, leaving minor gaps in what the survey actually produces.

Completeness

The "what" is clear (walk the module graph, report ranked deepening candidates), but the "when" is only weakly implied by the single word "Periodic" — there is no "Use when..." clause or equivalent explicit trigger guidance, which the guidelines say caps completeness at 3. Not a 2 because the "what" half is specific and complete, not vague.

Trigger Term Quality

"Periodic architecture survey" and "module graph" are relevant keywords a user might plausibly say, but natural variations users would actually utter ("refactoring candidates", "code health", "technical debt", "deep modules") are absent, and the metaphorical framing ("hands them to the captain", "rescue") works against natural trigger phrasing. Not a 4: coverage is thin and no synonyms or explicit user-facing trigger phrases appear.

Distinctiveness Conflict Risk

The niche is fairly distinct — an architecture survey with named finding classes and an explicit "never refactors" boundary separates it from refactoring and code-review skills. Minor overlap risk remains with general code-review or audit skills since "architecture survey" alone doesn't fully disambiguate; not a 5 because the finding-class jargon, while distinctive, is internal vocabulary rather than a clearly staked trigger territory.