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
5. Formulate up to three questions chosen from these archetypes:
32
+
5. Formulate questions chosen from these archetypes:
33
33
- Scope refinement (e.g., "Should this include integration touchpoints with X and Y or stay limited to local module correctness?")
34
34
- Risk prioritization (e.g., "Which of these potential risk areas should receive mandatory gating checks?")
35
35
- Depth calibration (e.g., "Is this a lightweight pre-commit sanity list or a formal release gate?")
36
36
- Audience framing (e.g., "Will this be used by the author only or peers during PR review?")
37
37
- Boundary exclusion (e.g., "Should we explicitly exclude performance tuning items this round?")
38
+
- Scenario class gap (e.g., "No recovery flows detected—are rollback / partial failure paths in scope?")
38
39
39
40
Question formatting rules:
40
41
- If presenting options, generate a compact table with columns: Option | Candidate | Why It Matters
41
42
- Limit to A–E options maximum; omit table if a free-form answer is clearer
42
43
- Never ask the user to restate what they already said
43
-
- Avoid speculative categories (no hallucination). If uncertain, ask explicitly: "Confirm whether X belongs in scope."
44
+
- Avoid speculative categories (no hallucination). If uncertain, ask explicitly: "Confirm whether X belongs in scope."
44
45
45
46
Defaults when interaction impossible:
46
47
- Depth: Standard
47
48
- Audience: Reviewer (PR) if code-related; Author otherwise
48
49
- Focus: Top 2 relevance clusters
49
50
50
-
Output the three questions (or fewer if not needed) and wait for answers before continuing. Clearly label each as Q1/Q2/Q3.
51
+
Output the questions (label Q1/Q2/Q3). After answers: if ≥2 scenario classes (Alternate / Exception / Recovery / Non-Functional domain) remain unclear, you MAY ask up to TWO more targeted follow‑ups (Q4/Q5) with a one-line justification each (e.g., "Unresolved recovery path risk"). Do not exceed five total questions. Skip escalation if user explicitly declines more.
51
52
52
53
3.**Understand user request**: Combine `$ARGUMENTS` + clarifying answers:
* If file exists, append to existing file (e.g., use the same UX checklist)
72
71
- Number items sequentially starting from CHK001
73
-
- Group items by category/section if applicable
74
-
- Include brief explanations or links where helpful
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.
75
84
- Each `/checklist` run creates a NEW file (never overwrites existing checklists)
76
-
-**CRITICAL**: Focus checklist items on **specification and requirements quality** for the domain:
77
-
* Validate scenario coverage and edge cases
78
-
* Ensure requirements are clear, testable, and measurable
79
-
* Check for completeness of acceptance criteria
80
-
* Verify domain-specific considerations are addressed
81
-
* DO NOT include implementation details like unit tests, code quality, or deployment steps
82
-
83
-
6.**Checklist structure**:
84
-
```markdown
85
-
# [Checklist Type] Checklist: [Feature Name]
86
-
87
-
**Purpose**: [Brief description of what this checklist covers]
- 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).
- 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.
97
121
98
122
7.**Report**: Output full path to created checklist, item count, and remind user that each run creates a new file. Summarize:
99
123
- Focus areas selected
100
124
- Depth level
101
125
- Actor/timing
102
126
- Any explicit user-specified must-have items incorporated
103
127
104
-
**Important**: Each `/checklist` command invocation creates a NEW checklist file using short, descriptive names. This allows:
128
+
**Important**: Each `/checklist` command invocation creates a checklist file using short, descriptive names unless file already exists. This allows:
129
+
105
130
- Multiple checklists of different types (e.g., `ux.md`, `test.md`, `security.md`)
106
131
- Simple, memorable filenames that indicate checklist purpose
107
-
- Counter-based uniqueness for duplicate types (e.g., `review-2.md`)
108
-
- Easy identification and navigation in the checklists/ folder
132
+
- Easy identification and navigation in the `checklists/` folder
109
133
110
134
To avoid clutter, use descriptive types and clean up obsolete checklists when done.
111
135
112
136
## Example Checklist Types
113
137
114
138
**Specification Review:**`spec-review.md`
139
+
115
140
- Requirement completeness and clarity
116
141
- User scenarios and edge cases coverage
117
142
- Acceptance criteria definition
118
143
- Domain-specific considerations
119
144
120
145
**Requirements Quality:**`requirements.md`
146
+
121
147
- Testable and measurable outcomes
122
148
- Stakeholder alignment verification
123
149
- Assumptions and constraints documentation
124
150
- Success metrics definition
125
151
126
152
**UX/Accessibility Scenarios:**`ux.md` or `a11y.md`
153
+
127
154
- User journey completeness
128
155
- Accessibility requirement coverage
129
156
- Responsive design considerations
130
157
- Internationalization needs
131
158
132
159
**Security Requirements:**`security.md`
160
+
133
161
- Threat model coverage
134
162
- Authentication/authorization requirements
135
163
- Data protection requirements
136
164
- Compliance and regulatory needs
137
165
138
166
**API/Integration Scenarios:**`api.md`
167
+
139
168
- Contract completeness
140
169
- Error handling scenarios
141
170
- Backward compatibility considerations
142
171
- Integration touchpoint coverage
143
172
144
-
Generate checklist items that validate the **quality and completeness of specifications and requirements** for the domain, focusing on scenarios, edge cases, and requirement clarity rather than implementation details.
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