Conciseness

Every line states an invariant or rule ("The scripts rewrite only the marked sections, so people can edit the rest of the body", "It is never re-filed") with no padding and no explanation of concepts Claude already knows, such as what GitHub issues are. This matches anchor 5 (lean, assumes competence, every token earns its place) rather than anchor 4's "minor instances of over-explanation".

Actionability

The guidance is fully concrete for an instruction-only skill: exact markers ("<!-- fragility-plan:start ... -->", "<!-- fragility-finding {json} -->"), the exact label, three accepted key formats ("#<n>", bare number, issue URL), precise close-state reasons ("closed as not planned or duplicate"), and the named commands to use (findings-doctor, findings-match, findings-upsert). Specific rules cover all the common lifecycle cases, matching anchor 5; there are no missing key details that would drop it to anchor 4.

Workflow Clarity

The lifecycle semantics are coherent (sighting to comment with cooldown, new plan replaces the marked section, fixed closes as completed with a recurrence issue, declined is never re-filed) and validation tooling is named via findings-doctor and the auth/access prerequisites. However, for the description's second trigger, "changing that mapping", there is no explicit step sequence or checkpoint, which fits anchor 4 (clear with minor validation gaps) rather than anchor 5's explicit feedback loops.

Progressive Disclosure

The body is under 50 lines, self-contained, and well organized into settings and a per-state mapping section, with the one cross-skill reference (factory-run) clearly signaled by name. The bundle's scripts/ (github.ts, tracker.ts) are implementation loaded by fragility-common's machinery rather than documentation to disclose, so inlining or referencing them would add tokens without value; this matches the simple-skill case for anchor 5.

Specificity

"issues labeled refactor-findings in the fragility repo, with the plan in the body" names the domain and its concrete artifacts, but the description defines what the skill is rather than listing several actions it performs. It is above anchor 2 because the identifying details are concrete (label, repo, plan location), and below anchor 4 because there is no multi-action capability list.

Completeness

Both halves are explicit: the what ("The GitHub issues tracker for refactor findings: issues labeled refactor-findings in the fragility repo, with the plan in the body") and a concrete when clause ("Read when fragility-common/config.json sets tracker to github and you need to know how findings map onto issues, or when changing that mapping"). This clearly matches the anchor-5 example structure with concrete trigger conditions, not the less-explicit when of anchor 4.

Trigger Term Quality

Natural phrases a user in this codebase would say are present: "GitHub issues tracker", "refactor findings", "tracker to github", "findings map onto issues". A few natural variations (e.g., "tickets", "issue tracker") are missing, so it fits anchor 4 rather than the comprehensive synonym coverage of anchor 5.

Distinctiveness Conflict Risk

The niche is sharply delimited by the refactor-findings label, the fragility repo, and the config.json tracker setting, so it is unlikely to trigger for the wrong skill. This matches anchor 5 (clear niche with distinct triggers, minimal conflict risk); anchor 4's "minor overlap risk" does not apply given the internal-scope gating.