@opengsd/gsd-pi 1.2.0 → 1.3.0-dev.72e3af2a

package/dist/resources/extensions/gsd/prompts/phase.md

@@ -0,0 +1,22 @@
+You are running the GSD **phase** workflow — CRUD for milestone ordering.
+
+## Action
+
+{{action}}
+
+## Process
+
+Work is modeled as an ordered milestone queue. Map the requested action onto the queue:
+
+- **add / insert <name>**: add a new milestone to the queue (or insert it at a position). Use `/gsd new-milestone` semantics then `/gsd queue` to position it.
+- **remove <id>**: remove a milestone from the queue (park it rather than hard-delete, to preserve history — confirm with the developer).
+- **edit <id>**: edit a milestone's title/scope in the ROADMAP/CONTEXT.
+- **list** (default): show the ordered milestone queue with state and progress.
+
+Confirm any destructive action (remove) before applying. Route structural changes through gsd-pi's queue/new-milestone/park commands rather than hand-editing state.
+
+## Success criteria
+
+- The action maps to the milestone queue, not a phase file.
+- Destructive actions are confirmed and prefer park-over-delete.
+- Structural changes go through gsd-pi commands, keeping state canonical.

package/dist/resources/extensions/gsd/prompts/plan-milestone.md

@@ -47,6 +47,8 @@ If milestone research is inlined, trust it and skip redundant exploration. If fi
 
 Narrate decomposition reasoning in complete sentences: grouping, risk order, verification strategy.
 
+**Web apps:** when inlined Web App UAT guidance is present, set milestone `Verification Classes` → UAT to browser-observable acceptance (Playwright spec or `browser_*` checks). Order an early slice to add Playwright smoke scaffolding when the dependency is missing.
+
 Then:
 1. Use the **Roadmap** output template from the inlined context above
 2. {{skillActivation}}
@@ -116,4 +118,4 @@ If external API keys or secrets are required, use the inlined **Secrets Manifest
 
 If no external API keys or secrets are required, skip this step; do not create an empty manifest.
 
-When done, say: "Milestone {{milestoneId}} planned."
+When done, say: "Milestone {{milestoneId}} planned." Say this exactly once — if you already said it in a prior message, do not repeat it.

package/dist/resources/extensions/gsd/prompts/plan-phase.md

@@ -0,0 +1,34 @@
+You are running the GSD **plan-phase** workflow — create a detailed plan for a milestone/slice with a verification loop.
+
+## Target
+
+{{target}}
+
+## Flags
+
+- `--auto` — {{autoFlag}}
+- `--research` / `--skip-research` — {{researchFlag}}
+- `--tdd` — {{tddFlag}} (plan test-first)
+
+## Process
+
+1. **Load authoritative context.** Read the milestone ROADMAP entry, CONTEXT, RESEARCH, the Decisions Register, and the discuss outcomes. Take a bounded codebase snapshot to ground the plan in current code reality.
+
+2. **Research (unless skipped).** If open questions remain and `--skip-research` is off, run a bounded research pass (grounded in the snapshot, not an open-ended survey). Fold findings into RESEARCH.
+
+3. **Decompose into slices/tasks.** Break the milestone into ordered, independently-verifiable slices; break each slice into concrete tasks. Each task has a clear definition of done and a verification method.
+
+4. **Plan test-first** (when `--tdd`): for each task, specify the test that proves it before specifying the implementation.
+
+5. **Verification loop.** Self-review the plan for gaps: missing tasks, unclear acceptance, orphaned requirements, unrealistic ordering. Revise until the plan is internally consistent.
+
+6. **Write the plan** to the milestone/slice's plan artifact in `.gsd/`. Record durable decisions via `/gsd knowledge rule`.
+
+7. **Route.** Recommend `/gsd dispatch execute` (or `/gsd next`).
+
+## Success criteria
+
+- Every requirement maps to at least one task.
+- Each task has a definition of done and a verification method.
+- The plan is grounded in current code (snapshot), not assumptions.
+- Durable decisions are persisted, not lost in the plan body.

package/dist/resources/extensions/gsd/prompts/plan-review-convergence.md

@@ -0,0 +1,34 @@
+You are running the GSD **plan-review-convergence** workflow — iterate a plan through review cycles until reviewer concerns are resolved or escalate.
+
+## Target
+
+{{target}}
+
+## Reviewers
+
+{{reviewers}}
+
+## Max cycles
+
+{{maxCycles}}
+
+## Process
+
+1. **Load the plan.** Read the target milestone/slice plan (and its requirements/CONTEXT). If no plan exists yet, suggest `/gsd dispatch plan` first.
+
+2. **Cycle loop** (bounded by max cycles):
+   a. **Review.** For each requested reviewer perspective, produce an independent review of the current plan. When an external AI CLI is unavailable in this runtime, simulate that reviewer's perspective using its documented focus and label it "simulated".
+   b. **Collect open concerns.** Merge and dedupe the concerns still outstanding after this cycle.
+   c. **Convergence check.** If there are no open concerns, stop — converged. If the same concerns recur across cycles without progress, stop — escalate rather than loop forever.
+   d. **Replan.** Revise the plan to address the open concerns, recording what changed and why. Re-run the review against the revised plan.
+
+3. **Outcome.** Report one of: `CONVERGED` (concerns resolved within the budget), `PARTIAL` (some concerns resolved, residual non-blocking ones listed), or `BLOCKED` (recurring concerns that need a human). Recommend the gsd-pi next step: `/gsd dispatch execute` if converged, or `/gsd dispatch replan` / human review if blocked.
+
+Never exceed the max cycles, and never claim convergence while open concerns remain.
+
+## Success criteria
+
+- Each cycle produces a fresh, independent review — not a rubber-stamp of the prior plan.
+- Unavailable external reviewers are simulated, not silently dropped.
+- The loop stops at convergence, at the cycle budget, or on a recurring-concern stall.
+- The reported outcome honestly reflects residual concerns.

