|
| 1 | +--- |
| 2 | +description: Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec. |
| 3 | +--- |
| 4 | + |
| 5 | +The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty). |
| 6 | + |
| 7 | +User input: |
| 8 | + |
| 9 | +$ARGUMENTS |
| 10 | + |
| 11 | +Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file. |
| 12 | + |
| 13 | +Note: This clarification workflow is expected to run (and be completed) BEFORE invoking `/plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases. |
| 14 | + |
| 15 | +Execution steps: |
| 16 | + |
| 17 | +1. Run `.specify/scripts/bash/check-prerequisites.sh --json --paths-only` from repo root **once** (combined `--json --paths-only` mode / `-Json -PathsOnly`). Parse minimal JSON payload fields: |
| 18 | + - `FEATURE_DIR` |
| 19 | + - `FEATURE_SPEC` |
| 20 | + - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.) |
| 21 | + - If JSON parsing fails, abort and instruct user to re-run `/specify` or verify feature branch environment. |
| 22 | + |
| 23 | +2. Load the current spec file. Perform a structured ambiguity & coverage scan using this taxonomy. For each category, mark status: Clear / Partial / Missing. Produce an internal coverage map used for prioritization (do not output raw map unless no questions will be asked). |
| 24 | + |
| 25 | + Functional Scope & Behavior: |
| 26 | + - Core user goals & success criteria |
| 27 | + - Explicit out-of-scope declarations |
| 28 | + - User roles / personas differentiation |
| 29 | + |
| 30 | + Domain & Data Model: |
| 31 | + - Entities, attributes, relationships |
| 32 | + - Identity & uniqueness rules |
| 33 | + - Lifecycle/state transitions |
| 34 | + - Data volume / scale assumptions |
| 35 | + |
| 36 | + Interaction & UX Flow: |
| 37 | + - Critical user journeys / sequences |
| 38 | + - Error/empty/loading states |
| 39 | + - Accessibility or localization notes |
| 40 | + |
| 41 | + Non-Functional Quality Attributes: |
| 42 | + - Performance (latency, throughput targets) |
| 43 | + - Scalability (horizontal/vertical, limits) |
| 44 | + - Reliability & availability (uptime, recovery expectations) |
| 45 | + - Observability (logging, metrics, tracing signals) |
| 46 | + - Security & privacy (authN/Z, data protection, threat assumptions) |
| 47 | + - Compliance / regulatory constraints (if any) |
| 48 | + |
| 49 | + Integration & External Dependencies: |
| 50 | + - External services/APIs and failure modes |
| 51 | + - Data import/export formats |
| 52 | + - Protocol/versioning assumptions |
| 53 | + |
| 54 | + Edge Cases & Failure Handling: |
| 55 | + - Negative scenarios |
| 56 | + - Rate limiting / throttling |
| 57 | + - Conflict resolution (e.g., concurrent edits) |
| 58 | + |
| 59 | + Constraints & Tradeoffs: |
| 60 | + - Technical constraints (language, storage, hosting) |
| 61 | + - Explicit tradeoffs or rejected alternatives |
| 62 | + |
| 63 | + Terminology & Consistency: |
| 64 | + - Canonical glossary terms |
| 65 | + - Avoided synonyms / deprecated terms |
| 66 | + |
| 67 | + Completion Signals: |
| 68 | + - Acceptance criteria testability |
| 69 | + - Measurable Definition of Done style indicators |
| 70 | + |
| 71 | + Misc / Placeholders: |
| 72 | + - TODO markers / unresolved decisions |
| 73 | + - Ambiguous adjectives ("robust", "intuitive") lacking quantification |
| 74 | + |
| 75 | + For each category with Partial or Missing status, add a candidate question opportunity unless: |
| 76 | + - Clarification would not materially change implementation or validation strategy |
| 77 | + - Information is better deferred to planning phase (note internally) |
| 78 | + |
| 79 | +3. Generate (internally) a prioritized queue of candidate clarification questions (maximum 5). Do NOT output them all at once. Apply these constraints: |
| 80 | + - Maximum of 5 total questions across the whole session. |
| 81 | + - Each question must be answerable with EITHER: |
| 82 | + * A short multiple‑choice selection (2–5 distinct, mutually exclusive options), OR |
| 83 | + * A one-word / short‑phrase answer (explicitly constrain: "Answer in <=5 words"). |
| 84 | + - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation. |
| 85 | + - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first; avoid asking two low-impact questions when a single high-impact area (e.g., security posture) is unresolved. |
| 86 | + - Exclude questions already answered, trivial stylistic preferences, or plan-level execution details (unless blocking correctness). |
| 87 | + - Favor clarifications that reduce downstream rework risk or prevent misaligned acceptance tests. |
| 88 | + - If more than 5 categories remain unresolved, select the top 5 by (Impact * Uncertainty) heuristic. |
| 89 | + |
| 90 | +4. Sequential questioning loop (interactive): |
| 91 | + - Present EXACTLY ONE question at a time. |
| 92 | + - For multiple‑choice questions render options as a Markdown table: |
| 93 | + |
| 94 | + | Option | Description | |
| 95 | + |--------|-------------| |
| 96 | + | A | <Option A description> | |
| 97 | + | B | <Option B description> | |
| 98 | + | C | <Option C description> | (add D/E as needed up to 5) |
| 99 | + | Short | Provide a different short answer (<=5 words) | (Include only if free-form alternative is appropriate) |
| 100 | + |
| 101 | + - For short‑answer style (no meaningful discrete options), output a single line after the question: `Format: Short answer (<=5 words)`. |
| 102 | + - After the user answers: |
| 103 | + * Validate the answer maps to one option or fits the <=5 word constraint. |
| 104 | + * If ambiguous, ask for a quick disambiguation (count still belongs to same question; do not advance). |
| 105 | + * Once satisfactory, record it in working memory (do not yet write to disk) and move to the next queued question. |
| 106 | + - Stop asking further questions when: |
| 107 | + * All critical ambiguities resolved early (remaining queued items become unnecessary), OR |
| 108 | + * User signals completion ("done", "good", "no more"), OR |
| 109 | + * You reach 5 asked questions. |
| 110 | + - Never reveal future queued questions in advance. |
| 111 | + - If no valid questions exist at start, immediately report no critical ambiguities. |
| 112 | + |
| 113 | +5. Integration after EACH accepted answer (incremental update approach): |
| 114 | + - Maintain in-memory representation of the spec (loaded once at start) plus the raw file contents. |
| 115 | + - For the first integrated answer in this session: |
| 116 | + * Ensure a `## Clarifications` section exists (create it just after the highest-level contextual/overview section per the spec template if missing). |
| 117 | + * Under it, create (if not present) a `### Session YYYY-MM-DD` subheading for today. |
| 118 | + - Append a bullet line immediately after acceptance: `- Q: <question> → A: <final answer>`. |
| 119 | + - Then immediately apply the clarification to the most appropriate section(s): |
| 120 | + * Functional ambiguity → Update or add a bullet in Functional Requirements. |
| 121 | + * User interaction / actor distinction → Update User Stories or Actors subsection (if present) with clarified role, constraint, or scenario. |
| 122 | + * Data shape / entities → Update Data Model (add fields, types, relationships) preserving ordering; note added constraints succinctly. |
| 123 | + * Non-functional constraint → Add/modify measurable criteria in Non-Functional / Quality Attributes section (convert vague adjective to metric or explicit target). |
| 124 | + * Edge case / negative flow → Add a new bullet under Edge Cases / Error Handling (or create such subsection if template provides placeholder for it). |
| 125 | + * Terminology conflict → Normalize term across spec; retain original only if necessary by adding `(formerly referred to as "X")` once. |
| 126 | + - If the clarification invalidates an earlier ambiguous statement, replace that statement instead of duplicating; leave no obsolete contradictory text. |
| 127 | + - Save the spec file AFTER each integration to minimize risk of context loss (atomic overwrite). |
| 128 | + - Preserve formatting: do not reorder unrelated sections; keep heading hierarchy intact. |
| 129 | + - Keep each inserted clarification minimal and testable (avoid narrative drift). |
| 130 | + |
| 131 | +6. Validation (performed after EACH write plus final pass): |
| 132 | + - Clarifications session contains exactly one bullet per accepted answer (no duplicates). |
| 133 | + - Total asked (accepted) questions ≤ 5. |
| 134 | + - Updated sections contain no lingering vague placeholders the new answer was meant to resolve. |
| 135 | + - No contradictory earlier statement remains (scan for now-invalid alternative choices removed). |
| 136 | + - Markdown structure valid; only allowed new headings: `## Clarifications`, `### Session YYYY-MM-DD`. |
| 137 | + - Terminology consistency: same canonical term used across all updated sections. |
| 138 | + |
| 139 | +7. Write the updated spec back to `FEATURE_SPEC`. |
| 140 | + |
| 141 | +8. Report completion (after questioning loop ends or early termination): |
| 142 | + - Number of questions asked & answered. |
| 143 | + - Path to updated spec. |
| 144 | + - Sections touched (list names). |
| 145 | + - Coverage summary table listing each taxonomy category with Status: Resolved (was Partial/Missing and addressed), Deferred (exceeds question quota or better suited for planning), Clear (already sufficient), Outstanding (still Partial/Missing but low impact). |
| 146 | + - If any Outstanding or Deferred remain, recommend whether to proceed to `/plan` or run `/clarify` again later post-plan. |
| 147 | + - Suggested next command. |
| 148 | + |
| 149 | +Behavior rules: |
| 150 | +- If no meaningful ambiguities found (or all potential questions would be low-impact), respond: "No critical ambiguities detected worth formal clarification." and suggest proceeding. |
| 151 | +- If spec file missing, instruct user to run `/specify` first (do not create a new spec here). |
| 152 | +- Never exceed 5 total asked questions (clarification retries for a single question do not count as new questions). |
| 153 | +- Avoid speculative tech stack questions unless the absence blocks functional clarity. |
| 154 | +- Respect user early termination signals ("stop", "done", "proceed"). |
| 155 | + - If no questions asked due to full coverage, output a compact coverage summary (all categories Clear) then suggest advancing. |
| 156 | + - If quota reached with unresolved high-impact categories remaining, explicitly flag them under Deferred with rationale. |
| 157 | + |
| 158 | +Context for prioritization: $ARGUMENTS |
0 commit comments