You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- If file exists, append to existing file (e.g., use the same UX checklist)
71
76
- Number items sequentially starting from CHK001
72
-
- Group items by category/section ONLY using this controlled set:
73
-
- Primary Flows
74
-
- Alternate Flows
75
-
- Exception / Error Flows
76
-
- Recovery & Resilience
77
-
- Non-Functional Domains (sub‑grouped or prefixed: Performance, Reliability, Security & Privacy, Accessibility, Observability, Scalability, Data Lifecycle)
78
-
- Traceability & Coverage
79
-
- Ambiguities & Conflicts
80
-
- Assumptions & Dependencies
81
-
- Do NOT invent ad-hoc categories; merge sparse categories (<2 items) into the closest higher-signal category.
82
-
- Add traceability refs when possible (order: spec section, acceptance criterion). If no ID system exists, create an item: `Establish requirement & acceptance criteria ID scheme before proceeding`.
83
-
- Optional brief rationale ONLY if it clarifies requirement intent or risk; never include implementation strategy, code pointers, or test plan details.
84
77
- Each `/checklist` run creates a NEW file (never overwrites existing checklists)
- Soft cap: If raw candidate items > 40, prioritize by risk/impact, consolidate minor edge cases, and add one consolidation item: `Consolidate remaining low-impact scenarios (see source docs) after priority review`.
87
-
- Minimum traceability coverage: ≥80% of items MUST include at least one traceability reference (spec section OR acceptance criterion). If impossible (missing structure), add corrective item: `Establish requirement & acceptance criteria ID scheme before proceeding` then proceed.
88
-
89
-
**Scenario Modeling & Traceability (MANDATORY)**:
90
-
- Classify scenarios into: Primary, Alternate, Exception/Error, Recovery/Resilience, Non-Functional (performance, reliability, security/privacy, accessibility, observability, scalability, data lifecycle) where applicable.
91
-
- At least one item per present scenario class; if a class is intentionally absent add: `Confirm intentional absence of <Scenario Class> scenarios`.
92
-
- Each item MUST include ≥1 of: scenario class tag, spec ref `[Spec §X.Y]`, acceptance criterion `[AC-##]`, or marker `(Assumption)/(Dependency)/(Ambiguity)/(Conflict)` (track coverage ratio for ≥80% traceability rule).
93
-
- Surface & cluster (
78
+
79
+
**Category Structure** - Group items ONLY using this controlled set:
80
+
- Primary Flows
81
+
- Alternate Flows
82
+
- Exception / Error Flows
83
+
- Recovery & Resilience
84
+
- Non-Functional Domains (sub‑grouped or prefixed: Performance, Reliability, Security & Privacy, Accessibility, Observability, Scalability, Data Lifecycle)
85
+
- Traceability & Coverage
86
+
- Ambiguities & Conflicts
87
+
- Assumptions & Dependencies
88
+
89
+
Do NOT invent ad-hoc categories; merge sparse categories (<2 items) into the closest higher-signal category.
- At least one item per present scenario class; if intentionally absent add: `Confirm intentional absence of <Scenario Class> scenarios`
94
+
- Include resilience/rollback coverage when state mutation or migrations occur (partial write, degraded mode, backward compatibility, rollback preconditions)
95
+
- If a major scenario lacks acceptance criteria, add an item to define measurable criteria
96
+
97
+
**Traceability Requirements**:
98
+
- MINIMUM: ≥80% of items MUST include at least one traceability reference
99
+
- Each item should include ≥1 of: scenario class tag, spec ref `[Spec §X.Y]`, acceptance criterion `[AC-##]`, or marker `(Assumption)/(Dependency)/(Ambiguity)/(Conflict)`
100
+
- If no ID system exists, create an item: `Establish requirement & acceptance criteria ID scheme before proceeding`
101
+
102
+
**Surface & Resolve Issues**:
103
+
- Cluster and create one resolution item per cluster for:
- Include resilience/rollback coverage when state mutation or migrations occur (partial write, degraded mode, backward compatibility, rollback preconditions).
100
-
- BANNED: references to specific tests ("unit test", "integration test"), code symbols, frameworks, algorithmic prescriptions, deployment steps. Rephrase any such user input into requirement clarity or coverage validation.
101
-
- If a major scenario lacks acceptance criteria, add an item to define measurable criteria.
102
-
103
-
**Context Curation (High-Signal Tokens Only)**:
104
-
- Load only necessary portions of `spec.md`, `plan.md`, `tasks.md` relevant to active focus areas (avoid full-file dumping where sections are irrelevant).
105
-
- Prefer summarizing long sections into concise scenario/requirement bullets before generating items (compaction principle).
106
-
- If source docs are large, generate interim summary items (e.g., `Confirm summary of §4 data retention rules is complete`) instead of embedding raw text.
107
-
- Use progressive disclosure: add follow-on retrieval only if a gap is detected (missing scenario class, unclear constraint).
108
-
- Treat context budget as finite: do not restate already-tagged requirements verbatim across multiple items.
109
-
- Merge near-duplicates when: same scenario class + same spec section + overlapping acceptance intent. Keep higher-risk phrasing; add note if consolidation occurred.
110
-
- Do not repeat identical spec or acceptance refs in >3 items unless covering distinct scenario classes.
111
-
- If >5 low-impact edge cases (minor parameter permutations), cluster into a single aggregated item.
112
-
- If user arguments are sparse, prioritize clarifying questions over speculative item generation.
113
-
114
-
6.**Structure Reference**: Generate the checklist exactly following the canonical template in `templates/checklist-template.md`. Treat that file as the single source of truth for:
115
-
- Title + meta section placement
116
-
- Category headings
117
-
- Checklist line formatting and ID sequencing
118
-
- Prohibited content (implementation details)
119
-
120
-
If (and only if) the canonical file is missing/unreadable, fall back to: H1 title, purpose/created meta lines, then one or more `##` category sections containing `- [ ] CHK### <imperative requirement-quality item>` lines with globally incrementing IDs starting at CHK001. No trailing explanatory footer.
108
+
109
+
**Content Consolidation**:
110
+
- Soft cap: If raw candidate items > 40, prioritize by risk/impact and add: `Consolidate remaining low-impact scenarios (see source docs) after priority review`
111
+
- Merge near-duplicates when: same scenario class + same spec section + overlapping acceptance intent
112
+
- If >5 low-impact edge cases, cluster into a single aggregated item
113
+
- Do not repeat identical spec or acceptance refs in >3 items unless covering distinct scenario classes
114
+
- Treat context budget as finite: do not restate already-tagged requirements verbatim across multiple items
- Focus on requirements & scenario coverage quality, NOT implementation
118
+
- NEVER include: specific tests ("unit test", "integration test"), code symbols, frameworks, algorithmic prescriptions, deployment steps, test plan details, implementation strategy
119
+
- Rephrase any such user input into requirement clarity or coverage validation
120
+
- Optional brief rationale ONLY if it clarifies requirement intent or risk
121
+
122
+
6.**Structure Reference**: Generate the checklist following the canonical template in `templates/checklist-template.md` for title, meta section, category headings, and ID formatting. If template is unavailable, use: H1 title, purpose/created meta lines, `##` category sections containing `- [ ] CHK### <requirement item>` lines with globally incrementing IDs starting at CHK001.
121
123
122
124
7.**Report**: Output full path to created checklist, item count, and remind user that each run creates a new file. Summarize:
123
125
- Focus areas selected
@@ -169,5 +171,3 @@ To avoid clutter, use descriptive types and clean up obsolete checklists when do
169
171
- Error handling scenarios
170
172
- Backward compatibility considerations
171
173
- Integration touchpoint coverage
172
-
173
-
Principle reminder: Checklist items validate requirements/scenario coverage quality—not implementation. If in doubt, transform any implementation phrasing into a requirement clarity or coverage validation item.
0 commit comments