prizmkit 1.0.127 → 1.0.129

package/bundled/skills/bugfix-pipeline-launcher/SKILL.md

@@ -111,61 +111,100 @@ Detect user intent from their message, then follow the corresponding workflow:
      --action status 2>/dev/null
    ```
 
-4. **Ask execution mode**: Present the user with a choice before launching:
-   - **(1) Foreground in session (recommended)**: Pipeline runs in the current session via `run-bugfix.sh run`. Visible output and direct error feedback.
-   - **(2) Background daemon**: Pipeline runs fully detached via `launch-bugfix-daemon.sh`. Survives session closure. Use only when user explicitly requests background execution.
-   - **(3) Manual — show commands**: Display the exact commands the user can run themselves. No execution.
+4. **Present all runtime options**: Show the user a complete options summary before launching. Present each option with its default, so the user can confirm or override.
 
-   Default to option 1 if user says "just run it" or doesn't specify. Default to option 2 only if user explicitly says "background", "detached", or "run in background".
+   **Runtime Options:**
 
-   **If option 1 (foreground)**:
+   | Option | Default | Description |
+   |--------|---------|-------------|
+   | **Execution mode** | Foreground | (1) Foreground — visible output (2) Background daemon — survives session closure (3) Manual — show commands only |
+   | **Verbose logging** | On | Detailed AI session logs including tool calls and subagent activity |
+   | **Max retries** | 3 | Max retry attempts per failed bug |
+   | **Session timeout** | None | Per-bug timeout in seconds (e.g. `3600` = 1 hour) |
+   | **Bug filter** | All | Run specific bugs: `B-001:B-005` (range), `B-001,B-003` (list), or mixed `B-001,B-005:B-010` |
+
+   Default to Foreground + Verbose On if user doesn't specify.
+
+   **Environment variable mapping** (for natural language → env var translation):
+
+   | User says | Environment variable |
+   |-----------|---------------------|
+   | "timeout 2 hours" | `SESSION_TIMEOUT=7200` |
+   | "max 5 retries" | `MAX_RETRIES=5` |
+   | "no verbose" / "quiet" | `VERBOSE=0` |
+   | "heartbeat every 60s" | `HEARTBEAT_INTERVAL=60` |
+
+   Example presentation to user:
+   ```
+   Bugfix pipeline will process N bugs with these settings:
+   - Execution:   Foreground (recommended)
+   - Verbose:     On (subagent detection enabled)
+   - Max retries: 3
+   - Timeout:     none
+   - Bugs:        all (by severity order)
+
+   Want to change any options, or launch with these defaults?
+   ```
+
+   **Execution mode details:**
+
+   **Foreground (recommended)**: Pipeline runs in the current session via `run-bugfix.sh run`. Provides visible output and direct error feedback.
+   ```bash
+   VERBOSE=1 dev-pipeline/run-bugfix.sh run bug-fix-list.json
+   ```
+   With all options:
    ```bash
-   dev-pipeline/run-bugfix.sh run bug-fix-list.json
+   VERBOSE=1 MAX_RETRIES=5 SESSION_TIMEOUT=3600 \
+     dev-pipeline/run-bugfix.sh run bug-fix-list.json
    ```
 
-   **If option 2 (background)**:
+   **Background daemon**: Pipeline runs fully detached via `launch-bugfix-daemon.sh`. Survives session closure. Use only when user explicitly requests background execution.
    ```bash
-   dev-pipeline/launch-bugfix-daemon.sh start bug-fix-list.json
+   dev-pipeline/launch-bugfix-daemon.sh start bug-fix-list.json --env "VERBOSE=1"
    ```
-   After launch, **record the decision** for traceability:
+   With all options:
    ```bash
