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

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

@@ -0,0 +1,31 @@
+You are running the GSD **discuss-phase** workflow — gather context for upcoming work through adaptive questioning before planning.
+
+## Target
+
+{{target}}
+
+## Flags
+
+- `--auto` — {{autoFlag}} (when ON, infer answers from existing artifacts without asking)
+- `--text` — {{textFlag}} (when ON, use plain-text questions instead of interactive prompts)
+
+## Process
+
+1. **Load context.** Read the target milestone's ROADMAP entry, CONTEXT, RESEARCH, prior SUMMARYs, and the Decisions Register. This preloaded context is authoritative — do not re-read these files; reference them.
+
+2. **Take a codebase snapshot.** A bounded sample of current code reality (≤5 source files, ≤8KB each) to ground questions. Read a specific file only when a question's answer hinges on it.
+
+3. **Ask grounded questions, one at a time.** Questions must be grounded in the preloaded context + snapshot — never an open-ended survey of the codebase before the first round. Probe: scope boundaries, success criteria, risks, unknowns, integration points.
+
+4. **`--auto` mode:** infer answers from the artifacts rather than asking, and record the inferences as assumptions to be confirmed later.
+
+5. **Record outcomes.** When the discussion settles, capture: decisions (to the Decisions Register via `/gsd knowledge rule` where durable), refined scope (to the milestone CONTEXT), open questions (to RESEARCH or `/gsd dispatch research`), and assumptions. Mark the milestone/slice as "Discussion Complete, Planning Pending".
+
+6. **Route.** Recommend the next step: `/gsd dispatch plan` to plan the milestone/slice, or `/gsd dispatch research` if open questions dominate.
+
+## Success criteria
+
+- Questions are grounded and asked one at a time — no upfront survey.
+- The preloaded context is treated as authoritative (not re-read).
+- Outcomes land in the right gsd-pi artifacts.
+- The recommended next step matches where the milestone now sits.

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

@@ -0,0 +1,13 @@
+You are running the GSD **docs-update** workflow — generate, update, and verify project documentation against the live codebase.
+
+## Mode
+
+{{mode}}
+
+## Process
+
+{{process}}
+
+## Success criteria
+
+{{successCriteria}}

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

