Conciseness

The body assumes Claude's competence throughout — it never explains what a spec or a delta is conceptually — and every section carries operational weight (paths, rules, output template). It is not a 5 because the opening line 'Sync delta specs from a change to main specs' duplicates the frontmatter description, and a few guardrail bullets could be tightened; it is well above anchor 3's 'some unnecessary explanation.'

Actionability

Guidance is fully executable for an instruction-only skill: exact glob paths ('openspec/changes/<name>/specs/*/spec.md'), a runnable command ('openspec list --json'), a named tool (AskUserQuestion), deterministic per-section handling rules for ADDED/MODIFIED/REMOVED/RENAMED, a concrete format reference, and a copy-paste-ready output template. Specific examples cover the common cases, matching the top anchor.

Workflow Clarity

Steps 1-4 are clearly sequenced and include a stop checkpoint ('If no delta specs found, inform user and stop') plus read-before-edit guardrails. However, applying deltas is a batch operation across multiple spec files, and there is no post-apply verification step (no re-read of the merged spec, no 'openspec validate', no confirmation that preserved scenarios survived). Per the rubric, a batch operation without validation is capped at 3.

Progressive Disclosure

There are no bundle files, and the single-file body is well organized with clearly headed, well-ordered sections; the inline 'Delta Spec Format Reference' is genuinely needed on every run. It does not reach 5 because the file runs ~125 lines — over the under-50-line threshold that earns a 5 for a self-contained skill — and the format reference and output template are candidates for a separate reference file.

Specificity

The description names its domain and one concrete action — 'Sync delta specs from a change to main specs' — but stops there, offering no coverage of the underlying operations (adding, modifying, removing, renaming requirements). It matches the anchor for naming a domain with 1-2 concrete actions without being comprehensive; it falls short of anchor 4, which expects several specific listed actions.

Completeness

Both parts are explicit: the 'what' is 'Sync delta specs from a change to main specs' and the 'when' is 'Use when the user wants to update main specs with changes from a delta spec, without archiving the change.' It is not a 5 because the when-clause largely restates the what instead of adding distinct concrete trigger phrases; it is above a 3 because the 'Use when' guidance is explicitly stated, not merely implied.

Trigger Term Quality

Relevant terms are present ('sync', 'delta spec', 'main specs', 'update main specs'), but common variations a user might naturally say — 'apply changes', 'apply the delta', 'merge specs into main' — are absent. This sits at 'some relevant keywords but missing common variations or synonyms' rather than the good coverage of anchor 4.

Distinctiveness Conflict Risk

The openspec-specific vocabulary ('delta specs', 'main specs', 'change') carves out a clear niche, and 'without archiving the change' explicitly separates it from the sibling archive workflow. Minor overlap risk remains with other openspec skills that also touch specs, so it is mostly distinct rather than the minimal-conflict profile of anchor 5.