-   echo "[$(date -u +%Y-%m-%dT%H:%M:%S)] MODE=daemon PID=$(cat dev-pipeline/bugfix-state/daemon.pid 2>/dev/null) BUG_LIST=bug-fix-list.json BUGS=$(python3 -c "import json; print(len(json.load(open('bug-fix-list.json')).get('bugs',[])))")" >> .prizmkit/bugfix-pipeline-run.log
+   dev-pipeline/launch-bugfix-daemon.sh start bug-fix-list.json \
+     --env "VERBOSE=1 MAX_RETRIES=5"
    ```
-   Note: Pipeline runs fully detached. Survives session closure.
 
-   **If option 3 (manual)**: Print commands and stop. Do not execute anything.
+   **Manual — show commands**: Display the exact commands the user can run themselves. Print commands and stop. Do not execute anything.
    ```
    # To run in foreground (recommended):
-   dev-pipeline/run-bugfix.sh run bug-fix-list.json
+   VERBOSE=1 dev-pipeline/run-bugfix.sh run bug-fix-list.json
 
    # To run in background (detached):
-   dev-pipeline/launch-bugfix-daemon.sh start bug-fix-list.json
+   dev-pipeline/launch-bugfix-daemon.sh start bug-fix-list.json --env "VERBOSE=1"
 
    # To check status:
    dev-pipeline/run-bugfix.sh status bug-fix-list.json
    ```
 
-5. **Ask user to confirm**: "Ready to launch the bugfix pipeline? It will process N bugs (by severity order)."
+5. **Ask user to confirm**: "Ready to launch the bugfix pipeline with the above settings?"
 
-6. **Launch** (based on chosen mode — see step 4).
+6. **Launch** with the assembled command from step 4.
 
-7. **Verify launch**:
-   ```bash
-   dev-pipeline/launch-bugfix-daemon.sh status
-   ```
+7. **Post-launch** (depends on execution mode):
 
-8. **Start log monitoring** (daemon mode only) -- Use the Bash tool with `run_in_background: true`:
-   ```bash
-   tail -f dev-pipeline/bugfix-state/pipeline-daemon.log
-   ```
-   This runs in background so you can continue interacting with the user.
+   **If foreground**: Pipeline runs to completion in the terminal. After it finishes:
+   - Summarize results: total bugs, fixed, failed, skipped
+   - If all fixed: each bug session has already run `prizmkit-retrospective` (structural sync) internally. Ask user what's next.
+   - If some failed: show failed bug IDs and suggest `retry-bug.sh <B-XXX>` or `reset-bug.sh <B-XXX> --clean --run`
 
-9. **Report to user**:
-   - Execution mode chosen
-   - Pipeline PID (daemon mode) or session status (foreground)
-   - Log file location
-   - "You can ask me 'bugfix status' or 'show fix logs' at any time"
-   - (daemon mode only) "Closing this session will NOT stop the pipeline"
+   **If background daemon**:
+   1. Verify launch:
+      ```bash
+      dev-pipeline/launch-bugfix-daemon.sh status
+      ```
+   2. Start log monitoring — Use the Bash tool with `run_in_background: true`:
+      ```bash
+      tail -f dev-pipeline/bugfix-state/pipeline-daemon.log
+      ```
+   3. Report to user:
+      - Pipeline PID
+      - Log file location
+      - "You can ask me 'bugfix status' or 'show fix logs' at any time"
+      - "Closing this session will NOT stop the pipeline"
 
 ---
 
@@ -236,25 +275,7 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 ---
 
-#### Intent E: Custom Parameters
-
-When user specifies custom settings, map to environment variables:
-
-| User says | Environment variable |
-|-----------|---------------------|
-| "timeout 2 hours" | `SESSION_TIMEOUT=7200` |
-| "max 5 retries" | `MAX_RETRIES=5` |
-| "verbose mode" | `VERBOSE=1` |
-| "heartbeat every 60s" | `HEARTBEAT_INTERVAL=60` |
-
-Pass via `--env`:
-```bash
-dev-pipeline/launch-bugfix-daemon.sh start bug-fix-list.json --env "SESSION_TIMEOUT=7200 MAX_RETRIES=5 VERBOSE=1"
-```
-
----
-
-#### Intent F: Retry Single Bug
+#### Intent E: Retry Single Bug
 
 When user says "retry B-001":
 

package/bundled/skills/dev-pipeline-launcher/SKILL.md

@@ -57,10 +57,13 @@ Before any action, validate:
 2. **For start**: `feature-list.json` must exist in project root (or user-specified path)
 3. **Dependencies**: `jq`, `python3`, AI CLI (`cbc` or `claude`) must be in PATH
 4. **Python version**: Requires Python 3.8+ for dev-pipeline scripts
+5. **playwright-cli** (optional): If any feature has `browser_interaction` field, check `playwright-cli` is available
 
 Quick check:
 ```bash
 command -v jq && command -v python3 && (command -v cbc || command -v claude) && echo "All dependencies OK"
