From 917f271d747660eec140026dbb4407600a5a2a8c Mon Sep 17 00:00:00 2001 From: "den (work)" <53200638+localden@users.noreply.github.com> Date: Fri, 3 Oct 2025 22:25:18 -0700 Subject: [PATCH] Prompt updates --- templates/commands/checklist.md | 54 ++++++++++++++--------- templates/commands/plan.md | 1 - templates/commands/specify.md | 78 ++++++++++++++++++++++++++++++++- 3 files changed, 109 insertions(+), 24 deletions(-) diff --git a/templates/commands/checklist.md b/templates/commands/checklist.md index b21737c0..52b154b8 100644 --- a/templates/commands/checklist.md +++ b/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. diff --git a/templates/commands/plan.md b/templates/commands/plan.md index 7348ada4..7c378fd4 100644 --- a/templates/commands/plan.md +++ b/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). diff --git a/templates/commands/specify.md b/templates/commands/specify.md index 357c0083..771f1237 100644 --- a/templates/commands/specify.md +++ b/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 \ No newline at end of file + - Security/compliance needs