@@ -0,0 +1,33 @@
+You are running the GSD **execute-phase** workflow — execute all tasks in a milestone/slice with wave-based parallelization.
+
+## Target
+
+{{target}}
+
+## Flags
+
+- `--wave N` — {{waveFlag}} (max parallel tasks per wave)
+- `--gaps-only` — {{gapsOnlyFlag}} (only execute tasks whose verification is incomplete)
+- `--interactive` — {{interactiveFlag}} (confirm each wave)
+- `--tdd` — {{tddFlag}}
+
+## Process
+
+1. **Load the plan.** Read the milestone/slice plan and task list. Determine task dependencies and group independent tasks into waves.
+
+2. **Execute wave-by-wave.** Within a wave, independent tasks can run in parallel (bounded by `--wave`). Each task: implement → run its verification → record outcome. `--gaps-only` restricts to tasks with incomplete verification.
+
+3. **Per-task guarantees.** Each completed task gets an atomic commit and an updated SUMMARY. Failing verification blocks that task's completion (do not mark it done).
+
+4. **Between waves**, confirm if `--interactive`, then proceed to the next wave respecting dependencies.
+
+5. **Honor closeout boundaries.** Stop after the first task/slice/milestone closeout boundary and leave the final closeout surface visible — do not barrel through multiple closeouts.
+
+Prefer delegating single-task execution to gsd-pi's execute machinery (`/gsd next`, `/gsd dispatch execute`) where it fits.
+
+## Success criteria
+
+- Every task attempted is either completed (verified + committed) or left blocked with a clear reason.
+- Wave parallelism respects task dependencies.
+- Closeout boundaries are honored (stop, don't barrel).
+- Atomic commits per task; SUMMARY updated per task.

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

@@ -63,6 +63,10 @@ Keep about **{{verificationBudget}}** for verification and summary. If context i
 
 ## Completion Contract
 
+### Closeout messaging (auto-mode)
+
+You write task closeout artifacts; **GSD auto-mode** decides when the task is actually **done**. Never say "Task {{taskId}} complete" in this unit — not even after `gsd_task_complete` succeeds. GSD announces completion only after post-unit verification passes.
+
 - If the plan is fundamentally invalid, set `blocker_discovered: true` in the summary and explain.
 - For downstream-impacting ambiguity that cannot be resolved from code, plans, or decisions, include an `escalation` object with question, options, recommendation, rationale, and `continueWithDefault`.
 - Capture meaningful architecture/pattern/observability decisions with `gsd_capture_thought` (or MCP-scoped `mcp__...__gsd_capture_thought`) when workflow MCP tools are presented; capture non-obvious gotchas or conventions only when they save future investigation.
@@ -77,4 +81,4 @@ Keep about **{{verificationBudget}}** for verification and summary. If context i
 
 **You MUST call `gsd_task_complete` before finishing, including when the stale-path safety rule stops execution.**
 
-When done, say: "Task {{taskId}} complete." Say this exactly once — if you already said it in a prior message, do not repeat it.
+When done, say: "Task {{taskId}} 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/explore.md

@@ -0,0 +1,58 @@
+You are running the GSD **explore** workflow — Socratic ideation that helps the developer think an idea through before committing to plans or milestones.
+
+## Idea
+
+{{topic}}
+
+## Process
+
+### Step 1 — Open the conversation
+
+If a topic was provided, acknowledge it and begin exploring. If not, ask what's on their mind (a feature idea, an architectural question, a problem, or something they're unsure about).
+
+### Step 2 — Socratic conversation (2–5 exchanges)
+
+- Ask **one question at a time** — never a list.
+- Probe: constraints, tradeoffs, users, scope, dependencies, risks.
+- Listen for "or" / "versus" / "tradeoff" signals — competing priorities worth exploring.
+- Reflect back what you hear to confirm understanding before moving on.
+- Follow the developer's energy — go deeper where they're engaged. Natural, not formulaic.
+
+### Step 3 — Mid-conversation research offer (after 2–3 exchanges)
+
+If the conversation surfaces factual questions, technology comparisons, or unknowns that research could resolve, offer a quick research pass. If the developer accepts, dispatch the project's research tooling. Skip entirely if the topic doesn't warrant it — never force it.
+
+### Step 4 — Crystallize outputs (after 3–6 exchanges)
+
+When the conversation reaches natural conclusions (or the developer signals readiness), analyze what was discussed and propose **up to 4 outputs** from:
+
+| Type | Destination (gsd-pi) | When to suggest |
+|------|----------------------|-----------------|
+| Capture | `.gsd/CAPTURES.md` (append) | Observations, context, decisions worth remembering |
+| Backlog item | `/gsd backlog add` | Forward-looking ideas not ready for a milestone |
+| Knowledge | `/gsd knowledge lesson` | A lesson learned worth persisting |
+| Research | `/gsd dispatch research` | Open questions needing deeper investigation |
+| Requirement | `.gsd/CONTEXT.md` (append under "Domain glossary") | Clear requirements that emerged |
+| New milestone | `/gsd new-milestone` | Scope large enough to warrant its own milestone |
+| Spike | `/gsd spike` | Feasibility uncertainty surfaced ("will this API work?") |
+| Sketch | `/gsd brief diagram` | Design direction unclear ("what should this look like?") |
+
+Present the suggestions and ask the developer to pick, modify, or skip.
+
+**Never write artifacts without explicit user selection.**
+
+### Step 5 — Write selected outputs
+
+For each selected output, use the matching gsd-pi command or write to the destination listed above. Prefer invoking the gsd-pi command (e.g. `/gsd backlog add`, `/gsd knowledge lesson`) so state stays canonical.
+
+### Step 6 — Close
+
+Summarize the topic, list the artifacts created, and suggest next steps (`/gsd explore` again, or `/gsd status` to see where to apply the work).
+
+## Success criteria
+
+- Questions asked one at a time, not in batches.
+- Research offered contextually, not forced.
+- Up to 4 outputs proposed, grounded in the actual conversation.
+- User explicitly selects which outputs to create before anything is written.
+- Artifacts go to the gsd-pi destinations above.

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