+# Optional: browser interaction support
+command -v playwright-cli && echo "playwright-cli OK" || echo "playwright-cli not found (browser verification will be skipped)"
 ```
 
 If `feature-list.json` is missing, inform user:
@@ -105,80 +108,107 @@ Detect user intent from their message, then follow the corresponding workflow:
      --action status 2>/dev/null
    ```
 
-4. **Ask execution mode**: Present the user with a choice before launching:
-   - **(1) Foreground in session (recommended)**: Pipeline runs in the current session via `run.sh run`. Visible output and direct error feedback.
-   - **(2) Background daemon**: Pipeline runs fully detached via `launch-daemon.sh`. Survives session closure. Use only when user explicitly requests background execution.
-   - **(3) Manual — show commands**: Display the exact commands the user can run themselves. No execution.
+4. **Present all runtime options**: Show the user a complete options summary before launching. Present each option with its default, so the user can confirm or override.
 
-   Default to option 1 if user says "just run it" or doesn't specify. Default to option 2 only if user explicitly says "background", "detached", or "run in background".
+   **Runtime Options:**
 
-   **If option 1 (foreground)**:
+   | Option | Default | Description |
+   |--------|---------|-------------|
+   | **Execution mode** | Foreground | (1) Foreground — visible output (2) Background daemon — survives session closure (3) Manual — show commands only |
+   | **Critic review** | Off | Adversarial review after planning & implementation. Increases time ~5-10 min/feature |
+   | **Verbose logging** | On | Detailed AI session logs including tool calls and subagent activity |
+   | **Max retries** | 3 | Max retry attempts per failed feature |
+   | **Session timeout** | None | Per-feature timeout in seconds (e.g. `3600` = 1 hour) |
+   | **Feature filter** | All | Run specific features: `F-001:F-005` (range), `F-001,F-003` (list), or mixed `F-001,F-005:F-010` |
+   | **Browser verify** | Auto | Run playwright-cli verification for features with `browser_interaction`. Auto = run if playwright-cli installed and features have the field |
+
+   Default to Foreground + Verbose On if user doesn't specify. Default Critic to Off unless features have `estimated_complexity: "high"` or above.
+
+   **Environment variable mapping** (for natural language → env var translation):
+
+   | User says | Environment variable |
+   |-----------|---------------------|
+   | "timeout 2 hours" | `SESSION_TIMEOUT=7200` |
+   | "max 5 retries" | `MAX_RETRIES=5` |
+   | "no verbose" / "quiet" | `VERBOSE=0` |
+   | "heartbeat every 60s" | `HEARTBEAT_INTERVAL=60` |
+   | "enable critic review" | `ENABLE_CRITIC=true` |
+   | "skip browser verify" | `BROWSER_VERIFY=false` |
+   | "enable browser verify" | `BROWSER_VERIFY=true` |
+
+   Example presentation to user:
+   ```
+   Pipeline will process N features with these settings:
+   - Execution:   Foreground (recommended)
+   - Critic:      Off
+   - Verbose:     On (subagent detection enabled)
+   - Max retries: 3
+   - Timeout:     none
+   - Features:    all
+
+   Want to change any options, or launch with these defaults?
+   ```
+
+   **Execution mode details:**
+
+   **Foreground (recommended)**: Pipeline runs in the current session via `run.sh run`. Provides visible output and direct error feedback.
    ```bash
-   dev-pipeline/run.sh run feature-list.json
+   VERBOSE=1 dev-pipeline/run.sh run feature-list.json
    ```
