Conciseness

The body is dense operational guidance — exact CLI invocations, JSON fields to read, and branching rules for store selection and root detection — with little explanation of concepts Claude already knows. The main trims available are the 8-row command reference table duplicated nearly verbatim in Phase 11 and the 'Quick Reference' exit section, and the ASCII-diagram placeholder block. Fits anchor 4 ('Efficient; minor instances of over-explanation that could be trimmed') better than 3, since the padding is localized duplication rather than a pattern of unnecessary explanation.

Actionability

Commands are copy-paste ready with correct JSON-reading instructions ('openspec instructions proposal --change "<name>" --json' then write to 'resolvedOutputPath', 'openspec archive "<name>" --yes' with the reason for --yes given), and each phase has verbatim display templates. Fully executable guidance covering the common cases — the anchor 5 example; it exceeds anchor 4 because even edge handling (root null, store errors, CLI missing) is concrete.

Workflow Clarity

Eleven clearly sequenced phases with explicit PAUSE checkpoints, a preflight CLI check, a project-setup validation step (read 'root' from 'openspec list --json', with the non-zero exit explained), and error-recovery branches for both root-null paths and mid-session exits. This matches anchor 5 ('Clear sequence with explicit validation steps; feedback loops for error recovery'), exceeding anchor 4's 'minor validation gaps' — validation is present at every risky transition.

Progressive Disclosure

The file is well-sectioned (Preflight, Phases 1-11, Graceful Exit, Guardrails) and self-contained with no bundle files, so there are no buried or nested references. However, at ~560 lines, material that could live in separate reference files — the artifact format templates and the command reference tables — is inlined. Fits anchor 4 ('Good structure; most content is appropriately placed... minor organization gaps') rather than 5, which expects content appropriately split across files, and clearly above 3, where structure is weak or references unclear.

Specificity

The description names the domain (OpenSpec onboarding) and one concrete action ('walk through a complete workflow cycle with narration and real codebase work'), but does not enumerate the specific actions performed (proposal, specs, design, tasks, archive). It fits the anchor 'Names domain and 1-2 concrete actions, but not comprehensive' — below level 4, which requires several listed specific actions, and above level 2, since more than the bare domain is stated.

Completeness

Both parts are present: 'what' ('Guided onboarding... walk through a complete workflow cycle with narration and real codebase work') and an explicit 'when' ('Also use when the user says "openspec onboard" or "opsx onboard"'). The 'when' clause is explicit but narrow — only exact command phrasings — so it matches anchor 4 ('when' could be more explicit or specific) rather than 5, and clearly above 3, where 'when' is missing or only implied.

Trigger Term Quality

Explicit trigger phrases '"openspec onboard"' and '"opsx onboard"' are natural things a user would say, giving good keyword coverage, but common variations like 'get started with OpenSpec', 'OpenSpec tutorial', or 'first change' are missing. Fits anchor 4 ('Good keyword coverage; a few natural terms missing') rather than 5, which demands synonym and variation coverage.

Distinctiveness Conflict Risk

The 'OpenSpec' niche and 'onboard' trigger phrases are distinct from other skills and from OpenSpec's other subcommands (propose, explore, archive). Clear niche with distinct triggers and minimal conflict risk — the anchor 5 example; it is not merely 'mostly distinct' (anchor 4), since the onboarding purpose and its triggers are unambiguous.