package/dist/resources/extensions/gsd/prompts/plan-slice.md

@@ -41,10 +41,11 @@ If slice research is inlined, trust its architectural findings, but verify every
 3. Use the inlined Output Template sections already present in this prompt. Do not read template files from disk.
 4. {{skillActivation}} Record expected executor skills in each task plan's `skills_used` frontmatter.
 5. Define slice verification before tasks. Non-trivial slices need real tests or executable assertions; boundary contracts need contract-exercising checks. Tests must not read .gitignore/gitignored paths such as `.gsd/`, `.planning/`, or `.audits/`.
+   **Web apps:** when inlined Web App UAT guidance is present, follow it — add Playwright smoke scaffolding on the first UI slice if missing, name localhost preconditions, and plan verification commands that match browser-capable UAT modes at slice closeout.
 6. Include Threat Surface (Q3), Requirement Impact (Q4), proof level, observability, integration closure, Failure Modes (Q5), Load Profile (Q6), and Negative Tests (Q7) only where applicable.
 7. Right-size tasks. Simple slices can be one task; split only when context, ownership, or verification boundaries justify it.
 8. Task `verify` commands must be safe, simple commands. Do not use shell pipes, redirects, semicolons, backticks, command substitution, output trimming, or grep regex alternation with `|`. If multiple checks are needed, create a small test file and run it with `node --test` or a package test script, or use separate simple commands joined only with `&&`. For absence checks, verify a pattern does not exist with `! grep -q 'pattern' file` or `! rg -q 'pattern' file`; do not use `grep -c` or `rg -c` to assert zero matches because count commands exit 1 when they find zero matches, and the verification gate treats that as failure.
-9. Each task needs the exact `gsd_plan_slice.tasks[]` shape: `taskId`, `title`, `description`, `estimate`, `files`, `verify`, `inputs`, `expectedOutput`, and optional `observabilityImpact`. `description` should contain the Why / Do / Done-when narrative. `files`, `inputs`, and `expectedOutput` must be JSON arrays of strings, even when there is only one path (for example, `"inputs": ["src/index.ts"]`, never `"inputs": "src/index.ts"`). Use paths relative to `{{workingDirectory}}`; do not put absolute paths to the original checkout or any directory outside `{{workingDirectory}}` in `files`, `inputs`, `expectedOutput`, or verification commands. **`expectedOutput` must only list files the task actually creates or overwrites on disk.** Do NOT include files the task merely reads, verifies, tests, or describes — those belong in `inputs`, `verify`, `description`, or slice success criteria. If a task is a pure verification or test task that produces no new files, `expectedOutput` must be `[]`; if it writes a test-result log or assertion output file, list only that concrete file path. A file that does not yet exist on disk and is needed as an `input` must be produced by an earlier task's `expectedOutput` — if no prior task creates it, add a task before this one that does.
+9. Each task needs the exact `gsd_plan_slice.tasks[]` shape: `taskId`, `title`, `description`, `estimate`, `files`, `verify`, `inputs`, `expectedOutput`, and optional `observabilityImpact`. `description` should contain the Why / Do / Done-when narrative. `files`, `inputs`, and `expectedOutput` must be JSON arrays of strings, even when there is only one path (for example, `"inputs": ["src/index.ts"]`, never `"inputs": "src/index.ts"`). Use paths relative to `{{workingDirectory}}`; do not put absolute paths to the original checkout or any directory outside `{{workingDirectory}}` in `files`, `inputs`, `expectedOutput`, or verification commands. **`expectedOutput` must only list files the task actually creates or overwrites on disk.** Do NOT include files the task merely reads, verifies, tests, or describes — those belong in `inputs`, `verify`, `description`, or slice success criteria. If a task is a pure verification or test task that produces no new files, `expectedOutput` must be `[]`; if it writes a test-result log or assertion output file, list only that concrete file path. A file that does not yet exist on disk and is needed as an `input` must be produced by an earlier task's `expectedOutput` — if no prior task creates it, add a task before this one that does. Never list GSD planning artifacts — anything under `.gsd/`, `.planning/`, or `.audits/`, or artifact names like `M001-CONTEXT.md` / `S01-PLAN.md` — in `inputs`, `files`, or `expectedOutput`: their content is preloaded as context, and they are written by workflow tools, not by tasks.
 10. Persist with `gsd_plan_slice` using `milestoneId`, `sliceId`, `goal`, optional `successCriteria`/`proofLevel`/`integrationClosure`/`observabilityImpact`, and `tasks`. `gsd_plan_slice` handles task persistence transactionally and renders `{{outputPath}}` plus task plans; do not call `gsd_plan_task`. The DB-backed tool is the canonical write path. Do **not** rely on direct `PLAN.md` writes as the source of truth.
 11. Self-audit before finishing: goal/demo closure, requirement coverage, deliverable coverage audit (cross-check every file listed in CONTEXT.md `## Scope` / `### In Scope` against task `files` or `expectedOutput`), locked decisions, concrete paths, dependency order, wiring, scope size, proof truthfulness, feature completeness, and quality gates. Quality gates: non-trivial slices/tasks include specific Q3-Q7 coverage where applicable.
 12. If planning creates structural decisions, call `gsd_decision_save` for each; the tool persists the decision and regenerates `.gsd/DECISIONS.md`.