-   If user wants to run only specific features:
+   With all options:
    ```bash
-   dev-pipeline/run.sh run feature-list.json --features F-001:F-005
-   dev-pipeline/run.sh run feature-list.json --features F-001,F-003,F-007
+   VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5 SESSION_TIMEOUT=3600 \
+     dev-pipeline/run.sh run feature-list.json --features F-001:F-005
    ```
 
-   **If option 2 (background)**:
+   **Background daemon**: Pipeline runs fully detached via `launch-daemon.sh`. Survives session closure. Use only when user explicitly requests background execution.
    ```bash
-   dev-pipeline/launch-daemon.sh start feature-list.json
+   dev-pipeline/launch-daemon.sh start feature-list.json --env "VERBOSE=1"
    ```
-   With feature filter:
+   With all options:
    ```bash
-   dev-pipeline/launch-daemon.sh start feature-list.json --features F-001:F-005
+   dev-pipeline/launch-daemon.sh start feature-list.json --features F-001:F-005 \
+     --env "VERBOSE=1 ENABLE_CRITIC=true MAX_RETRIES=5"
    ```
-   Note: Pipeline runs fully detached. Survives session closure.
 
-   **If option 3 (manual)**: Print commands and stop. Do not execute anything.
+   **Manual — show commands**: Display the exact commands the user can run themselves. Print commands and stop. Do not execute anything.
    ```
    # To run in foreground (recommended):
-   dev-pipeline/run.sh run feature-list.json
+   VERBOSE=1 dev-pipeline/run.sh run feature-list.json
 
    # To run in background (detached):
-   dev-pipeline/launch-daemon.sh start feature-list.json
+   dev-pipeline/launch-daemon.sh start feature-list.json --env "VERBOSE=1"
 
    # To check status:
    dev-pipeline/run.sh status feature-list.json
    ```
 
-5. **Ask whether to enable Critic Agent** (adversarial review):
-   Present the choice:
-   - **(a) No — standard pipeline (default)**: No adversarial review. Faster execution, lower token cost.
-   - **(b) Yes — enable Critic review**: Adds adversarial challenge after planning and implementation. Challenges plan fitness and code integration quality. Increases pipeline time by ~5-10 minutes per feature.
-
-   Default to (a). Only suggest (b) if features have `estimated_complexity: "high"` or above.
-
-   If user chooses (b), prepend `ENABLE_CRITIC=true` to the launch command in step 6.
-
-6. **Ask user to confirm**: "Ready to launch the pipeline? It will process N features."
-
-7. **Launch** (based on chosen mode from step 4, with `ENABLE_CRITIC=true` env var if chosen in step 5):
-   - Foreground: `ENABLE_CRITIC=true dev-pipeline/run.sh run feature-list.json`
-   - Background: `dev-pipeline/launch-daemon.sh start feature-list.json --env "ENABLE_CRITIC=true"`
-   - If user specified environment overrides:
-     ```bash
-     dev-pipeline/launch-daemon.sh start feature-list.json --env "SESSION_TIMEOUT=7200 MAX_RETRIES=5"
-     ```
-
-8. **Verify launch**:
-   ```bash
-   dev-pipeline/launch-daemon.sh status
-   ```
-
-9. **Start log monitoring** -- Use the Bash tool with `run_in_background: true`:
-   ```bash
-   tail -f dev-pipeline/state/pipeline-daemon.log
-   ```
-   This runs in background so you can continue interacting with the user.
-
-10. **Report to user**:
-   - Pipeline PID
-   - Log file location
-   - "You can ask me 'pipeline status' or 'show logs' at any time"
-   - "Closing this session will NOT stop the pipeline"
+5. **Ask user to confirm**: "Ready to launch the pipeline with the above settings?"
+
+6. **Launch** with the assembled command from step 4.
+
+7. **Post-launch** (depends on execution mode):
+
+   **If foreground**: Pipeline runs to completion in the terminal. After it finishes:
+   - Summarize results: total features, succeeded, failed, skipped
+   - If all succeeded: each feature session has already run `prizmkit-retrospective` internally. Ask user what's next.
+   - If some failed: show failed feature IDs and suggest `retry-feature.sh <F-XXX>` or `reset-feature.sh <F-XXX> --clean --run`
+   - **Browser verification**: If any completed features have `browser_interaction` and `playwright-cli` is installed, offer to run browser verification (see §Post-Pipeline Browser Verification)
+
+   **If background daemon**:
+   1. Verify launch:
+      ```bash
+      dev-pipeline/launch-daemon.sh status
+      ```
+   2. Start log monitoring — Use the Bash tool with `run_in_background: true`:
+      ```bash
+      tail -f dev-pipeline/state/pipeline-daemon.log
+      ```
+   3. Report to user:
+      - Pipeline PID
+      - Log file location
+      - "You can ask me 'pipeline status' or 'show logs' at any time"
+      - "Closing this session will NOT stop the pipeline"
 
 ---
 
