@opengsd/gsd-pi 1.2.0-dev.fbdca60b → 1.3.0-dev.65546769

package/src/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/src/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/src/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/src/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." Say this exactly once — if you already said it in a prior message, do not repeat it.
+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/src/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/src/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/src/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/src/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/src/resources/extensions/gsd/prompts/run-uat.md

@@ -102,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." Say this exactly once — if you already said it in a prior message, do not repeat it.
+### 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/src/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/src/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/src/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/src/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/src/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.

package/src/resources/extensions/gsd/prompts/stats.md

@@ -0,0 +1,43 @@
+You are running the GSD **stats** workflow — display comprehensive project statistics.
+
+## Process
+
+Read the canonical gsd-pi state and present a statistics summary. Use gsd-pi's own tooling to gather the data — do not hand-parse files when a command or query exists.
+
+Gather:
+- Active milestone id/title and overall milestone progress (completed/total).
+- Slice and task progress for the active milestone (completed/total per slice where available).
+- Requirements coverage if tracked.
+- Git metrics: total commits, first commit date, last activity date, current branch.
+- Project age in days.
+
+Present the summary in this shape:
+
+```
+# 📊 Project Statistics — {milestone} {title}
+
+## Progress
+[████████░░] X/Y milestones (Z%)
+
+## Slices (active milestone)
+| Slice | Tasks | Completed | Status |
+
+## Requirements
+✅ X/Y requirements complete
+
+## Git
+- Commits: N
+- Started: YYYY-MM-DD
+- Last activity: YYYY-MM-DD
+
+## Timeline
+- Project age: N days
+```
+
+If no `.gsd/` project exists, say so and suggest `/gsd init`.
+
+## Success criteria
+
+- Numbers come from canonical gsd-pi state, not estimates.
+- The summary is readable in a terminal (ASCII progress bar, tables).
+- Missing sections are omitted rather than printed with zeroes.

package/src/resources/extensions/gsd/prompts/surface.md

@@ -0,0 +1,25 @@
+You are running the GSD **surface** workflow — manage which skills/extensions are surfaced in the active session.
+
+## Action
+
+{{action}}
+
+## Process
+
+Parse the action:
+
+- **list / status** (default): Show every installed skill/extension with its current surfaced state (enabled/disabled) and source (bundled, project, global). Group by cluster where applicable.
+- **profile <name>**: Apply a named surfacing profile — enable a curated cluster of skills and disable the rest. Confirm the change set before applying.
+- **disable <cluster>**: Disable a cluster of skills so they stop loading into context. Record the change so it persists.
+- **enable <cluster>**: Re-enable a previously disabled cluster.
+- **reset**: Restore the default surfacing state.
+
+Use gsd-pi's own extension/skill management (`/gsd extensions`, `/gsd skill-health`) as the backing store for these changes — do not invent a separate state file.
+
+If the action names an unknown cluster or profile, list the valid options rather than failing silently.
+
+## Success criteria
+
+- The current surfaced state is reported accurately from the backing store.
+- Changes persist via gsd-pi's extension/skill management, not a parallel mechanism.
+- Unknown names produce a helpful list of valid options.

package/src/resources/extensions/gsd/prompts/thread.md

@@ -0,0 +1,24 @@
+You are running the GSD **thread** workflow — manage persistent context threads for cross-session work, backed by the memory store so threads survive across sessions.
+
+## Action
+
+{{action}}
+
+## Process
+
+A thread is a named, resumable context line: a topic, the open question, decisions so far, and the next step. Threads live in the gsd-pi memory store so they persist and are queryable.
+
+Parse the action:
+
+- **list [--open|--resolved]** (default): list threads filtered by state. Each entry: slug, status, last-updated, one-line topic.
+- **close <slug>**: mark a thread resolved (record the resolution as a knowledge lesson if durable).
+- **status <slug>**: show a thread's full context (topic, decisions, open question, next step).
+- **<name> / <description>** (bare text): create or update a thread with the given name/description, stamping the current state and next step.
+
+Use `/gsd memory` as the backing store for thread persistence. When closing a thread whose resolution is a reusable lesson, also record it via `/gsd knowledge lesson`.
+
+## Success criteria
+
+- Threads persist in the memory store, not in a throwaway file.
+- Listing honors the open/resolved filter.
+- Resolved threads with durable lessons feed the knowledge store.

package/src/resources/extensions/gsd/prompts/triage-captures.md

@@ -65,4 +65,4 @@ Classify each capture as one of:
 
 **Important:** Do NOT execute any resolutions. Only classify and update CAPTURES.md. Resolution execution happens separately (in auto-mode dispatch or manually by the user).
 
-When done, say: "Triage complete." Say this exactly once — if you already said it in a prior message, do not repeat it.
+When done, say: "Triage closeout submitted." Do not say triage is complete — GSD announces completion only after post-unit verification passes. Say this exactly once — if you already said it in a prior message, do not repeat it.

package/src/resources/extensions/gsd/prompts/ui-phase.md

