Skip to content

Commit 917f271

Browse files
localdenlocalden
committed
Prompt updates
1 parent 00fe1bb commit 917f271

3 files changed

Lines changed: 113 additions & 28 deletions

File tree

‎templates/commands/checklist.md‎

Lines changed: 37 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -73,6 +73,12 @@ You **MUST** consider the user input before proceeding (if not empty).
7373
- Group items by category/section if applicable
7474
- Include brief explanations or links where helpful
7575
- 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
7682

7783
6. **Checklist structure**:
7884
```markdown
@@ -105,28 +111,34 @@ To avoid clutter, use descriptive types and clean up obsolete checklists when do
105111

106112
## Example Checklist Types
107113

108-
**Code Review:** `review.md`
109-
- Code quality checks
110-
- Documentation requirements
111-
- Test coverage verification
112-
- Security considerations
113-
114-
**Pre-Deployment:** `deploy.md`
115-
- Build verification
116-
- Test execution
117-
- Configuration validation
118-
- Rollback plan
119-
120-
**Accessibility:** `ux.md` or `a11y.md`
121-
- WCAG compliance
122-
- Keyboard navigation
123-
- Screen reader compatibility
124-
- Color contrast
125-
126-
**Security:** `security.md`
127-
- Input validation
128-
- Authentication/authorization
129-
- Data encryption
130-
- Dependency vulnerabilities
131-
132-
Generate checklist items that are specific, actionable, and relevant to the feature context.
114+
**Specification Review:** `spec-review.md`
115+
- Requirement completeness and clarity
116+
- User scenarios and edge cases coverage
117+
- Acceptance criteria definition
118+
- Domain-specific considerations
119+
120+
**Requirements Quality:** `requirements.md`
121+
- Testable and measurable outcomes
122+
- Stakeholder alignment verification
123+
- Assumptions and constraints documentation
124+
- Success metrics definition
125+
126+
**UX/Accessibility Scenarios:** `ux.md` or `a11y.md`
127+
- User journey completeness
128+
- Accessibility requirement coverage
129+
- Responsive design considerations
130+
- Internationalization needs
131+
132+
**Security Requirements:** `security.md`
133+
- Threat model coverage
134+
- Authentication/authorization requirements
135+
- Data protection requirements
136+
- Compliance and regulatory needs
137+
138+
**API/Integration Scenarios:** `api.md`
139+
- Contract completeness
140+
- Error handling scenarios
141+
- Backward compatibility considerations
142+
- Integration touchpoint coverage
143+
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.

‎templates/commands/plan.md‎

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,6 @@ You **MUST** consider the user input before proceeding (if not empty).
1919
## Outline
2020

2121
1. **Setup**: Run `{SCRIPT}` from repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH.
22-
- Before proceeding: Check FEATURE_SPEC has `## Clarifications` section. If missing or ambiguous, instruct user to run `/clarify` first.
2322

2423
2. **Load context**: Read FEATURE_SPEC and `.specify/memory/constitution.md`. Load IMPL_PLAN template (already copied).
2524

‎templates/commands/specify.md‎

Lines changed: 76 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -40,7 +40,81 @@ Given that feature description, do this:
4040
7. Return: SUCCESS (spec ready for planning)
4141

4242
4. Write the specification to SPEC_FILE using the template structure, replacing placeholders with concrete details derived from the feature description (arguments) while preserving section order and headings.
43-
5. Report completion with branch name, spec file path, and readiness for the next phase.
43+
44+
5. **Specification Quality Validation**: After writing the initial spec, validate it against quality criteria:
45+
46+
a. **Create Spec Quality Checklist**: Generate a checklist file at `FEATURE_DIR/checklists/spec.md` using the checklist template structure with these validation items:
47+
48+
```markdown
49+
# Specification Quality Checklist: [FEATURE NAME]
50+
51+
**Purpose**: Validate specification completeness and quality before proceeding to planning
52+
**Created**: [DATE]
53+
**Feature**: [Link to spec.md]
54+
55+
## Content Quality
56+
57+
- [ ] No implementation details (languages, frameworks, APIs)
58+
- [ ] Focused on user value and business needs
59+
- [ ] Written for non-technical stakeholders
60+
- [ ] All mandatory sections completed
61+
62+
## Requirement Completeness
63+
64+
- [ ] No [NEEDS CLARIFICATION] markers remain
65+
- [ ] Requirements are testable and unambiguous
66+
- [ ] Success criteria are measurable
67+
- [ ] Scope is clearly bounded
68+
- [ ] Dependencies and assumptions identified
69+
70+
## Notes
71+
72+
- Items marked incomplete require spec updates before `/clarify` or `/plan`
73+
```
74+
75+
b. **Run Validation Check**: Review the spec against each checklist item:
76+
- For each item, determine if it passes or fails
77+
- Document specific issues found (quote relevant spec sections)
78+
79+
c. **Handle Validation Results**:
80+
81+
- **If all items pass**: Mark checklist complete and proceed to step 6
82+
83+
- **If items fail (excluding [NEEDS CLARIFICATION])**:
84+
1. List the failing items and specific issues
85+
2. Update the spec to address each issue
86+
3. Re-run validation until all items pass (max 3 iterations)
87+
4. If still failing after 3 iterations, document remaining issues in checklist notes and warn user
88+
89+
- **If [NEEDS CLARIFICATION] markers remain**:
90+
1. Extract all [NEEDS CLARIFICATION: ...] markers from the spec
91+
2. For each clarification needed, present options to user in this format:
92+
93+
```markdown
94+
### Clarification Needed: [Topic]
95+
96+
**Context**: [Quote relevant spec section]
97+
98+
**Question**: [Specific question from NEEDS CLARIFICATION marker]
99+
100+
| Option | Description | Implications |
101+
|--------|-------------|--------------|
102+
| A | [First option] | [What this means for the feature] |
103+
| B | [Second option] | [What this means for the feature] |
104+
| C | [Third option] | [What this means for the feature] |
105+
| Custom | Provide your own specification | [Explain how to provide custom input] |
106+
107+
**Your choice**: _[Wait for user response]_
108+
```
109+
110+
3. Wait for user to respond with their choice (A, B, C, or custom input)
111+
4. Update the spec by replacing the [NEEDS CLARIFICATION] marker with the user's choice
112+
5. Repeat for all clarification markers
113+
6. Re-run validation after all clarifications are resolved
114+
115+
d. **Update Checklist**: After each validation iteration, update the checklist file with current pass/fail status
116+
117+
6. Report completion with branch name, spec file path, checklist results, and readiness for the next phase (`/clarify` or `/plan`).
44118

45119
**NOTE:** The script creates and checks out the new branch and initializes the spec file before writing.
46120

@@ -72,4 +146,4 @@ When creating this spec from a user prompt:
72146
- Performance targets and scale
73147
- Error handling behaviors
74148
- Integration requirements
75-
- Security/compliance needs
149+
- Security/compliance needs

0 commit comments

Comments
 (0)