@@ -249,76 +279,87 @@ Detect user intent from their message, then follow the corresponding workflow:
 
 ---
 
-#### Intent E: Custom Parameters
-
-When user specifies custom settings, map to environment variables:
+#### Intent E: Retry Single Feature Node
 
-| User says | Environment variable |
-|-----------|---------------------|
-| "timeout 2 hours" | `SESSION_TIMEOUT=7200` |
-| "max 5 retries" | `MAX_RETRIES=5` |
-| "verbose mode" | `VERBOSE=1` |
-| "heartbeat every 60s" | `HEARTBEAT_INTERVAL=60` |
-| "enable critic review" | `ENABLE_CRITIC=true` env var (or `--critic` for single feature) |
+When user says "retry F-003":
 
-Pass via `--env`:
 ```bash
-dev-pipeline/launch-daemon.sh start feature-list.json --env "SESSION_TIMEOUT=7200 MAX_RETRIES=5 VERBOSE=1"
+dev-pipeline/retry-feature.sh F-003 feature-list.json
 ```
 
----
-
-#### Intent F: Run Subset of Features
-
-When user says "run only F-001 to F-005", "only build features 1 through 5":
+When user says "clean retry F-003" or "retry F-003 from scratch":
 
 ```bash
-dev-pipeline/run.sh run feature-list.json --features F-001:F-005
+dev-pipeline/reset-feature.sh F-003 --clean --run feature-list.json
 ```
 
-When user says "run F-001, F-003, and F-007", "only build these three features":
-
+Environment variables (optional):
 ```bash
-dev-pipeline/run.sh run feature-list.json --features F-001,F-003,F-007
+SESSION_TIMEOUT=3600 dev-pipeline/retry-feature.sh F-003 feature-list.json
 ```
 
-Mixed format (IDs + ranges):
+Notes:
+- `retry-feature.sh` runs exactly one feature session and exits.
+- `reset-feature.sh --clean --run` clears the feature state before retrying (fresh start).
+- Keep pipeline daemon mode for main run management (`launch-daemon.sh`).
 
-```bash
-dev-pipeline/run.sh run feature-list.json --features F-001,F-005:F-010
-```
+---
 
-Background daemon with feature filter:
+#### Post-Pipeline Browser Verification
 
-```bash
-dev-pipeline/launch-daemon.sh start feature-list.json --features F-001:F-005
-```
+After pipeline completion, if features have `browser_interaction` fields and `playwright-cli` is installed:
 
----
+1. **Check which features qualify**:
+   ```bash
+   python3 -c "
+   import json
+   with open('feature-list.json') as f:
+       data = json.load(f)
+   for feat in data.get('features', []):
+       bi = feat.get('browser_interaction')
+       if bi and feat.get('status') == 'completed':
+           print(f\"  {feat['id']}: {feat.get('title','')} → {bi['url']}\")
+   " 2>/dev/null
+   ```
 
-#### Intent G: Retry Single Feature Node
+2. **Ask user**: "N features have browser verification configured. Run playwright-cli verification now? (Y/n)"
 