@@ -0,0 +1,27 @@
+You are running the GSD **graphify** workflow — build, query, and inspect a lightweight project knowledge graph. The graph lives in `.gsd/knowledge/` and is grounded in CODEBASE.md and project memories.
+
+## Action
+
+{{action}}
+
+## Process
+
+The knowledge graph is a set of Markdown + a JSON edge index under `.gsd/knowledge/`:
+- `nodes.md` — entities discovered in the codebase (modules, services, data models, external integrations), each with a stable id, type, file path, and one-line description.
+- `edges.json` — relationships between nodes (`depends-on`, `calls`, `implements`, `produces`, `consumes`).
+
+Parse the action:
+
+- **build** (default when no action): Re-scan the codebase and CODEBASE.md, extract nodes and edges, and write/refresh `nodes.md` and `edges.json`. Preserve human-added annotations where possible. Stamp the build with the current HEAD commit.
+- **query <term>**: Look up nodes matching the term and print their direct relationships (one hop). Show the evidence (file path) for each edge.
+- **status**: Print graph stats — node count by type, edge count by relationship, last build commit. Say if the graph is stale (HEAD moved since last build).
+- **diff**: Compare the current codebase HEAD against the last build commit and report added/removed/changed nodes — a drift report.
+
+Ground extraction in real code. Do not invent nodes. When the codebase has no CODEBASE.md, suggest running `/gsd codebase generate` first.
+
+## Success criteria
+
+- Nodes and edges are backed by real file evidence.
+- The graph lives under `.gsd/knowledge/`.
+- Query/status/diff give accurate, evidence-backed answers.
+- Stale graphs are detected and reported.

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

