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

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/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/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.

package/dist/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/dist/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/dist/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/dist/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/dist/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/dist/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/dist/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/dist/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.

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

@@ -0,0 +1,24 @@
+You are running the GSD **verify-work** workflow — validate built features through conversational UAT.
+
+## Target
+
+{{target}}
+
+## Process
+
+1. **Load what was built.** Read the target slice/milestone plan and SUMMARY to understand what features were delivered and what their acceptance criteria are.
+
+2. **Draft a UAT script.** Turn each acceptance criterion into a concrete, observable test step the human can perform (or that you can perform via tooling where possible). Group by feature; order so earlier steps set up later ones.
+
+3. **Walk through the script conversationally.** Present one step (or a small group) at a time. For each, record the outcome: `pass`, `fail` (with what happened), `blocked` (with the blocker), or `skipped` (intentionally). Do not advance past a fail without acknowledging it.
+
+4. **Where you can self-verify** (deterministic checks: type checks, tests, lint, schema), run them and include the result alongside the human step.
+
+5. **Produce the verdict.** After all steps: `pass` (all criteria met), `needs-attention` (some steps failed but none blocking), or `needs-remediation` (a blocking failure). Record the UAT outcome against the slice via the appropriate gsd-pi mechanism.
+
+## Success criteria
+
+- Every acceptance criterion becomes a concrete, observable step.
+- Outcomes are recorded honestly — fails are not hidden.
+- Deterministic checks are run where possible, not just asked about.
+- The final verdict maps to a canonical gsd-pi outcome.

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

@@ -0,0 +1,22 @@
+You are running the GSD **workspace** workflow — manage isolated workspace environments for parallel or experimental work.
+
+## Action
+
+{{action}}
+
+## Process
+
+A workspace is an isolated environment backed by a git worktree. Map workspace actions onto worktrees:
+
+- **--list / list** (default): show all worktrees with state (current, merged, clean, dirty) — `/gsd worktree list`.
+- **--remove <name>**: remove a worktree — `/gsd worktree remove`.
+- **--merge <name>**: merge a worktree — `/gsd worktree merge`.
+- **--clean / clean**: clean stale worktree records — `/gsd worktree clean`.
+
+Route every structural action to `/gsd worktree` rather than hand-managing git worktrees.
+
+## Success criteria
+
+- Listing reflects canonical worktree state.
+- Structural actions route to `/gsd worktree`, keeping state canonical.
+- Removing a dirty worktree is guarded (confirm first).

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

@@ -0,0 +1,24 @@
+You are running the GSD **workstreams** workflow — manage parallel workstreams that run multiple milestones concurrently with isolation.
+
+## Action
+
+{{action}}
+
+## Process
+
+A workstream is a parallel worker running its own milestone in its own branch/worktree. Map workstream actions onto parallel workers:
+
+- **list / status** (default): show all parallel workers — milestone, branch/worktree, progress, state (running/paused/done/failed).
+- **create / start**: start parallel workers for all eligible milestones (`/gsd parallel start`). Does not accept a milestone target; use `/gsd parallel start` directly to start all eligible milestones.
+- **switch**: focus the dashboard on the most active worker (`/gsd parallel watch`). Does not accept a milestone target; use `/gsd parallel watch` directly to monitor workers.
+- **progress**: show all workers' progress (`/gsd parallel status`). Does not accept a milestone target; use `/gsd parallel status` directly for worker status.
+- **pause / resume <milestone>**: pause or resume a worker (`/gsd parallel pause|resume`).
+- **complete <milestone>**: complete and merge a worker's milestone (`/gsd parallel merge`).
+
+Route every structural action to `/gsd parallel <subcommand>` rather than reimplementing worktree/merge logic.
+
+## Success criteria
+
+- Status reflects canonical parallel-worker state.
+- Structural actions route to `/gsd parallel`, not duplicates.
+- Unknown milestones list the valid options rather than failing silently.

package/dist/resources/extensions/gsd/provider-error-guidance.js

@@ -44,11 +44,35 @@ function defaultAlternateModel(provider, modelId) {
     }
     return undefined;
 }
+function isGeminiCliDeprecatedError(errorMsg) {
+    return (/IneligibleTierError/i.test(errorMsg)
+        || /UNSUPPORTED_CLIENT/i.test(errorMsg)
+        || /no longer supported for Gemini Code Assist for individuals/i.test(errorMsg)
+        || /migrate to the Antigravity suite/i.test(errorMsg));
+}
+function resolveGeminiCliDeprecationGuidance(input) {
+    const { provider, modelId, unitType } = input;
+    const modelLabel = provider && modelId ? `${provider}/${modelId}` : modelId ?? provider ?? "google-gemini-cli";
+    const unitSuffix = unitType ? ` during ${unitType}` : "";
+    return {
+        summary: `Provider error on ${modelLabel}${unitSuffix}. ` +
+            "Google no longer supports Gemini CLI for individual-tier users — migrate to Antigravity CLI.",
+        steps: [
+            "Install Antigravity CLI: curl -fsSL https://antigravity.google/cli/install.sh | bash",
+            "Run `agy` in a terminal and complete authentication.",
+            "In GSD, run `/login` and select Antigravity, or restart GSD to auto-migrate when `agy` is on PATH.",
+            "Run /gsd next to resume the paused unit.",
+        ],
+    };
+}
 /**
  * Build concrete next steps for a provider/model rejection pause.
  */
 export function resolveProviderErrorGuidance(input) {
     const { errorMsg, provider, modelId, unitType, preferencesPath, hasConfiguredFallbacks, } = input;
+    if (isGeminiCliDeprecatedError(errorMsg)) {
+        return resolveGeminiCliDeprecationGuidance(input);
+    }
     const modelLabel = provider && modelId ? `${provider}/${modelId}` : modelId ?? provider ?? "current model";
     const phaseKey = unitTypeToPrefsPhaseKey(unitType);
     const prefsFile = preferencesPath ?? ".gsd/PREFERENCES.md";

package/dist/resources/extensions/gsd/queue-order.js

@@ -31,8 +31,9 @@ export function loadQueueOrder(basePath) {
     return data?.order ?? null;
 }
 /**
- * Save a custom queue order. The DB sequence is canonical when a DB
- * connection is open; QUEUE-ORDER.json remains a compatibility projection.
+ * Save a custom queue order. When the DB connection is open, mirror the order
+ * into milestone sequence; QUEUE-ORDER.json remains the durable file contract
+ * for prompt-driven flows such as /gsd rethink.
  */
 export function saveQueueOrder(basePath, order) {
     if (isDbAvailable()) {