-When user says "retry F-003":
+3. **If yes**, first learn the available commands:
+   ```bash
+   playwright-cli --help
+   ```
+   Then read `dev-pipeline/assets/playwright-cli-reference.md` for snapshot format and workflow patterns. For each qualifying feature:
+   ```bash
+   # Start dev server if setup_command is specified
+   # (run in background, wait for port to be ready)
 
-```bash
-dev-pipeline/retry-feature.sh F-003 feature-list.json
-```
+   # Open browser and navigate
+   playwright-cli open <url>
 
-When user says "clean retry F-003" or "retry F-003 from scratch":
+   # Take initial snapshot
+   playwright-cli snapshot
 
-```bash
-dev-pipeline/reset-feature.sh F-003 --clean --run feature-list.json
-```
+   # Execute verify_steps (if specified) — these are descriptive;
+   # map them to actual refs from the snapshot
+   # e.g., "click login button" → find button ref in snapshot → playwright-cli click <ref>
 
-Environment variables (optional):
-```bash
-SESSION_TIMEOUT=3600 dev-pipeline/retry-feature.sh F-003 feature-list.json
-```
+   # Take final screenshot
+   playwright-cli screenshot
 
-Notes:
-- `retry-feature.sh` runs exactly one feature session and exits.
-- `reset-feature.sh --clean --run` clears the feature state before retrying (fresh start).
-- Keep pipeline daemon mode for main run management (`launch-daemon.sh`).
+   # Close browser
+   playwright-cli close
+   ```
+
+4. **Report results**:
+   - For each feature: URL opened, steps executed, screenshot path
+   - If any step fails (element not found, page error): flag as verification failure
+   - Screenshots are saved to `.playwright-cli/` for user review
+
+5. **Cleanup**: Stop any dev servers started by `setup_command`
+
+**Important**: Browser verification is best-effort — failures here do NOT change the feature's pipeline status. They serve as visual confirmation aids for the user.
+
+---
 
 ### Error Handling
 
@@ -332,6 +373,7 @@ Notes:
 | Launch failed (process died immediately) | Show last 20 lines of log: `tail -20 dev-pipeline/state/pipeline-daemon.log` |
 | Feature stuck/blocked | Use `retry-feature.sh <F-XXX>` to retry; use `reset-feature.sh <F-XXX> --clean --run` for fresh start |
 | All features blocked/failed | Show status, suggest daemon-safe recovery: `dev-pipeline/reset-feature.sh <F-XXX> --clean --run feature-list.json` |
+| `playwright-cli` not installed | Browser verification skipped (non-blocking). Suggest: `npm install -g @playwright/cli@latest` |
 | Permission denied on script | Run `chmod +x dev-pipeline/launch-daemon.sh dev-pipeline/run.sh` |
 
 ### Integration Notes
@@ -341,4 +383,4 @@ Notes:
 - **Single instance**: Only one pipeline can run at a time. The PID file prevents duplicates.
 - **Pipeline coexistence**: Feature and bugfix pipelines use separate state directories (`state/` vs `bugfix-state/`), so they can run simultaneously without conflict.
 - **State preservation**: Stopping and restarting the pipeline resumes from where it left off -- completed features are not re-run.
-- **HANDOFF**: After pipeline completes all features, suggest running `prizmkit-retrospective` for `.prizm-docs/` architecture sync, or ask user what's next.
+- **HANDOFF**: After pipeline completes all features, each session has already run `prizmkit-retrospective` internally. Ask user what's next.

package/bundled/skills/prizmkit-clarify/SKILL.md

@@ -1,16 +1,17 @@
 ---
 name: "prizmkit-clarify"
-description: "Interactive requirement clarification. Resolves ambiguities in feature specs by asking sequential questions with recommended answers. Use when spec has unclear parts or you're unsure about requirements before planning. Use this skill whenever a spec has [NEEDS CLARIFICATION] markers, vague requirements, or the user wants to refine their feature definition before planning. Trigger on: 'clarify', 'refine spec', 'resolve ambiguities', 'spec has questions', 'unsure about requirements', 'spec is unclear'. (project)"
+description: "Interactive requirement clarification. Resolves ALL ambiguities in feature specs through unlimited rounds of questions until full understanding is reached. Use when spec has unclear parts, you're unsure about requirements, or before planning to ensure nothing is ambiguous. Trigger on: 'clarify', 'refine spec', 'resolve ambiguities', 'spec has questions', 'unsure about requirements', 'spec is unclear'. (project)"
 ---
 
 # PrizmKit Clarify
 
