Prompt updates

templates/commands/checklist.md

@@ -73,6 +73,12 @@ You **MUST** consider the user input before proceeding (if not empty).
    - Group items by category/section if applicable
    - Include brief explanations or links where helpful
    - Each `/checklist` run creates a NEW file (never overwrites existing checklists)
+   - **CRITICAL**: Focus checklist items on **specification and requirements quality** for the domain:
+     * Validate scenario coverage and edge cases
+     * Ensure requirements are clear, testable, and measurable
+     * Check for completeness of acceptance criteria
+     * Verify domain-specific considerations are addressed
+     * DO NOT include implementation details like unit tests, code quality, or deployment steps
 
 6. **Checklist structure**:
    ```markdown
@@ -105,28 +111,34 @@ To avoid clutter, use descriptive types and clean up obsolete checklists when do
 
 ## Example Checklist Types
 
-**Code Review:** `review.md`
-- Code quality checks
-- Documentation requirements
-- Test coverage verification
-- Security considerations
+**Specification Review:** `spec-review.md`
+- Requirement completeness and clarity
+- User scenarios and edge cases coverage
+- Acceptance criteria definition
+- Domain-specific considerations
 
-**Pre-Deployment:** `deploy.md`
-- Build verification
-- Test execution
-- Configuration validation
-- Rollback plan
+**Requirements Quality:** `requirements.md`
+- Testable and measurable outcomes
+- Stakeholder alignment verification
+- Assumptions and constraints documentation
+- Success metrics definition
 
-**Accessibility:** `ux.md` or `a11y.md`
-- WCAG compliance
-- Keyboard navigation
-- Screen reader compatibility
-- Color contrast
+**UX/Accessibility Scenarios:** `ux.md` or `a11y.md`
+- User journey completeness
+- Accessibility requirement coverage
+- Responsive design considerations
+- Internationalization needs
 
-**Security:** `security.md`
-- Input validation
-- Authentication/authorization
-- Data encryption
-- Dependency vulnerabilities
+**Security Requirements:** `security.md`
+- Threat model coverage
+- Authentication/authorization requirements
+- Data protection requirements
+- Compliance and regulatory needs
 
-Generate checklist items that are specific, actionable, and relevant to the feature context.
+**API/Integration Scenarios:** `api.md`
+- Contract completeness
+- Error handling scenarios
+- Backward compatibility considerations
+- Integration touchpoint coverage
+
+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

@@ -19,7 +19,6 @@ You **MUST** consider the user input before proceeding (if not empty).
 ## Outline
 
 1. **Setup**: Run `{SCRIPT}` from repo root and parse JSON for FEATURE_SPEC, IMPL_PLAN, SPECS_DIR, BRANCH.
-   - Before proceeding: Check FEATURE_SPEC has `## Clarifications` section. If missing or ambiguous, instruct user to run `/clarify` first.
 
 2. **Load context**: Read FEATURE_SPEC and `.specify/memory/constitution.md`. Load IMPL_PLAN template (already copied).
 

templates/commands/specify.md

@@ -40,7 +40,81 @@ Given that feature description, do this:
     7. Return: SUCCESS (spec ready for planning)
 
 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.
-5. Report completion with branch name, spec file path, and readiness for the next phase.
+
+5. **Specification Quality Validation**: After writing the initial spec, validate it against quality criteria:
+
+   a. **Create Spec Quality Checklist**: Generate a checklist file at `FEATURE_DIR/checklists/spec.md` using the checklist template structure with these validation items:
+   
+      ```markdown
+      # Specification Quality Checklist: [FEATURE NAME]
+      
+      **Purpose**: Validate specification completeness and quality before proceeding to planning
+      **Created**: [DATE]
+      **Feature**: [Link to spec.md]
+      
+      ## Content Quality
+      
+      - [ ] No implementation details (languages, frameworks, APIs)
+      - [ ] Focused on user value and business needs
+      - [ ] Written for non-technical stakeholders
+      - [ ] All mandatory sections completed
+      
+      ## Requirement Completeness
+      
+      - [ ] No [NEEDS CLARIFICATION] markers remain
+      - [ ] Requirements are testable and unambiguous
+      - [ ] Success criteria are measurable
+      - [ ] Scope is clearly bounded
+      - [ ] Dependencies and assumptions identified
+      
+      ## Notes
+      
+      - Items marked incomplete require spec updates before `/clarify` or `/plan`
+      ```
+   
+   b. **Run Validation Check**: Review the spec against each checklist item:
+      - For each item, determine if it passes or fails
+      - Document specific issues found (quote relevant spec sections)
+   
+   c. **Handle Validation Results**:
+      
+      - **If all items pass**: Mark checklist complete and proceed to step 6
+      
+      - **If items fail (excluding [NEEDS CLARIFICATION])**:
+        1. List the failing items and specific issues
+        2. Update the spec to address each issue
+        3. Re-run validation until all items pass (max 3 iterations)
+        4. If still failing after 3 iterations, document remaining issues in checklist notes and warn user
+      
+      - **If [NEEDS CLARIFICATION] markers remain**:
+        1. Extract all [NEEDS CLARIFICATION: ...] markers from the spec
+        2. For each clarification needed, present options to user in this format:
+        
+           ```markdown
+           ### Clarification Needed: [Topic]
+           
+           **Context**: [Quote relevant spec section]
+           
+           **Question**: [Specific question from NEEDS CLARIFICATION marker]
+           
+           | Option | Description | Implications |
+           |--------|-------------|--------------|
+           | A | [First option] | [What this means for the feature] |
+           | B | [Second option] | [What this means for the feature] |
+           | C | [Third option] | [What this means for the feature] |
+           | Custom | Provide your own specification | [Explain how to provide custom input] |
+           
+           **Your choice**: _[Wait for user response]_
+           ```
+        
+        3. Wait for user to respond with their choice (A, B, C, or custom input)
+        4. Update the spec by replacing the [NEEDS CLARIFICATION] marker with the user's choice
+        5. Repeat for all clarification markers
+        6. Re-run validation after all clarifications are resolved
+   
+   d. **Update Checklist**: After each validation iteration, update the checklist file with current pass/fail status
+
+6. Report completion with branch name, spec file path, checklist results, and readiness for the next phase (`/clarify` or `/plan`).
 
 **NOTE:** The script creates and checks out the new branch and initializes the spec file before writing.
 
@@ -72,4 +146,4 @@ When creating this spec from a user prompt:
    - Performance targets and scale
    - Error handling behaviors
    - Integration requirements
-   - Security/compliance needs
+   - Security/compliance needs