@@ -56,4 +57,4 @@ The slice directory already exists. Do not mkdir.
 
 **You MUST call `gsd_plan_slice` to persist planning state before finishing, unless the stale-path safety rule above stops the unit before safe planning can occur.**
 
-When done, say: "Slice {{sliceId}} planned."
+When done, say: "Slice {{sliceId}} planned." Say this exactly once — if you already said it in a prior message, do not repeat it.

package/dist/resources/extensions/gsd/prompts/profile-user.md

@@ -0,0 +1,28 @@
+You are running the GSD **profile-user** workflow — generate a developer behavioral profile to personalize GSD's defaults, and persist it so future sessions use it.
+
+## Flags
+
+- `--questionnaire` — {{questionnaireFlag}} (run the full questionnaire instead of inferring)
+- `--refresh` — {{refreshFlag}} (re-profile even if a profile exists)
+
+## Process
+
+1. **Check for an existing profile.** If one exists and `--refresh` is off, show it and ask whether to refresh.
+
+2. **Gather the profile.** Either run the structured questionnaire (`--questionnaire`) or infer from the session + recent activity. Capture:
+   - Preferred verbosity (concise vs. thorough).
+   - Risk appetite (prefer safe/verified vs. fast/experimental).
+   - Commit style and granularity.
+   - Testing preference (TDD-first vs. test-after).
+   - Review preference (self-review only vs. convergence/multi-reviewer).
+   - Preferred tools/runtimes and any to avoid.
+
+3. **Map the profile to gsd-pi preferences.** Translate each preference to the matching gsd-pi setting (auto-mode behavior, commit granularity, review depth, model tier hints) via `/gsd prefs`.
+
+4. **Persist.** Write the profile into gsd-pi preferences so future sessions apply it. Print a summary of what was set.
+
+## Success criteria
+
+- The profile captures concrete preferences, not vague adjectives.
+- Each preference maps to an actual gsd-pi setting (no orphan preferences).
+- The profile persists in preferences, not a throwaway file.

package/dist/resources/extensions/gsd/prompts/progress.md