-Interactive requirement clarification that resolves ambiguities in feature specifications. Asks focused questions one at a time, updating the spec atomically after each answer.
+Exhaustive interactive requirement clarification. Resolves **every** ambiguity in a feature specification by asking questions one at a time — no limit on rounds or number of questions. The goal is **complete understanding**: do not stop until every unclear aspect is resolved and you are fully confident about the requirements.
 
 ### When to Use
 - After `/prizmkit-specify` when spec has `[NEEDS CLARIFICATION]` markers
 - User says "clarify", "resolve ambiguities", "refine spec"
 - Before `/prizmkit-plan` to ensure spec is unambiguous
+- Whenever you encounter any uncertainty about what the user wants — proactively ask rather than assume
 
 **PRECONDITION:**
 
@@ -21,21 +22,38 @@ Interactive requirement clarification that resolves ambiguities in feature speci
 ## Execution Steps
 
 1. Read `spec.md` from `.prizmkit/specs/###-feature-name/`
-2. Scan for `[NEEDS CLARIFICATION]` markers and underspecified areas
+2. Scan for ALL ambiguities — not just `[NEEDS CLARIFICATION]` markers but also:
+   - Vague terms without measurable criteria (e.g., "fast", "user-friendly", "secure")
+   - Missing edge cases that would affect implementation
+   - Implicit assumptions not stated explicitly
+   - Scope boundaries that could be interpreted multiple ways
+   - Data model gaps (entities, relationships, constraints undefined)
 3. Categorize ambiguities by dimension and prioritize — address the ones that would most affect architecture and data model first, since those are hardest to change later:
    - Data model (what entities, relationships, constraints?) — **highest priority when DB changes are involved**: field types, nullability, naming conventions, relationships, and constraint patterns must all be resolved before plan finalization. Unresolved DB design decisions during implementation lead to expensive rework.
    - Functional scope (what does it do?)
-   - Data model (what entities, relationships?)
    - UX flow (what does the user see?)
    - Error handling (what happens when things fail?)
    - Non-functional requirements (performance, security)
    - Edge cases, integration points, accessibility
-4. Ask questions one at a time (max 5 per session) — batch questions overwhelm users and produce lower-quality answers because they rush through without thinking deeply about each one
+4. Ask questions **one at a time** — batch questions overwhelm users and produce lower-quality answers because they rush through without thinking deeply about each one
 5. For each question: provide a recommended answer with rationale. The recommendation gives users a concrete starting point to accept, modify, or reject — this is much faster than open-ended questions
 6. After each answer: immediately update `spec.md` (not batched at the end). Atomic updates mean the spec is always in a consistent state, even if the session is interrupted
-7. Support early termination: user says "done" or "stop" — end immediately
-8. Remove resolved `[NEEDS CLARIFICATION]` markers
-9. After all questions resolved or user terminates: output summary of changes made
+7. Remove resolved `[NEEDS CLARIFICATION]` markers as they are addressed
+8. **Continue asking** — after each answer, re-evaluate the spec for remaining ambiguities. Each user answer may reveal new questions. Keep going until:
+   - All `[NEEDS CLARIFICATION]` markers are removed, AND
+   - No vague or underspecified areas remain, AND
+   - You are fully confident about the requirements
+9. Support early termination: user says "done", "stop", or "enough" — end immediately and summarize what was resolved vs what remains unclear
+10. After all questions resolved or user terminates: output summary of all changes made
+
+## No Limits Policy
+
+**There is NO cap on the number of questions or rounds.** Ask as many questions as needed to achieve complete understanding. A half-understood spec leads to wrong implementations, which cost far more than thorough clarification upfront.
+
+- If you've asked 10 questions and there are still ambiguities — keep asking
+- If the user's answer raises new questions — ask those too
+- If you realize a previously-resolved item needs revisiting because of new context — go back and ask again
+- Only stop when you genuinely have no more uncertainties, or the user explicitly terminates
 
 ## Example Session
 
