Conciseness

The body is lean and assumes competence — no space is spent explaining what breaking changes or OpenSpec are; sections are compact bullet lists and short steps. It is not a 5 because the "What is covered" bullet list substantially duplicates the surface enumeration already in the description, and lines like "**This is an interactive SKILL**" add little; it is well above a 3 since there is no concept over-explanation or padding.

Actionability

For an instruction-only skill the guidance is concrete: a mandated reference read ("MUST read references/056-design-avoid-breaking-changes.md before producing compatibility guidance"), an explicit classification taxonomy ("BREAKING, POTENTIALLY BREAKING, NON-BREAKING, or UNKNOWN"), and a defined report shape (reviewed sources, severity-ranked findings, validation guidance). It stops short of a 5 because steps like "Check commands, skills, generated outputs..." remain high-level pointers with no worked example, checklist, or command inline — the executable detail is deferred entirely to the reference file.

Workflow Clarity

Five clearly sequenced steps (read reference → inventory surfaces → classify → recommend migration → report) each carry concrete sub-instructions, and step 3 requires "validation evidence or missing evidence" per finding. It is not a 5 because there is no explicit feedback/checkpoint loop (e.g., verifying the inventory was complete or that each classification has evidence before reporting); it is not a 3 since the sequence is complete and step 3 embeds an evidence requirement.

Progressive Disclosure

The body is a pure overview: scope bullets, constraints, triggers, a 5-step workflow, and a single clearly-signaled one-level-deep reference — [references/056-design-avoid-breaking-changes.md](references/056-design-avoid-breaking-changes.md) — which exists as a real file containing the detailed guidance with no further nested references. This matches the anchor of a clear overview with well-signaled, one-level-deep references and easy navigation.

Specificity

The description grounds itself in concrete review surfaces ("commands, skills, generated outputs, XML sources, README/docs, tests, CI, APIs, schemas, configuration, data, migration, and release guidance") and a clear action ("review a plan, OpenSpec change, specification, or implementation proposal for breaking-change risk"). It falls short of a 5 because it names essentially one action verb (review/assess) rather than multiple distinct capabilities, and above a 3 because the enumerated coverage goes well beyond naming a domain with 1-2 actions.

Completeness

Both questions are answered explicitly: the "what" is "review ... for breaking-change risk across" a concrete list of surfaces, and the "when" opens with "Use when you need to review a plan, OpenSpec change, specification, or implementation proposal" plus five literal trigger phrases. It matches the anchor 5 example pattern (what + explicit 'Use when' with concrete trigger phrases); it is not a 4 because the 'when' is not merely present but spelled out with quoted request examples.

Trigger Term Quality

It quotes natural user phrasings — "Review breaking changes in this spec; Check compatibility risks; Avoid breaking changes in this OpenSpec change; Review migration impact before release; Assess command and skill compatibility" — which are phrases a user would plausibly say. Not a 5 because common synonyms like "backward compatibility" or "deprecation risk" are absent, leaving a few natural trigger variants uncovered.

Distinctiveness Conflict Risk

The niche — breaking-change/compatibility review of OpenSpec changes and implementation proposals — is well-differentiated with distinct trigger phrases. It is not a 5 because the broad surface list (APIs, schemas, configuration, CI) creates minor overlap risk with general code-review or migration-review skills.