@@ -0,0 +1,30 @@
+You are running the GSD **progress** workflow — give situational awareness: where the project is, what was just done, and what's next.
+
+## Mode
+
+{{mode}}
+
+## Process
+
+1. **Load state.** Read the active milestone, its slices and tasks, and the last completed unit. Determine what is queued or in-flight.
+
+2. **Summarize recent work.** In 2–4 bullets, describe what was most recently completed (which slice/task, the outcome). Ground this in the canonical state, not memory.
+
+3. **Show what's next.** Identify the next unit to run. If there is an active slice with pending tasks, the next step is usually executing the next task. If the active slice is complete, the next step is completing the slice. If the milestone is complete, the next step is validation.
+
+4. **Route.** Based on `{{mode}}`:
+   - Default: present the summary and recommend the next command (e.g. `/gsd next`, `/gsd auto`, `/gsd dispatch validate`).
+   - `--next`: after summarizing, dispatch the single next unit (equivalent to `/gsd next`).
+   - `--forensic`: include the recent execution history and any drift/blockers.
+   - `--do "<task>"`: route the freeform task via `/gsd do`.
+
+   Never auto-advance past a closeout boundary without confirmation.
+
+If no `.gsd/` project exists, say so and suggest `/gsd init`.
+
+## Success criteria
+
+- Recent-work summary is grounded in canonical state.
+- The recommended next step matches the milestone/slice lifecycle position.
+- Forensic mode surfaces drift/blockers when present.
+- Closeout boundaries are respected (stop and confirm, don't barrel through).

package/dist/resources/extensions/gsd/prompts/quick-task.md

@@ -37,4 +37,4 @@ You are executing a GSD quick task — a lightweight, focused unit of work outsi
 - <what was tested/verified>
 ```
 
-When done, say: "Quick task {{taskNum}} complete."
+When done, say: "Quick task {{taskNum}} closeout submitted." Do not say the task is complete. Say this exactly once — if you already said it in a prior message, do not repeat it.

package/dist/resources/extensions/gsd/prompts/reactive-execute.md

@@ -10,7 +10,7 @@ You are executing **multiple tasks in parallel** for this slice. The task graph
 
 **Critical rule:** Use the `subagent` tool in **parallel mode** to dispatch all ready tasks simultaneously. Each subagent gets a task-specific execution packet (task plan + dependency carry-forward + completion contract) and is responsible for its own implementation, verification, task summary, and completion tool calls. The parent batch agent orchestrates, verifies, and records failures only when a dispatched task failed before it could leave its own summary behind.
 
-**Tool call format:** Call `subagent` with `tasks: [...]` as a **native JSON array** — one object per ready task. Do NOT JSON.stringify the array into a string; the tool validates that `tasks` is an array, and a serialized string will be rejected with "must be array".
+**Tool call format:** Call `subagent` with `tasks: [...]` as a **native JSON array** — one object per ready task. Each task object MUST include `cwd: "{{workingDirectory}}"` so child agents inherit the milestone worktree, not the project root. Do NOT JSON.stringify the array into a string; the tool validates that `tasks` is an array, and a serialized string will be rejected with "must be array".
 
 ## Task Dependency Graph
 
@@ -24,7 +24,7 @@ You are executing **multiple tasks in parallel** for this slice. The task graph
 
 ## Execution Protocol
 
-1. **Dispatch all ready tasks** using `subagent` in parallel mode. Call `subagent` with `tasks: [{ agent: "worker", task: "<prompt>" }, ...]` — one object per ready task. Each subagent prompt is provided below.
+1. **Dispatch all ready tasks** using `subagent` in parallel mode. Call `subagent` with `tasks: [{ agent: "worker", cwd: "{{workingDirectory}}", task: "<prompt>" }, ...]` — one object per ready task. Each subagent prompt is provided below.
 2. **Wait for all subagents** to complete.
 3. **Verify each dispatched task's outputs** — check that expected files were created/modified, that verification commands pass where applicable, and that each task wrote its own `T##-SUMMARY.md`.
 4. **Do not rewrite successful task summaries or duplicate completion tool calls.** Treat a subagent-written summary as authoritative for that task.

package/dist/resources/extensions/gsd/prompts/reassess-roadmap.md

@@ -67,4 +67,4 @@ If `.gsd/REQUIREMENTS.md` exists and requirement ownership or status changed, up
 
 **DB access safety:** Do NOT query `.gsd/gsd.db` directly via `sqlite3` or `node -e require('better-sqlite3')`. Use `gsd_milestone_status` to read current milestone and slice state. All roadmap mutations go through `gsd_reassess_roadmap` — the tool writes to the DB and re-renders ROADMAP.md atomically.
 
-When done, say: "Roadmap reassessed."
+When done, say: "Roadmap reassessed." Say this exactly once — if you already said it in a prior message, do not repeat it.

package/dist/resources/extensions/gsd/prompts/refine-slice.md

@@ -63,8 +63,9 @@ Then:
    - `{{taskPlanTemplatePath}}`
 2. {{skillActivation}} Record the installed skills you expect executors to use in each task plan's `skills_used` frontmatter.
 3. Define slice-level verification: the objective stopping condition. Plan real test files with real assertions; for simple slices, executable commands are fine.
+   **Web apps:** when inlined Web App UAT guidance is present, follow it for Playwright scaffolding and browser-capable verification commands.
 4. For non-trivial slices, plan observability / proof level / integration closure, threat surface, and requirement impact. Omit entirely for simple slices.
-5. Decompose the slice into tasks that fit one context window each. Every task passed to `gsd_plan_slice` must use the exact keys `taskId`, `title`, `description`, `estimate`, `files`, `verify`, `inputs`, `expectedOutput`, and optional `observabilityImpact`. Put Why / Do / Done-when detail in `description`. `files`, `inputs`, and `expectedOutput` must be JSON arrays of strings, even for one path (for example, `"expectedOutput": ["src/index.ts"]`, never `"expectedOutput": "src/index.ts"`). `expectedOutput` is path-only: list only files the task creates or overwrites, and use `[]` for pure verification tasks.
+5. Decompose the slice into tasks that fit one context window each. Every task passed to `gsd_plan_slice` must use the exact keys `taskId`, `title`, `description`, `estimate`, `files`, `verify`, `inputs`, `expectedOutput`, and optional `observabilityImpact`. Put Why / Do / Done-when detail in `description`. `files`, `inputs`, and `expectedOutput` must be JSON arrays of strings, even for one path (for example, `"expectedOutput": ["src/index.ts"]`, never `"expectedOutput": "src/index.ts"`). `expectedOutput` is path-only: list only files the task creates or overwrites, and use `[]` for pure verification tasks. Never list GSD planning artifacts — anything under `.gsd/`, `.planning/`, or `.audits/`, or artifact names like `M001-CONTEXT.md` / `S01-PLAN.md` — in `inputs`, `files`, or `expectedOutput`: their content is preloaded as context, and they are written by workflow tools, not by tasks.
 6. **Persist planning state through `gsd_plan_slice`.** Call it with the full payload. The tool writes to the DB and renders `{{outputPath}}` and `{{slicePath}}/tasks/T##-PLAN.md` automatically. Do NOT rely on direct `PLAN.md` writes.
 7. **Self-audit the plan.** If every task were completed exactly as written, the slice goal/demo should be true. Every must-have maps to a task. Inputs and Expected Output are backtick-wrapped file paths.
 8. If refinement produced structural decisions that diverge from the sketch, call `gsd_decision_save` for each; the tool persists the decision and regenerates `.gsd/DECISIONS.md`.
@@ -76,4 +77,4 @@ The slice directory and tasks/ subdirectory already exist. Do NOT mkdir.
 
 **You MUST call `gsd_plan_slice` to persist planning state before finishing.** After success, the pipeline clears the sketch flag on next state derivation; the on-disk PLAN file is the signal.
 
-When done, say: "Slice {{sliceId}} refined."
+When done, say: "Slice {{sliceId}} refined." Say this exactly once — if you already said it in a prior message, do not repeat it.

package/dist/resources/extensions/gsd/prompts/replan-slice.md

@@ -34,8 +34,8 @@ Consider these captures when rewriting the remaining tasks — they represent th
 
 1. Use the inlined blocker summary excerpt first. Read the full blocker task summary only if the excerpt is absent, marked truncated, or lacks the specific blocker evidence needed to replan.
 2. Analyze the remaining `[ ]` tasks in the slice plan. Determine which are still valid, which need modification, and which should be replaced.
-3. **Persist replan state through `gsd_replan_slice`.** Call it with: `milestoneId`, `sliceId`, `blockerTaskId`, `blockerDescription`, `whatChanged`, `updatedTasks` (array of task objects with taskId, title, description, estimate, files, verify, inputs, expectedOutput), `removedTaskIds` (array of task ID strings). The tool structurally enforces preservation of completed tasks, writes replan history to the DB, re-renders `{{planPath}}`, and renders `{{replanPath}}`. Preserve or update the Threat Surface and Requirement Impact sections if the replan changes the slice's security posture or requirement coverage.
+3. **Persist replan state through `gsd_replan_slice`.** Call it with: `milestoneId`, `sliceId`, `blockerTaskId`, `blockerDescription`, `whatChanged`, `updatedTasks` (array of task objects with taskId, title, description, estimate, files, verify, inputs, expectedOutput), `removedTaskIds` (array of task ID strings). Never list GSD planning artifacts — anything under `.gsd/`, `.planning/`, or `.audits/`, or artifact names like `M001-CONTEXT.md` / `S01-PLAN.md` — in `inputs`, `files`, or `expectedOutput`: their content is preloaded as context, and they are written by workflow tools, not by tasks. The tool structurally enforces preservation of completed tasks, writes replan history to the DB, re-renders `{{planPath}}`, and renders `{{replanPath}}`. Preserve or update the Threat Surface and Requirement Impact sections if the replan changes the slice's security posture or requirement coverage.
 4. If any incomplete task had a `T0x-PLAN.md`, remove or rewrite it to match the new task description.
 5. Do not commit manually — the system auto-commits your changes after this unit completes.
 
-When done, say: "Slice {{sliceId}} replanned."
+When done, say: "Slice {{sliceId}} replanned." Say this exactly once — if you already said it in a prior message, do not repeat it.

package/dist/resources/extensions/gsd/prompts/research-milestone.md

@@ -46,4 +46,4 @@ Then research the codebase and relevant technologies. Narrate key findings and s
 
 **You MUST call `gsd_summary_save` with the research content before finishing.**
 
-When done, say: "Milestone {{milestoneId}} researched."
+When done, say: "Milestone {{milestoneId}} researched." Say this exactly once — if you already said it in a prior message, do not repeat it.

package/dist/resources/extensions/gsd/prompts/research-slice.md

@@ -55,4 +55,4 @@ The slice directory already exists at `{{slicePath}}/`. Do NOT mkdir.
 
 **You MUST call `gsd_summary_save` with the research content before finishing.**
 
-When done, say: "Slice {{sliceId}} researched."
+When done, say: "Slice {{sliceId}} researched." Say this exactly once — if you already said it in a prior message, do not repeat it.

package/dist/resources/extensions/gsd/prompts/resume-work.md

@@ -0,0 +1,20 @@
+You are running the GSD **resume-work** workflow — resume work from a previous session with full context restoration.
+
+## Process
+
+1. **Reconcile state.** Read the canonical gsd-pi state (DB + markdown projections) and run reconciliation so any drift between disk and DB is repaired before resuming. Do not resume on top of drift.
+
+2. **Load the handoff.** Read any `HANDOFF.md` or pause notes in `.gsd/` to recover the intended next step, open threads, and in-flight work the prior session left.
+
+3. **Reconstruct context.** Combine: the active milestone/slice/task, the last completed unit, the open threads, and a bounded codebase snapshot of what was being edited. This is the resume context — present a concise summary.
+
+4. **Resume the work.** Pick up at the explicit resume instruction. If the handoff named a specific next action, do that. If state has moved on (e.g. the task was completed by another worker), detect it and re-derive the next step from canonical state rather than blindly following a stale handoff.
+
+5. **Re-enter the lifecycle.** Hand control to the appropriate gsd-pi command (`/gsd next`, `/gsd auto`, or a specific dispatch) to continue.
+
+## Success criteria
+
+- State is reconciled before resuming (no resuming on drift).
+- The handoff is honored unless canonical state contradicts it.
+- The resume summary is concise and grounded in state.
+- Control returns to the gsd-pi lifecycle rather than ad-hoc work.

package/dist/resources/extensions/gsd/prompts/review-backlog.md

@@ -0,0 +1,21 @@
+You are running the GSD **review-backlog** workflow — review backlog items and promote ready ones to active milestones.
+
+## Process
+
+1. **Load the backlog.** Read all backlog items with their metadata (added date, trigger conditions, notes, priority hints).
+
+2. **Triage each item** into one of:
+   - **promote**: ready to become an active milestone now (clear scope, dependency met, value justifies it).
+   - **keep**: not yet ready (blocked, low value now, trigger not met) — record why.
+   - **discard**: no longer relevant (superseded, done elsewhere, obsolete) — archive with a reason.
+
+3. **Present the triage** grouped by recommendation, with the reasoning for each. Let the developer confirm promotions and discards.
+
+4. **Act on confirmation**: promote selected items via `/gsd backlog promote` (then `/gsd new-milestone` to scope them), and archive discards. Do not promote or discard without explicit confirmation.
+
+## Success criteria
+
+- Every backlog item gets a triage recommendation with reasoning.
+- Promotions and discards require explicit confirmation.
+- Trigger conditions are checked before recommending promotion.
+- Actions route through gsd-pi's backlog commands.

package/dist/resources/extensions/gsd/prompts/review.md

@@ -0,0 +1,27 @@
+You are running the GSD **review** workflow — peer review of recent work, optionally across multiple AI reviewers.
+
+## Target
+
+{{target}}
+
+## Reviewers
+
+{{reviewers}}
+
+## Process
+
+1. **Identify what to review.** Use the explicit milestone/slice target if given; otherwise review the active slice's plan and recent execution. Gather the plan, the SUMMARY/ASSESSMENT, and the diff against the base branch.
+
+2. **Run the review.** For each requested reviewer perspective, produce an independent review covering: correctness vs. intent, missed requirements, risk/regression, and verification gaps. When a reviewer is an external AI CLI not available in this runtime, perform that reviewer's perspective yourself using its documented focus, and label it as "simulated".
+
+3. **Collect concerns.** Merge the per-reviewer concerns into a single deduplicated list, each tagged with which reviewer(s) raised it and a severity.
+
+4. **Route.** Recommend the next action: if concerns are minor, proceed to `/gsd dispatch validate`; if concerns need rework, recommend `/gsd dispatch replan` or `/gsd next`; if a concern is a blocker, surface it clearly.
+
+Do not block on unavailable external reviewers — simulate their perspective and continue.
+
+## Success criteria
+
+- Each concern is tied to a reviewer and grounded in the plan/diff.
+- Unavailable external reviewers are simulated, not silently skipped.
+- The recommended next action matches the severity of the concerns.

package/dist/resources/extensions/gsd/prompts/rewrite-docs.md

@@ -30,4 +30,4 @@ An override was issued by the user that changes a fundamental decision or approa
 
 **You MUST update the relevant documents AND mark overrides as resolved in `{{overridesPath}}` before finishing.**
 
-When done, say: "Override applied across all documents."
+When done, say: "Override applied across all documents." Say this exactly once — if you already said it in a prior message, do not repeat it.

package/dist/resources/extensions/gsd/prompts/run-uat.md

@@ -10,6 +10,8 @@ If any inlined plan, summary, verification command, or prior artifact names an a
 
 All relevant context has been preloaded below. Start working immediately without re-reading these files.
 
+If a `.gsd/**` or `.gsd/**/*` glob returns no matches, treat that as a possible symlink-backed traversal limitation; do not infer that the GSD harness is missing. Use the preloaded UAT context and direct `.gsd/...` file paths named in this prompt instead.
+
 {{inlinedContext}}
 
 {{skillActivation}}
@@ -27,21 +29,23 @@ You are the UAT runner. Execute every check defined in `{{uatPath}}` as deeply a
 ### Automation rules by mode
 
 - `artifact-driven` — verify with shell commands, scripts, file reads, and artifact structure checks.
-- `browser-executable` — use browser tools to navigate to the target URL and verify expected behavior. Prefer direct `browser_*` tools when available. Capture screenshots as evidence. Record pass/fail with specific assertions.
-- `runtime-executable` — execute the specified command or script. Capture stdout/stderr as evidence. Record pass/fail based on exit code and output.
+- `browser-executable` — use browser tools to navigate to the target URL and verify expected behavior. Prefer direct `browser_*` tools when available. Capture screenshots as evidence. Record pass/fail with specific assertions. When the UAT **Evidence** section names a self-contained runtime harness (for example `npm run test:uat` or `node tests/browser/search-uat.mjs`), treat the effective mode as **runtime-executable** instead: run that command only and do not start a separate server or `browser_navigate` to a hardcoded localhost port.
+- `runtime-executable` — execute the specified command or script. Capture stdout/stderr as evidence. Record pass/fail based on exit code and output. When the verification script starts its own dev/static server (for example `node tests/browser/search-uat.mjs`), do **not** start a separate server with `uat-service-start` — the script owns server lifecycle and binds an ephemeral port. If a server is already running, pass its URL via `UAT_BASE_URL` or `PORT` in the `gsd_uat_exec` environment instead of hardcoding a fixed port like 4173.
 - `live-runtime` — exercise the real runtime path. Start or connect to the app/service if needed, use browser/runtime/network checks, and verify observable behavior.
 - `mixed` — run all automatable artifact-driven and live-runtime checks. Separate any remaining human-only checks explicitly.
 - `human-experience` — automate setup, preconditions, screenshots, logs, and objective checks, but do **not** invent subjective PASS results. Mark taste-based, experiential, or purely human-judgment checks as `NEEDS-HUMAN`. Use an overall verdict of `PASS` when all automatable checks succeed (even if human-only checks remain as `NEEDS-HUMAN`). Use `PARTIAL` only when automatable checks themselves were inconclusive.
 
 ### Evidence tools
 
-Choose the lightest tool that proves the check honestly:
+The **Tool Surface** block prepended above lists unavailable tools for this unit. In short:
 
 - Run automated checks with `gsd_uat_exec`
   - Use `uat-artifact-check` as `intent` for static file, grep, structure, or artifact checks.
   - Use `uat-runtime-check` as `intent` for executing tests, scripts, or runtime assertions.
   - Use `uat-browser-check` as `intent` for browser interaction or screenshot-backed UI checks.
-  - Use `uat-service-start` as `intent` only when starting or connecting to an app/service.
+  - Use `uat-service-start` as `intent` only when starting or connecting to an app/service that the UAT checks will not start themselves.
+  - Do not start a dev/static server separately when a runtime test script owns server lifecycle — run the script directly instead.
+  - When you do start a service, capture the URL from its stdout (for example `Ready at http://127.0.0.1:PORT`) and pass it to downstream checks via `UAT_BASE_URL` rather than assuming a fixed port.
   - Use `uat-log-inspection` as `intent` for checking logs or captured output files.
   - The result-table evidence mode is separate; do not use `artifact`, `runtime`, or `human-follow-up` as `intent`.
 - Run `grep` / `rg` checks against files
@@ -98,4 +102,8 @@ checks: [{
 
 **You MUST call `gsd_uat_result_save` before finishing. Do not write the assessment file directly, and do not call `gsd_summary_save` as a substitute.**
 
-When done, say: "UAT {{sliceId}} complete."
+### Closeout messaging (auto-mode)
+
+You submit UAT results; **GSD auto-mode** decides when UAT is actually **done**. Never say "UAT {{sliceId}} complete" in this unit — not even after `gsd_uat_result_save` succeeds. GSD announces completion only after post-unit verification passes.
+
+When done, say: "UAT {{sliceId}} results submitted." Do not say UAT is complete. Say this exactly once — if you already said it in a prior message, do not repeat it.

package/dist/resources/extensions/gsd/prompts/secure-phase.md

@@ -0,0 +1,24 @@
+You are running the GSD **secure-phase** workflow — retroactively verify threat mitigations for completed work.
+
+## Target
+
+{{target}}
+
+## Process
+
+1. **Load the threat context.** Read any security/threat notes for the target (milestone plan, CONTEXT, KNOWLEDGE security rules). If none exist, derive threats from the work itself: auth, authorization, input validation, secrets handling, data exposure, dependency risk.
+
+2. **For each identified threat, confirm its mitigation.** Trace the threat to where the code mitigates it. Classify each: `mitigated` (evidence in code), `partial` (mitigation incomplete), `unmitigated` (no evidence), or `not-applicable`.
+
+3. **Verify the mitigations hold.** Where a mitigation is a test, confirm the test exists and covers the threat. Where it's a code pattern, confirm it's applied consistently (not just in the happy path).
+
+4. **Update the security record.** Write/append `.gsd/SECURITY.md` (or the project's security doc) with the threat-mitigation table and any new findings. Record durable security rules via `/gsd knowledge rule`.
+
+5. **Report.** Summarize: mitigated count, partial/unmitigated findings (critical first), and recommended remediation.
+
+## Success criteria
+
+- Every threat is traced to a mitigation (or flagged unmitigated) with code evidence.
+- Mitigations are verified for consistency, not just presence.
+- The security record is updated, not just printed.
+- Partial/unmitigated findings are prioritized and actionable.

package/dist/resources/extensions/gsd/prompts/settings.md

@@ -0,0 +1,24 @@
+You are running the GSD **settings** workflow — configure GSD workflow toggles and the model profile.
+
+## Process
+
+This is the settings flow: present the current effective configuration and let the developer change it.
+
+1. **Show effective settings.** Display the current configuration: active provider/model, model profile, auto-mode toggles, commit granularity, review depth, isolation mode, language, and any feature flags. Pull these from gsd-pi's config overlay, not memory.
+
+2. **Offer changes**, grouped:
+   - **LLM**: provider, model, default tier — `/gsd setup llm` / `/gsd model`.
+   - **Workflow**: auto-mode behavior, isolation mode, commit granularity — `/gsd prefs`.
+   - **Keys**: API keys — `/gsd keys`.
+   - **Integrations**: remote, search, cmux — `/gsd setup remote|search`, `/gsd cmux`.
+   - **Onboarding**: re-run the wizard — `/gsd onboarding`.
+
+3. **Apply the selection** by routing to the matching gsd-pi command. Confirm before changing anything destructive (e.g. switching provider, wiping keys).
+
+4. **Re-show** the effective settings after changes.
+
+## Success criteria
+
+- The displayed settings reflect the real config overlay.
+- Every change routes to the real gsd-pi command, keeping state canonical.
+- Destructive changes are confirmed.

package/dist/resources/extensions/gsd/prompts/sketch.md

@@ -0,0 +1,59 @@
+You are running the GSD **sketch** workflow — explore UI/design ideas with throwaway HTML mockups that let the developer feel a design before committing to implementation.
+
+## Design Idea
+
+{{input}}
+
+## Flags
+
+- `--quick` — {{quickFlag}} (when true, skip decomposition and jump straight to a single mockup)
+- `--text` — {{textFlag}} (when true, use plain-text numbered lists instead of interactive prompts)
+- Frontier mode — {{frontierFlag}} (when true, analyze existing sketches and propose what to sketch next instead of a new one)
+
+## Process
+
+### 1. Route the input
+
+- If frontier mode is active (no idea given, or the word "frontier"): go to **Frontier mode**.
+- Otherwise: continue to **Setup**.
+
+### 2. Setup
+
+Create `.gsd/sketches/` if it does not exist and determine the next sketch number by listing existing `.gsd/sketches/[0-9][0-9][0-9]-*` directories.
+
+### 3. Decompose the design (skip if `--quick`)
+
+If the design idea has multiple surfaces (e.g. landing page, dashboard, empty state), break it into focused mockups. Each should explore one surface or one interaction. Order by the most uncertain design direction first.
+
+### 4. Align on direction
+
+Briefly confirm scope and any constraints (brand, target device, accessibility). Keep this short — sketches are cheap and disposable.
+
+### 5. Build
+
+Create `.gsd/sketches/{{sketchId}}/` and build each mockup as a self-contained `index.html` (inline CSS/JS, no build step). Open it in the browser via the project's tooling so the developer can see and react to it.
+
+### 6. Observe and refine
+
+Let the developer react to each mockup. Iterate quickly on the throwaway HTML. Capture the design decisions that emerge (layout, color, motion, copy).
+
+### 7. Document
+
+Write `.gsd/sketches/{{sketchId}}/README.md` with:
+- The design idea and the surfaces explored
+- The mockup files and what each demonstrates
+- Design decisions captured and their rationale
+- Recommendations for the real implementation
+
+Append a one-line summary to `.gsd/CAPTURES.md` linking the README.
+
+### 8. Frontier mode (only when frontier flag is active)
+
+Load the sketch landscape: read `.gsd/sketches/*/README.md`. Analyze for **integration sketches** (sketches that touch the same flow) and **frontier sketches** (unexplored surfaces, alternative directions, empty/loading/error states). Present concrete candidates and let the developer choose which to run.
+
+## Success criteria
+
+- Each mockup is a self-contained `index.html` with no build step.
+- Artifacts live under `.gsd/sketches/{{sketchId}}/`.
+- The README captures design decisions usable by the real implementation.
+- Iteration is fast and the sketches stay disposable.

package/dist/resources/extensions/gsd/prompts/spec-phase.md

@@ -0,0 +1,29 @@
+You are running the GSD **spec-phase** workflow — clarify WHAT a milestone/slice delivers, with ambiguity scoring, before discussion or planning.
+
+## Target
+
+{{target}}
+
+## Flags
+
+- `--auto` — {{autoFlag}}
+- `--text` — {{textFlag}}
+
+## Process
+
+1. **Load intent.** Read the milestone/slice's stated goal, requirements, and any discuss/research context.
+
+2. **Draft the SPEC.** State, in plain language: what this delivers, for whom, the inputs/outputs, the success criteria, and explicit non-goals.
+
+3. **Score ambiguity.** For each part of the spec, score ambiguity (low/medium/high) and identify the specific phrase causing it. High-ambiguity items become discussion questions.
+
+4. **Resolve ambiguity.** For each high-ambiguity item: in `--auto`, infer and flag; otherwise ask one targeted question at a time to resolve it. Update the spec with the resolved language.
+
+5. **Write the SPEC** to the milestone/slice artifact in `.gsd/`. Recommend `/gsd discuss-phase` (deeper discussion) or `/gsd plan-phase` (the spec is clear enough to plan).
+
+## Success criteria
+
+- The spec states WHAT, not HOW.
+- Every high-ambiguity item is resolved or explicitly deferred with a reason.
+- Non-goals are explicit.
+- The recommended next step reflects remaining ambiguity.

package/dist/resources/extensions/gsd/prompts/spike.md

@@ -0,0 +1,59 @@
+You are running the GSD **spike** workflow — experiential exploration that builds focused experiments to validate feasibility and produce verified knowledge for the real build.
+
+## Spike Input
+
+{{input}}
+
+## Flags
+
+- `--quick` — {{quickFlag}} (when true, skip decomposition/alignment and jump straight to building)
+- `--text` — {{textFlag}} (when true, use plain-text numbered lists instead of interactive prompts)
+- Frontier mode — {{frontierFlag}} (when true, analyze existing spikes and propose integration/frontier spikes instead of a new one)
+
+## Process
+
+### 1. Route the input
+
+- If frontier mode is active (no idea given, or the word "frontier"): go to **Frontier mode**.
+- Otherwise: continue to **Setup**.
+
+### 2. Setup
+
+Create `.gsd/spikes/` if it does not exist and determine the next spike number by listing existing `.gsd/spikes/[0-9][0-9][0-9]-*` directories. Use the project's detected stack (check `package.json` / `pyproject.toml` / `Cargo.toml` / `go.mod`) to choose technology. Avoid heavy tooling — pick whatever reaches a runnable result fastest.
+
+### 3. Decompose the idea (skip if `--quick`)
+
+Break the idea into 1–3 focused experiments. Each experiment should validate one specific risk or assumption with a clear **Given/When/Then** validation question. Order by highest risk first.
+
+### 4. Research (brief)
+
+For each experiment, do the minimum research needed to start building — library docs, API shape, known gotchas. Use `resolve_library`/docs lookups. Do not over-research.
+
+### 5. Build
+
+Create `.gsd/spikes/{{spikeId}}/` and build each experiment as a small, self-contained, runnable artifact. Prefer throwaway code that proves the point. Hardcode configuration — do not build config systems.
+
+### 6. Verify
+
+For each experiment, run the validation question and record a verdict: `VALIDATED`, `PARTIAL`, or `INVALIDATED`, with the evidence (command output, observed behavior).
+
+### 7. Document
+
+Write `.gsd/spikes/{{spikeId}}/README.md` with:
+- The original idea and the experiments run
+- Per-experiment verdict + evidence
+- Conclusions and recommendations for the real build
+- Any conventions discovered worth recording (stack, patterns)
+
+Append a one-line summary to `.gsd/CAPTURES.md` linking the README so the spike is discoverable.
+
+### 8. Frontier mode (only when frontier flag is active)
+
+Load the spike landscape: read `.gsd/spikes/*/README.md` and any `CONVENTIONS.md`. Analyze for **integration spikes** (validated spikes that share resources, hand off data, or contend) and **frontier spikes** (gaps, discovered dependencies, alternative approaches). Present concrete candidates with Given/When/Then questions and let the developer choose which to run.
+
+## Success criteria
+
+- Each experiment has a clear validation question and a recorded verdict with evidence.
+- Artifacts live under `.gsd/spikes/{{spikeId}}/`.
+- The README captures conclusions usable by the real build.
+- No heavy infrastructure, build systems, or config layers unless the spike specifically requires them.