@@ -54,11 +72,19 @@ File upload: accepts JPEG, PNG, PDF, SVG. Max size: 25MB per file.
 ```
 Remove `[NEEDS CLARIFICATION]` marker from §3.2.
 
+**Question 2** (new question triggered by user's answer):
+> You mentioned SVG files. SVGs can contain embedded scripts which pose XSS risks. Should uploaded SVGs be sanitized (strip `<script>` tags and event handlers), or should SVG upload be restricted to trusted users only?
+>
+> **Recommended answer:** Sanitize all SVG uploads by stripping scripts and event handlers. This allows all users to upload SVGs safely.
+
+*(Continue until all ambiguities are resolved...)*
+
 ## Guidelines
 
 - Keep questions at the WHAT/WHY level — do not introduce implementation details (HOW). The spec describes the problem space; implementation choices belong in plan.md
-- 5-question limit per session keeps clarification focused. If more questions remain, tell the user and suggest running clarify again after they've had time to think
 - If the user's answer contradicts an existing requirement, point out the conflict and ask which one should change
+- Group related follow-up questions naturally — if a user's answer opens 3 related sub-questions, ask the most impactful one first, then proceed to the others
+- If the user seems fatigued, acknowledge it: "I have N more questions. Want to continue now or come back later?" — but never silently stop with unresolved ambiguities
 
 **HANDOFF:** `/prizmkit-plan`
 

package/bundled/skills/prizmkit-specify/SKILL.md

@@ -38,7 +38,7 @@ Create structured feature specifications from natural language descriptions. Thi
    - Acceptance criteria (Given/When/Then)
    - Scope boundaries (In scope / Out of scope)
    - Dependencies and constraints
-   - `[NEEDS CLARIFICATION]` markers for ambiguous items (max 3)
+   - `[NEEDS CLARIFICATION]` markers for all ambiguous items
 7. **Database design detection**: If the feature involves data persistence (new entities, new fields, schema changes), add a `## Data Model` section to spec.md (see template):
    - Scan for existing database schema files to understand current conventions:
      ```bash
@@ -51,7 +51,7 @@ Create structured feature specifications from natural language descriptions. Thi
 8. Run internal quality validation loop (max 3 iterations):
    - Check: All user stories have acceptance criteria?
    - Check: Scope boundaries clearly defined?
-   - Check: No more than 3 `[NEEDS CLARIFICATION]` markers?
+   - Check: All `[NEEDS CLARIFICATION]` markers have recommended defaults?
    - Check: If Data Model section exists, are existing schema conventions documented?
 9. Output: `spec.md` path and summary
 
@@ -60,7 +60,7 @@ Create structured feature specifications from natural language descriptions. Thi
 - **Focus on WHAT and WHY, never HOW** — the spec describes the problem space; implementation choices belong in plan.md. Mixing in tech stack details couples the spec to a specific solution and makes it harder to explore alternatives during planning.
 - **Every user story needs acceptance criteria** in Given/When/Then format — without them, the implementer has no way to verify the feature works correctly, and the code reviewer has no baseline to check against.
 - **Scope boundaries must be explicit** — without "Out of scope" boundaries, implementers tend to gold-plate features with capabilities nobody asked for, wasting time and adding complexity.
-- **Max 3 `[NEEDS CLARIFICATION]` markers** — more than 3 means the feature idea isn't mature enough to spec. Suggest the user think through the concept further and return, or use `/prizmkit-clarify` to resolve them interactively.
+- **Mark all unclear areas with `[NEEDS CLARIFICATION]`** — do not limit the number of markers. Every genuine ambiguity should be surfaced. After spec generation, suggest running `/prizmkit-clarify` to resolve them all interactively.
 - **Feature numbers are zero-padded to 3 digits** (e.g., `001`, `012`) with a `-MMDD` timestamp suffix — ensures consistent sorting and prevents collisions when multiple sessions run concurrently.
 
 ## Handling Vague Inputs

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prizmkit",
-  "version": "1.0.127",
+  "version": "1.0.129",
   "description": "Create a new PrizmKit-powered project with clean initialization — no framework dev files, just what you need.",
   "type": "module",
   "bin": {