feat(design): strengthen DOCS story criteria

design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: design
-version: 0.14.0
+version: 0.15.0
 description: >-
   Design-and-decompose workflow that takes a PRD, researches the problem space,
   drafts a technical design document with a requirement-anchored testplan,

design/decomposition-review.md

@@ -144,15 +144,34 @@ impact:
    as gaps. Do not reject a legitimate prerequisite for adding no new
    feature behavior — that is its nature.
 
-8. **Documentation** — Do `[DOCS]` stories use the `[DOCS]` template
-   (Documentation Scope and Documentation Inputs instead of
-   Implementation Guidance and Testing Approach)? Does the Documentation
-   Scope describe what the reader needs to understand without prescribing
-   how to write or organize the documentation? Does the Documentation
-   Inputs section inventory all user-facing artifacts from the
-   implementation stories it references? Is the inventory detailed enough
-   for a documentation author to know what to look for in the
-   implementation?
+8. **Documentation** — Do `[DOCS]` stories satisfy the `[DOCS]` story
+   quality criteria from the decompose skill that the reviewer can
+   evaluate from its available inputs (PRD and decomposition artifacts)?
+   Specifically: does the title include searchable product/feature/
+   command terms (not just `[DOCS] Feature documentation`)? Does the
+   persona/goal/benefit name the actual reader and a concrete task? Are
+   acceptance criteria reader-verifiable documentation outcomes (not
+   implementation artifacts)? Does the Documentation Scope describe what
+   the reader needs to understand without prescribing how to write or
+   organize the documentation? Does the Documentation Inputs section
+   inventory user-facing artifacts from the contributing `[DEV]`/`[UI]`
+   stories? Are `[Assumption]` and `[Open: §9.N]` markers present on
+   items that appear speculative or unresolved? Does the Design
+   Reference include a `Contributing stories` line consistent with the
+   Documentation Inputs headers? Are the contributing story references
+   complete? Per criterion 7 placement: is each per-epic `[DOCS]`
+   story the last story in its epic (after all other stories,
+   including non-contributing `[QE]`/`[CI]` stories)? Is each
+   cross-cutting `[DOCS]` story the last story in the last epic? If
+   a `[DOCS]` story appears to violate either rule, flag it as a
+   conditional LOW finding — the decomposer will verify whether it
+   is a manifest-tracked post-sync story with an immutable filename
+   before acting. Note: the
+   reviewer cannot verify whether unmarked Documentation Inputs items
+   are truly derived from the design document or PRD — that provenance
+   check belongs to the decomposer (see the provenance verification
+   in `/decompose`). Flag items that appear speculative or unresolved
+   from the PRD and artifact context alone.
 
 ## Finding Format
 
@@ -179,10 +198,10 @@ Reference section.
 
 | Severity | Meaning | Action |
 |----------|---------|--------|
-| CRITICAL | Would cause incorrect implementation — missing requirements, contradictory acceptance criteria, broken dependency chain, scope reduction, stories referencing non-existent ICs or TCs, ICs with no implementing story, prerequisite story without justification or dependency declaration | Must fix before presenting |
-| HIGH | Would cause rework — story too large to review in a single PR, missing testing commitment, integration gap between stories, `[QE]` story duplicating `[DEV]` test scope, stories missing Interface Changes or Validated by references, prerequisite story missing preserved-behavior tests | Should fix before presenting |
-| MEDIUM | Would reduce clarity — vague acceptance criteria, imprecise implementation guidance or documentation scope, sizing concerns, minor coverage matrix inconsistencies, minor IC or TC reference inconsistencies | Fix if it adds value |
-| LOW | Structural improvements — naming consistency, ordering suggestions, documentation clarity | Fix only if clearly valuable |
+| CRITICAL | Would cause incorrect implementation — missing requirements, contradictory acceptance criteria, broken dependency chain, scope reduction, stories referencing non-existent ICs or TCs, ICs with no implementing story, prerequisite story without justification or dependency declaration, `[DOCS]` story missing contributing stories or with Documentation Inputs that omit user-facing artifacts from referenced implementation stories | Must fix before presenting |
+| HIGH | Would cause rework — story too large to review in a single PR, missing testing commitment, integration gap between stories, `[QE]` story duplicating `[DEV]` test scope, stories missing Interface Changes or Validated by references, prerequisite story missing preserved-behavior tests, `[DOCS]` story with generic title or unidentified reader/task | Should fix before presenting |
+| MEDIUM | Would reduce clarity — vague acceptance criteria, imprecise implementation guidance or documentation scope, sizing concerns, minor coverage matrix inconsistencies, minor IC or TC reference inconsistencies, `[DOCS]` story with Documentation Inputs items that appear speculative or unresolved from PRD and artifact context but lack `[Assumption]` or `[Open: §9.N]` markers (items verifiable against the PRD need no marker; the decomposer verifies design-derived provenance separately in the provenance sub-step of Step 8) | Fix if it adds value |
+| LOW | Structural improvements — naming consistency, ordering suggestions, documentation clarity, `[DOCS]` story placement that appears to precede a contributor (conditional — decomposer verifies sync identity before acting) | Fix only if clearly valuable |
 
 ## Validation Rules