Lean instruction skill with no concept-tutoring or padding; every section (Constraints, When to use, Workflow, Reference) earns its place and assumes Claude's competence. Not a 2 because there is no unnecessary explanation of known concepts, only mild overview/workflow overlap that aids scanning.

Gives concrete commands — `openspec --version`, `openspec init`, `openspec validate --all` — plus specific artifact types (proposal, design, specification deltas, tasks) and named approval gates. Not a 2 because, as an instruction skill, the guidance is specific and actionable rather than vague or pseudocode.

Six clearly sequenced steps with explicit validation checkpoints (steps 5 'Validate authority and alignment' and 6 `openspec validate --all`) and approval/conflict-resolution gates ('require alignment review plus an explicit user decision before propagation'). Not a 2 because validation and feedback gates are explicit, not merely implied.

Well-organized overview in SKILL.md pointing one level deep to references/042-planning-openspec.md (a real, verified file) signaled in both step 1 and the Reference section. Not a 2 because the split is clean and navigation is clearly signaled with no nested-reference chains.

Lists multiple concrete actions — 'creating or updating OpenSpec change artifacts', 'assesses whether the scope is one change or multiple changes', 'records sources and derivation direction', 'prevents silent synchronization' — matching the 'lists multiple specific concrete actions' anchor. Not a 2 because it goes well beyond naming a domain and a few actions.

Explicitly answers both: 'Use when creating or updating OpenSpec change artifacts...' (when) and 'The workflow assesses... records sources... prevents silent synchronization' (what), plus a 'This should trigger for...' clause. Not a 2 because the 'when' is explicit via a 'Use when' clause, not implied.

Provides natural user-request phrasings — 'Create an OpenSpec change from an issue; Convert a plan into OpenSpec; Update an existing OpenSpec change; Split broad requirements into reviewable OpenSpec changes' — that a user would naturally say. Not a 2 because it covers multiple common request variations rather than a single keyword.

Occupies a clear niche — OpenSpec change-artifact planning — with distinct triggers unlikely to fire for unrelated skills. Not a 2 because the OpenSpec-specific triggers are far from generic 'works with files' overlap.