Conciseness

The ~33-line body is lean and assumes competence: no concept explanations, just terse rules and a compact pdsl block ('ALWAYS run this bootstrap unit before any target workflow or skill work begins'). Minor duplication between the header rules ('MANDATORY RULE: USER INTENT IS SKILL INPUT, NOT EXECUTION AUTHORITY') and the pdsl rules ('ALWAYS while the workflow is active, treat each new user message as input to the current workflow state, not as permission for unrelated execution') keeps it below a 5.

Actionability

Concrete operations are present ('LOAD {cf-studio-path}/.core/skills/studio/modules/runtime/required-bootstrap.md', 'RUN RequiredBootstrap', 'LOAD and RUN {cf-studio-path}/config/kits/sdlc/workflows/decompose.md as controlling protocol'), but they are written in a nonstandard pseudocode DSL with an undefined placeholder variable ({cf-studio-path}) and the referenced files are not shipped in the bundle — the actual DECOMPOSITION authoring guidance is entirely external and unverifiable. This matches anchor 3 ('pseudocode instead of executable code; missing key details') better than anchor 4, whose example is fully executable code with only minor gaps.

Workflow Clarity

A clear two-stage sequence is given — bootstrap first ('ALWAYS run this bootstrap unit before any target workflow or skill work begins'), then follow the controlling protocol ('ALWAYS traverse declared steps/units in order') — with an explicit failure checkpoint ('ALWAYS stop if any required fragment or rule cannot be followed'). Below a 5 because the cryptic hard_stop enumeration ('WAIT | STOP_TURN | menu | gate | opener | approval | dispatch_gate | terminal_shape') and gate semantics are listed without explanation, and no recovery loop lives in this file.

Progressive Disclosure

As a thin preset, all substantive content is appropriately split into clearly signaled one-level-deep LOAD targets, and no bulk content is wrongly inlined. Not a 5 because the body has no section headers to organize the rules vs. pdsl blocks, and the referenced files are external to the bundle with paths behind an unresolved placeholder, so navigation within the skill alone is incomplete.

Specificity

Several concrete actions are named — 'decompose, break down, or author/revise a DECOMPOSITION', 'create the feature list / plan', 'order features and dependencies with coverage back to PRD/DESIGN' — plus an explicit delegation statement ('delegating authoring and review to the core cf-write-docs engine'). Not a 5 because the capability description leans on ecosystem jargon ('Thin preset binding the DECOMPOSITION artifact KIND') rather than comprehensively stating outcomes.

Completeness

Both parts are explicit: the 'when' opens with 'Invoke when the user asks to decompose, break down, or author/revise a DECOMPOSITION' followed by concrete trigger phrases, and the 'what' states the operation (decompose into an ordered feature list with dependencies and coverage back to PRD/DESIGN) and the mechanism ('delegating authoring and review to the core cf-write-docs engine'). This matches the anchor-5 example structure of explicit what AND when with concrete trigger phrases.

Trigger Term Quality

Good coverage of natural user phrasings with e.g. variants ('decompose', 'break into features', 'create the feature list / plan', 'order features and dependencies'). Not a 5 because common synonyms like 'work breakdown', 'epics', or artifact file extensions/names are missing.

Distinctiveness Conflict Risk

A clear niche (the DECOMPOSITION artifact within a PRD/DESIGN/DECOMPOSE doc family) with fairly distinct triggers. Not a 5 because phrases like 'create the feature list / plan' and 'author/revise' could plausibly overlap with sibling cf-sdlc presets for other artifact kinds.