@@ -0,0 +1,29 @@
+You are running the GSD **ui-phase** workflow — produce a UI design contract (UI-SPEC) for a frontend milestone/slice before implementation.
+
+## Target
+
+{{target}}
+
+## Process
+
+1. **Load intent.** Read the milestone/slice goal, requirements, and any existing brand/design references.
+
+2. **Inventory the surfaces.** List every screen/state/component the milestone touches: pages, key states (empty, loading, error, success), and shared components.
+
+3. **Define the design contract per surface:**
+   - Layout (structure, responsive behavior)
+   - Key interactions and their feedback states
+   - Content/copy essentials
+   - Accessibility requirements
+   - Entry/exit points to other surfaces
+
+4. **Align on constraints.** Brand, type scale, color tokens, spacing system, component library — use existing design tokens where they exist; flag gaps.
+
+5. **Write the UI-SPEC** to the milestone/slice artifact in `.gsd/`. Recommend `/gsd sketch` to prototype high-uncertainty surfaces, or `/gsd plan-phase` to plan implementation.
+
+## Success criteria
+
+- Every surface the milestone touches is inventoried.
+- Each surface's contract is concrete enough to implement against.
+- Existing design tokens are reused; gaps are flagged.
+- The recommended next step reflects design readiness.

package/src/resources/extensions/gsd/prompts/ui-review.md

@@ -0,0 +1,29 @@
+You are running the GSD **ui-review** workflow — retroactive visual audit of implemented frontend code against design intent.
+
+## Target
+
+{{target}}
+
+## Process
+
+Audit the implemented UI across these pillars, grounding each finding in actual code (component files, styles, markup) with file paths:
+
+1. **Layout & spacing** — alignment, grid/flex correctness, responsive behavior, spacing rhythm.
+2. **Color & contrast** — palette consistency, accessible contrast ratios, dark/light coherence.
+3. **Typography** — type scale, hierarchy, line-height, legibility.
+4. **Interaction & feedback** — hover/focus/active states, loading/empty/error states, motion.
+5. **Consistency** — shared components reused, design tokens applied, no one-off magic numbers.
+6. **Accessibility** — semantic markup, keyboard navigation, ARIA correctness, focus management.
+
+For each pillar, give a score (0–5) with bullet findings (location + issue + suggested fix).
+
+## Output
+
+Write `.gsd/reviews/{{reviewId}}-UI-REVIEW.md` with the per-pillar scores, findings, and a prioritized fix list (critical first). Print the overall score and the critical findings.
+
+## Success criteria
+
+- Every finding cites a component/file path.
+- Each pillar has an explicit score, not just prose.
+- Critical findings are surfaced first and are actionable.
+- The review lives under `.gsd/reviews/`.

package/src/resources/extensions/gsd/prompts/ultraplan-phase.md

@@ -0,0 +1,24 @@
+You are running the GSD **ultraplan-phase** workflow — offload heavy planning of a milestone/slice to an extended-reasoning plan pass, review the result, and import it back. This uses a local extended-reasoning pass (an external cloud service is not available in this runtime).
+
+## Target
+
+{{target}}
+
+## Process
+
+1. **Assemble the planning brief.** Gather the milestone/slice goal, CONTEXT, RESEARCH, decisions, requirements, and a codebase snapshot into a single self-contained brief.
+
+2. **Run the extended-reasoning plan pass.** Produce a thorough plan from the brief using high reasoning effort: full task decomposition, dependency graph, verification per task, risks. This is the "ultraplan" — more exhaustive than a standard plan pass.
+
+3. **Review in the open.** Present the plan for review (the human reviews it before it's imported). Flag anything uncertain, risky, or that diverges from the stated goal.
+
+4. **Import.** On approval, write the plan to the milestone/slice plan artifact in `.gsd/` and record durable decisions. Note that this replaces the cloud review-and-import with a local review.
+
+5. **Route.** Recommend `/gsd dispatch execute` or `/gsd plan-review-convergence` for a convergence pass.
+
+## Success criteria
+
+- The plan is more exhaustive than a standard pass (that's the point of the offload).
+- The human reviews before import (no silent overwrite of an existing plan).
+- The brief is self-contained so the reasoning isn't context-starved.
+- Durable decisions are persisted on import.

package/src/resources/extensions/gsd/prompts/validate-phase.md

@@ -0,0 +1,26 @@
+You are running the GSD **validate-phase** workflow — retroactively audit and fill validation coverage gaps for completed work, using Nyquist-style coverage sampling.
+
+## Target
+
+{{target}}
+
+## Process
+
+1. **Map the verification surface.** For the target's tasks, list what behaviors/outputs each claims to verify, and the test (or manual check) that verifies it.
+
+2. **Find coverage gaps.** Identify: behaviors with no test, error/edge paths untested, boundaries between slices untested, and claims verified only by happy-path tests. Apply a Nyquist lens — sample at the rate needed to catch the behavior changing, not just once.
+
+3. **Generate the missing tests.** For each gap that is safe to fill deterministically, write the test (matching the project's test framework and conventions). Run the test suite after adding tests. For gaps that need a human (UI, exploratory), record them as UAT items instead of auto-generating.
+
+4. **Update the validation record.** Write/append the slice's VALIDATION note (or `.gsd/` equivalent) with the coverage map before/after, the tests added, and the remaining human-UAT items.
+
+5. **Report.** Summarize: gaps found, tests added (passing), and remaining human-UAT items.
+
+Prefer delegating test generation to `/gsd add-tests` where it fits, rather than hand-writing every test.
+
+## Success criteria
+
+- Every claimed behavior is mapped to a test (or flagged as needing human UAT).
+- Generated tests pass and match the project's conventions.
+- The validation record reflects the new coverage honestly.
+- Human-only gaps are recorded as UAT items, not silently skipped.