@@ -0,0 +1,37 @@
+You are running the GSD **health** workflow — validate `.gsd/` directory integrity and report actionable issues, optionally repairing auto-fixable ones.
+
+## Flags
+
+- `--repair` — {{repairFlag}} (when ON, auto-fix detected issues)
+- `--context` — {{contextFlag}} (when ON, report context-window utilization instead of directory health)
+
+## Process
+
+### Directory integrity (default; skip if `--context`)
+
+Check the canonical `.gsd/` state for:
+
+- **Missing or malformed artifacts:** ROADMAP, milestone/slice markdown projections, CONTEXT, CAPTURES.
+- **DB/disk drift:** rows in the canonical DB that don't match the markdown projections (and vice-versa).
+- **Orphaned artifacts:** slices/tasks referenced nowhere, or projections whose DB rows are gone.
+- **Incomplete/inconsistent state:** an active milestone that's actually complete, a locked milestone with no lease, stale crash locks.
+- **Unmerged completed milestones:** milestones marked complete but never merged/published.
+
+For each issue, classify it: **auto-fixable** (drift repair, projection rebuild) or **needs-human** (data loss, ambiguous state). When `--repair` is ON, apply the auto-fixable fixes (preferring gsd-pi's repair tooling: `/gsd doctor fix`, `/gsd rebuild markdown`). Report exactly what changed.
+
+Prefer delegating the heavy lifting to gsd-pi's existing repair commands rather than hand-editing state.
+
+### Context utilization (only when `--context`)
+
+Report the session's approximate tokens used vs. the active model's context window, and what is consuming it (skills, injections, history). Suggest compaction or pruning if utilization is high.
+
+## Output
+
+Present issues grouped by severity (needs-human first, then auto-fixable). For `--repair`, also list each fix applied with a one-line before/after. If everything is healthy, say so plainly.
+
+## Success criteria
+
+- Every reported issue is concrete and actionable (file/row + what's wrong + how to fix).
+- Repairs use gsd-pi repair tooling where it exists.
+- No silent destructive changes — auto-fixable means reversible/projection-level only.
+- Context mode and directory mode are orthogonal and never mixed.

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

@@ -0,0 +1,30 @@
+You are running the GSD **import** workflow — ingest an external plan with conflict detection against existing project decisions before writing anything.
+
+## Flags
+
+- `--resolve auto|interactive` — {{resolveFlag}}
+
+## Source
+
+{{source}}
+
+## Process
+
+1. **Read the source plan.** From the given filepath (or `--from-gsd2` to migrate a legacy `.planning/` directory laid out as ordered phases). Parse its phases, requirements, decisions, and tasks.
+
+2. **Conflict detection (before writing).** Compare the source's decisions and requirements against the project's existing CONTEXT, Decisions Register, KNOWLEDGE rules, and current milestones. Flag: contradictory decisions, duplicate requirements, scope that overlaps an existing milestone, and terminology mismatches.
+
+3. **Present the conflict report.** List conflicts by severity (blocking / warning / info). Do not write anything yet.
+
+4. **Resolve.** For each conflict, propose a resolution (adopt source, keep ours, merge). In `--resolve auto`, apply the safe merges and flag the rest; in `--resolve interactive`, confirm each resolution with the user.
+
+5. **Import.** On approval, translate the source into gsd-pi artifacts: phases → milestones, requirements → CONTEXT/requirements, decisions → Decisions Register (`/gsd knowledge rule`), tasks → slice tasks. Prefer `/gsd migrate` machinery for whole `.planning/` imports.
+
+Nothing is written until conflicts are resolved.
+
+## Success criteria
+
+- Conflicts are detected and reported before any write.
+- No destructive overwrite of existing decisions without explicit resolution.
+- Phase-based source content is translated to gsd-pi's milestone/slice model.
+- Whole-`.planning/` imports route through `/gsd migrate`.

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

@@ -0,0 +1,27 @@
+You are running the GSD **inbox** workflow — triage and review open GitHub issues and PRs against the project's conventions, using the GitHub Issues tracker referenced in AGENTS.md.
+
+## Flags
+
+- `--issues` / `--prs` — {{focusFlag}} (which to review; default both)
+- `--label <name>` — {{labelFlag}}
+- `--close-incomplete` — {{closeIncompleteFlag}} (close items that don't meet contribution requirements)
+- `--repo <owner/repo>` — {{repo}}
+
+## Process
+
+1. **Fetch open items.** Use the `gh` CLI (or the project's GitHub integration) to list open issues and/or PRs, applying the label and repo filters.
+
+2. **Triage each item** against the project's contribution guide and templates:
+   - **Issues**: is it actionable? Does it have reproduction, labels, expected/actual? Route: promote to backlog (`/gsd backlog add`), request info, or close incomplete.
+   - **PRs**: does it meet the PR checklist (tests, docs, conventional commits, scope)? Route: request changes, request review, or merge-ready.
+
+3. **Present the triage** with the recommended action per item. When `--close-incomplete` is ON, also act on the clear-close items (with a comment explaining why).
+
+4. **Act on confirmation** for non-close actions: add to backlog, request changes, etc. Never merge or close-without-comment automatically.
+
+## Success criteria
+
+- Triage is grounded in the actual issue/PR content, not assumptions.
+- Each item gets a concrete recommended action.
+- Destructive actions (close, merge) require confirmation or an explicit flag.
+- Actionable issues feed the backlog so they aren't lost.

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

@@ -0,0 +1,30 @@
+You are running the GSD **ingest-docs** workflow — bootstrap or merge a `.gsd/` setup from existing ADRs, PRDs, SPECs, and docs in the repo.
+
+## Flags
+
+- `--mode new|merge` — {{modeFlag}} (new = fresh .gsd/; merge = fold into existing)
+- `--manifest <file>` — {{manifestFlag}} (a manifest listing which docs to ingest)
+- `--resolve auto|interactive` — {{resolveFlag}}
+
+## Source path
+
+{{path}}
+
+## Process
+
+1. **Discover source docs.** Scan the given path (default: repo root) for decision records (ADRs, MADR, Nygard), PRDs, SPECs, RFCs, and READMEs that carry project knowledge. Apply the manifest filter if given.
+
+2. **Classify each doc**: decision (→ Decisions Register), requirement/spec (→ CONTEXT/requirements), context/narrative (→ CONTEXT), architecture (→ CODEBASE or RESEARCH).
+
+3. **Conflict detection.** When `--mode merge`, detect where ingested decisions contradict the existing Decisions Register and flag them.
+
+4. **Resolve.** In `--resolve auto`, apply safe ingests and flag conflicts; otherwise confirm each.
+
+5. **Bootstrap/merge.** For `--mode new`, run `/gsd init` then write the ingested artifacts. For `--mode merge`, append into the existing `.gsd/` artifacts. Record ingested decisions durably via `/gsd knowledge rule`.
+
+## Success criteria
+
+- Source docs are discovered and classified, not blindly copied.
+- Merge conflicts are detected before writing.
+- Decisions land in the Decisions Register; requirements in CONTEXT — not dumped as raw files.
+- Bootstrap and merge both route through gsd-pi init/knowledge commands.

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

@@ -0,0 +1,21 @@
+You are running the GSD **manager** workflow — an interactive command center for managing multiple milestones from one terminal.
+
+## Flags
+
+- `--analyze-deps` — {{analyzeDepsFlag}} (when ON, also analyze cross-milestone dependencies)
+
+## Process
+
+1. **Load the milestone queue.** Read all milestones with their state (active, queued, parked, complete), progress (slices/tasks done/total), and last activity.
+
+2. **Present the dashboard.** Show milestones grouped by state with a compact progress indicator each. Highlight the active milestone and any blockers.
+
+{{managerActions}}
+
+4. **`--analyze-deps`:** scan for cross-milestone dependencies (shared files, shared APIs, sequencing) and surface them so the developer can order milestones to avoid integration conflicts.
+
+{{managerSelectionStep}}
+
+## Success criteria
+
+{{managerSuccessCriteria}}

package/dist/resources/extensions/gsd/prompts/map-codebase.md

@@ -0,0 +1,42 @@
+You are running the GSD **map-codebase** workflow — analyze the codebase and produce structured reference documents that planning and execution can rely on. Output goes to `.gsd/codebase/`.
+
+## Scope
+
+{{scope}}
+
+## Output directory
+
+`{{outputDir}}`
+
+## Philosophy
+
+- **Practical detail over arbitrary brevity.** Include enough to be useful as reference, with real code patterns.
+- **Always include file paths** formatted with backticks (e.g. `src/services/user.ts`). These documents are reference material for planning and execution.
+- Prefer reading the code directly over guessing.
+
+## Documents to produce
+
+Write a well-structured Markdown file in `{{outputDir}}/` for each relevant document:
+
+- **STACK.md** — languages, runtimes, versions; key frameworks/libraries; build tools; package manager.
+- **INTEGRATIONS.md** — third-party APIs/services; databases; auth providers; infra/deploy; comms services.
+- **ARCHITECTURE.md** — architecture style; core data flow; key design patterns; module/package boundaries.
+- **STRUCTURE.md** — directory layout with purpose of each top-level dir; entry points; where tests live.
+- **CONVENTIONS.md** — coding conventions, naming, error handling, logging patterns.
+- **TESTING.md** — test framework(s), how to run tests, test structure, coverage approach.
+- **CONCERNS.md** — technical debt, risk areas, TODO/FIXME clusters, fragile areas.
+
+Only produce documents relevant to this project (skip ones with nothing to say). Stamp each document's YAML frontmatter with `last_mapped_commit: <current HEAD sha>` so drift can be detected later.
+
+## Process
+
+1. Detect the project's stack and structure (read manifests, top-level dirs, entry points).
+2. Read representative source files to ground each document in real evidence.
+3. Write each document with concrete examples and file paths.
+4. Print a short summary of which documents were created/updated and their line counts.
+
+## Success criteria
+
+- Every produced document is grounded in real code with file paths.
+- Documents live under `.gsd/codebase/`.
+- Each document has a `last_mapped_commit` frontmatter stamp.

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

@@ -0,0 +1,27 @@
+You are running the GSD **milestone-summary** workflow — generate a comprehensive project summary from milestone artifacts for onboarding and review.
+
+## Target
+
+{{target}}
+
+## Process
+
+1. **Gather artifacts.** Read the target milestone's ROADMAP entry, CONTEXT, RESEARCH, per-slice SUMMARY/ASSESSMENT, the Decisions Register, and any UAT/validation outcomes. If no target, summarize the whole project across milestones.
+
+2. **Synthesize the summary** covering:
+   - What the milestone/project set out to do (intent + requirements).
+   - What was delivered (slices, key changes, by area).
+   - Key decisions made and why (from the Decisions Register).
+   - Verification outcomes (tests, UAT, audits).
+   - Known gaps, deferred work, and tech debt.
+   - Onboarding notes: how to run, where things live, gotchas.
+
+3. **Write the summary** to `.gsd/summaries/` and print it. For a milestone, name it after the milestone id; for a project, name it with the date.
+
+4. **Recommend next steps** based on the summary (next milestone, remediation, archive).
+
+## Success criteria
+
+- The summary is grounded in artifacts, not memory.
+- Decisions and gaps are included, not just the happy-path deliverables.
+- Onboarding notes are concrete (commands, paths) not vague.

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

@@ -0,0 +1,23 @@
+You are running the GSD **mvp-phase** workflow — plan a milestone as a vertical MVP slice: a single user story, split into the thinnest end-to-end path, then planned (SPIDR splitting).
+
+## Target
+
+{{target}}
+
+## Process
+
+1. **Capture the user story.** One concrete story: "A user can …" that exercises the full stack end-to-end.
+
+2. **Split into the thinnest vertical slice** that proves the story. Identify the happy path that touches every layer (UI → API → data → back) with the minimum viable behavior. Defer everything else to later milestones.
+
+3. **SPIDR-split if the slice is still too large** — split by Story, Process, Interface, Data, Rules — and pick the single sub-slice that delivers the story.
+
+4. **Define the demo.** The observable behavior that proves the MVP works (a concrete demo step).
+
+5. **Hand off to planning.** Record the MVP scope (story, slice, demo, deferred items) on the milestone and recommend `/gsd plan-phase` to plan the slice, or `/gsd new-milestone` if this should be its own milestone.
+
+## Success criteria
+
+- The slice is genuinely vertical (touches every layer) and genuinely minimal (nothing that isn't needed to prove the story).
+- The demo is concrete and observable.
+- Deferred work is listed, not lost.

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

@@ -0,0 +1,24 @@
+You are running the GSD **pause-work** workflow — create a context handoff when pausing work mid-stream, so the next session can resume cleanly.
+
+## Flags
+
+- `--report` — {{reportFlag}} (also produce a human-readable pause report)
+
+## Process
+
+1. **Snapshot current state.** Capture the active milestone/slice/task, what was just done, what is in-flight (partially edited files, uncommitted work), and the intended next step. Pull this from canonical gsd-pi state, not memory.
+
+2. **Capture open threads.** Unresolved questions, decisions pending, blockers, and TODOs that the next session must pick up.
+
+3. **Write the handoff.** Persist a `HANDOFF.md` (or append to the slice's running notes) in `.gsd/` with: state snapshot, in-flight work, open threads, and the explicit resume instruction ("next: resume <slice/task>, do <X>").
+
+4. **Pause cleanly.** Commit any safe-to-commit work; leave a clear note on anything intentionally left dirty. Trigger the gsd-pi pause (`/gsd pause`) so auto-mode stops.
+
+5. **`--report`:** also print a concise pause report to the terminal.
+
+## Success criteria
+
+- The handoff is grounded in canonical state, not memory.
+- The resume instruction is explicit and actionable.
+- Auto-mode is actually paused, not just documented.
+- In-flight/dirty state is called out honestly.

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