Conciseness

Nearly every token carries non-obvious operational detail (store flag stickiness, "root": null semantics, existingOutputPaths vs resolvedOutputPath) with no padding or explanation of known concepts, matching anchor 4. Not 5: several guardrails are repeated across steps 2, 4, and the Guardrails section, and some sentences (e.g., the store-selection paragraph) are convoluted and could be tightened.

Actionability

Fully executable, copy-paste-ready commands with exact syntax (openspec status --change "<name>" --json, openspec instructions "<artifact-id>" --change "<name>" --json, openspec list --json), concrete JSON fields to read (root, existingOutputPaths, lastModified), and specific path-creation checks. This is an instruction-only skill and its guidance is concretely actionable, so absence of code is not penalized.

Workflow Clarity

Six clearly sequenced steps with explicit validation checkpoints (project-root check before any write, re-refreshing status/instructions immediately before creating a glob file, confirm-before-write on every edit) and feedback loops for error recovery (stop on skipped artifacts, missing dependencies, or failed checks). Matches the anchor-5 pattern of validate-then-proceed with retry/stop guidance.

Progressive Disclosure

Single-file skill with no bundle files; content is appropriately placed for a CLI-driving workflow and organized under clear bolded sections (Store selection, Project check, Input, Steps, Output, Guardrails) with a one-line overview. Anchor 4 rather than 5: at ~100 lines, the interleaved edge-case handling (store selection, root-null disambiguation, the 5-item glob procedure) makes the main happy path harder to scan, a minor organization gap.

Specificity

Names the domain and several concrete actions ("revising its existing planning artifacts", "fold new decisions into it", "reconcile its artifacts after an edit", "Never edits code") with an explicit CLI-command redirect. Not 5 because the listed actions are near-synonymous variations on one capability rather than a comprehensive list of distinct operations; well above 3 since more than 1-2 concrete actions plus disambiguation are given.

Completeness

Explicitly answers both: what ("Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another") and when ("Use when the user wants to revise a change's plan... Also use when the user says 'openspec update change' or 'opsx update'") with concrete trigger phrases. This matches the anchor-5 example pattern exactly; a 'Use when...' clause is present, so no cap applies.

Trigger Term Quality

Good natural-term coverage: "revise a change's plan", "fold new decisions into it", "reconcile its artifacts", plus the literal phrases users would type ("openspec update change", "opsx update"). Not 5 because a few natural variants (e.g., "update the spec", "edit the design") are not covered.

Distinctiveness Conflict Risk

Clear niche (revising existing change artifacts, distinct from creating/applying/archiving changes) with distinct triggers, and it preempts its closest conflict explicitly: "If the user means the openspec update CLI command, which refreshes generated files, run that command instead." Third-person voice throughout, so no voice penalty.