gsd-pi 2.10.12 → 2.12.0

package/dist/resources/extensions/gsd/prompts/guided-resume-task.md

@@ -0,0 +1 @@
+Resume interrupted work. Find the continue file (`{{sliceId}}-CONTINUE.md` or `continue.md`) in slice {{sliceId}} of milestone {{milestoneId}}, then pick up from where you left off. Delete the continue file after reading it. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during execution, without relaxing required verification or artifact rules.

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

@@ -0,0 +1,78 @@
+You are executing GSD auto-mode.
+
+## UNIT: Plan Milestone {{milestoneId}} ("{{milestoneTitle}}")
+
+All relevant context has been preloaded below — start working immediately without re-reading these files.
+
+{{inlinedContext}}
+
+Narrate your decomposition reasoning — why you're grouping work this way, what risks are driving the order, what verification strategy you're choosing and why.
+
+Then:
+1. Use the **Roadmap** output template from the inlined context above
+2. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during planning, without overriding required roadmap formatting
+3. Create the roadmap: decompose into demoable vertical slices — as many as the work genuinely needs, no more. A simple feature might be 1 slice. Don't decompose for decomposition's sake.
+4. Order by risk (high-risk first)
+5. Write `{{outputPath}}` with checkboxes, risk, depends, demo sentences, proof strategy, verification classes, milestone definition of done, **requirement coverage**, and a boundary map. Write success criteria as observable truths, not implementation tasks. If the milestone crosses multiple runtime boundaries, include an explicit final integration slice that proves the assembled system works end-to-end in a real environment
+6. If planning produced structural decisions (e.g. slice ordering rationale, technology choices, scope exclusions), append them to `.gsd/DECISIONS.md` (use the **Decisions** output template from the inlined context above if the file doesn't exist yet)
+7. Update `.gsd/STATE.md`
+
+## Requirement Mapping Rules
+
+- Every Active requirement relevant to this milestone must be in one of these states by the end of planning: mapped to a slice, explicitly deferred, blocked with reason, or moved out of scope.
+- Each requirement should have one accountable primary owner and may have supporting slices.
+- Product-facing milestones should cover launchability, primary user loop, continuity, and failure visibility when relevant.
+- A slice may support multiple requirements, but should not exist with no requirement justification unless it is clearly enabling work for a mapped requirement.
+- Include a compact coverage summary in the roadmap so omissions are mechanically visible.
+- If `.gsd/REQUIREMENTS.md` exists and an Active requirement has no credible path, surface that clearly. Do not silently ignore orphaned Active requirements.
+
+## Planning Doctrine
+
+Apply these when decomposing and ordering slices:
+
+- **Risk-first means proof-first.** The earliest slices should prove the hardest thing works by shipping the real feature through the uncertain path. If auth is the risk, the first slice ships a real login page with real session handling that a user can actually use — not a CLI command that returns "authenticated: true". Proof is the shipped feature working. There is no separate "proof" artifact. Do not plan spikes, proof-of-concept slices, or validation-only slices — the proof is the real feature, built through the risky path.
+- **Every slice is vertical, demoable, and shippable.** Every slice ships real, user-facing functionality. "Demoable" means you could show a stakeholder and they'd see real product progress — not a developer showing a terminal command. If the only way to demonstrate the slice is through a test runner or a curl command, the slice is missing its UI/UX surface. Add it. A slice that only proves something but doesn't ship real working code is not a slice — restructure it.
+- **Brownfield bias.** When planning against an existing codebase, ground slices in existing modules, conventions, and seams. Prefer extending real patterns over inventing new ones.
+- **Each slice should establish something downstream slices can depend on.** Think about what stable surface this slice creates for later work — an API, a data shape, a proven integration path.
+- **Avoid foundation-only slices.** If a slice doesn't produce something demoable end-to-end, it's probably a layer, not a vertical slice. Restructure it.
+- **Verification-first.** When planning slices, know what "done" looks like before detailing implementation. Each slice's demo line should describe concrete, verifiable evidence — not vague "it works" claims.
+- **Plan for integrated reality, not just local proof.** Distinguish contract proof from live integration proof. If the milestone involves multiple runtime boundaries, one slice must explicitly prove the assembled system through the real entrypoint or runtime path.
+- **Truthful demo lines only.** If a slice is proven by fixtures or tests only, say so. Do not phrase harness-level proof as if the user can already perform the live end-to-end behavior unless that has actually been exercised.
+- **Completion must imply capability.** If every slice in this roadmap were completed exactly as written, the milestone's promised outcome should actually work at the proof level claimed. Do not write slices that can all be checked off while the user-visible capability still does not exist.
+- **Don't invent risks.** If the project is straightforward, skip the proof strategy and just ship value in smart order. Not everything has major unknowns.
+- **Ship features, not proofs.** A completed slice should leave the product in a state where the new capability is actually usable through its real interface. A login flow slice ends with a working login page, not a middleware function. An API slice ends with endpoints that return real data from a real store, not hardcoded fixtures. A dashboard slice ends with a real dashboard rendering real data, not a component that renders mock props. If a slice can't ship the real thing yet because a dependency isn't built, it should ship with realistic stubs that are clearly marked for replacement — but the user-facing surface must be real.
+- **Ambition matches the milestone.** The number and depth of slices should match the milestone's ambition. A milestone promising "core platform with auth, data model, and primary user loop" should have enough slices to actually deliver all three as working features — not two proof-of-concept slices and a note that "the rest will come in the next milestone." If the milestone's context promises an outcome, the roadmap must deliver it.
+- **Right-size the decomposition.** Match slice count to actual complexity. If the work is small enough to build and verify in one pass, it's one slice — don't split it into three just because you can identify sub-steps. Multiple requirements can share a single slice. Conversely, don't cram genuinely independent capabilities into one slice just to keep the count low. Let the work dictate the structure.
+
+## Single-Slice Fast Path
+
+If the roadmap has only one slice, also write the slice plan and task plans inline during this unit — don't leave them for a separate planning session.
+
+1. Use the **Slice Plan** and **Task Plan** output templates from the inlined context above
+2. `mkdir -p {{milestonePath}}/slices/S01/tasks`
+3. Write the S01 plan file at `{{milestonePath}}/slices/S01/S01-PLAN.md`
+4. Write individual task plans at `{{milestonePath}}/slices/S01/tasks/T01-PLAN.md`, etc.
+5. For simple slices, keep the plan lean — omit Proof Level, Integration Closure, and Observability sections if they would all be "none". Executable verification commands are sufficient.
+
+This eliminates a separate research-slice + plan-slice cycle when the work is straightforward.
+
+## Secret Forecasting
+
+After writing the roadmap, analyze the slices and their boundary maps for external service dependencies (third-party APIs, SaaS platforms, cloud providers, databases requiring credentials, OAuth providers, etc.).
+
+If this milestone requires any external API keys or secrets:
+
+1. Use the **Secrets Manifest** output template from the inlined context above for the expected format
+2. Write `{{secretsOutputPath}}` listing every predicted secret as an H3 section with:
+   - **Service** — the external service name
+   - **Dashboard** — direct URL to the console/dashboard page where the key is created (not a generic homepage)
+   - **Format hint** — what the key looks like (e.g. `sk-...`, `ghp_...`, 40-char hex, UUID)
+   - **Status** — always `pending` during planning
+   - **Destination** — `dotenv`, `vercel`, or `convex` depending on where the key will be consumed
+   - Numbered step-by-step guidance for obtaining the key (navigate to dashboard → create project → generate key → copy)
+
+If this milestone does not require any external API keys or secrets, skip this step entirely — do not create an empty manifest.
+
+**You MUST write the file `{{outputPath}}` before finishing.**
+
+When done, say: "Milestone {{milestoneId}} planned."

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

@@ -0,0 +1,55 @@
+You are executing GSD auto-mode.
+
+## UNIT: Plan Slice {{sliceId}} ("{{sliceTitle}}") — Milestone {{milestoneId}}
+
+All relevant context has been preloaded below — start working immediately without re-reading these files.
+
+{{inlinedContext}}
+
+### Dependency Slice Summaries
+
+Pay particular attention to **Forward Intelligence** sections — they contain hard-won knowledge about what's fragile, what assumptions changed, and what this slice should watch out for.
+
+{{dependencySummaries}}
+
+Narrate your decomposition reasoning — why you're grouping work this way, what risks are driving the order, what verification strategy you're choosing and why. Keep the narration proportional to the work — a simple slice doesn't need a long justification.
+
+**Right-size the plan.** If the slice is simple enough to be 1 task, plan 1 task. Don't split into multiple tasks just because you can identify sub-steps. Don't fill in sections with "None" when the section doesn't apply — omit them entirely. The plan's job is to guide execution, not to fill a template.
+
+Then:
+0. If `REQUIREMENTS.md` was preloaded above, identify which Active requirements the roadmap says this slice owns or supports. These are the requirements this plan must deliver — every owned requirement needs at least one task that directly advances it, and verification must prove the requirement is met.
+1. Use the **Slice Plan** and **Task Plan** output templates from the inlined context above
+2. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during planning, without overriding required plan formatting
+3. Define slice-level verification — the objective stopping condition for this slice:
+   - For non-trivial slices: plan actual test files with real assertions. Name the files.
+   - For simple slices: executable commands or script assertions are fine.
+   - If the project is non-trivial and has no test framework, the first task should set one up.
+   - If this slice establishes a boundary contract, verification must exercise that contract.
+4. **For non-trivial slices only** — plan observability, proof level, and integration closure:
+   - Include `Observability / Diagnostics` for backend, integration, async, stateful, or UI slices where failure diagnosis matters.
+   - Fill `Proof Level` and `Integration Closure` when the slice crosses runtime boundaries or has meaningful integration concerns.
+   - **Omit these sections entirely for simple slices** where they would all be "none" or trivially obvious.
+5. Decompose the slice into tasks, each fitting one context window. Each task needs:
+   - a concrete, action-oriented title
+   - the inline task entry fields defined in the plan.md template (Why / Files / Do / Verify / Done when)
+   - a matching task plan file with description, steps, must-haves, verification, inputs, and expected output
+   - Observability Impact section **only if the task touches runtime boundaries, async flows, or error paths** — omit it otherwise
+6. Write `{{outputPath}}`
+7. Write individual task plans in `{{slicePath}}/tasks/`: `T01-PLAN.md`, `T02-PLAN.md`, etc.
+8. **Self-audit the plan.** Walk through each check — if any fail, fix the plan files before moving on:
+    - **Completion semantics:** If every task were completed exactly as written, the slice goal/demo should actually be true.
+    - **Requirement coverage:** Every must-have in the slice maps to at least one task. No must-have is orphaned. If `REQUIREMENTS.md` exists, every Active requirement this slice owns maps to at least one task.
+    - **Task completeness:** Every task has steps, must-haves, verification, inputs, and expected output — none are blank or vague.
+    - **Dependency correctness:** Task ordering is consistent. No task references work from a later task.
+    - **Key links planned:** For every pair of artifacts that must connect, there is an explicit step that wires them.
+    - **Scope sanity:** Target 2–5 steps and 3–8 files per task. 10+ steps or 12+ files — must split. Each task must be completable in a single fresh context window.
+    - **Feature completeness:** Every task produces real, user-facing progress — not just internal scaffolding.
+9. If planning produced structural decisions, append them to `.gsd/DECISIONS.md`
+10. Commit: `docs({{sliceId}}): add slice plan`
+11. Update `.gsd/STATE.md`
+
+The slice directory and tasks/ subdirectory already exist. Do NOT mkdir. You are on the slice branch; all work stays here.
+
+**You MUST write the file `{{outputPath}}` before finishing.**
+
+When done, say: "Slice {{sliceId}} planned."

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

@@ -0,0 +1,100 @@
+{{preamble}}
+
+## Draft Awareness
+
+Drafts are milestones that were identified during a prior multi-milestone discussion where the user chose "Needs own discussion" instead of "Ready for auto-planning." A `CONTEXT-DRAFT.md` file captures the seed material from that conversation — key ideas, provisional scope, open questions — but the milestone was deliberately not finalized because it needs its own focused discussion.
+
+Before asking "What do you want to add?", check the existing milestones context below. If any milestone is marked **"Draft context available"**, surface these drafts to the user first:
+
+1. Tell the user which milestones have draft contexts and briefly summarize what each draft contains (read the draft file).
+2. Use `ask_user_questions` to ask per-draft milestone:
+   - **"Discuss now"** — Treat this draft as the primary topic. Read the draft content, use it as seed material, and conduct a focused discussion following the standard discussion flow (reflection → investigation → questioning → depth verification → requirements → roadmap). After the discussion, write the full CONTEXT.md and delete the `CONTEXT-DRAFT.md` file. The milestone is then ready for auto-planning.
+   - **"Leave for later"** — Keep the draft as-is. The user will discuss it in a future session. Auto-mode will continue to pause when it reaches this milestone.
+3. Handle all draft discussions before proceeding to new queue work.
+4. If no drafts exist in the context, skip this section entirely and proceed to "What do you want to add?"
+
+Say exactly: "What do you want to add?" — nothing else. Wait for the user's answer.
+
+## Discussion Phase
+
+After they describe it, your job is to understand the new work deeply enough to create context files that a future planning session can use.
+
+**If the user provides a file path or pastes a large document** (spec, design doc, product plan, chat export), read it fully before asking questions. Use it as the starting point — don't ask them to re-explain what's already in the document. Your questions should fill gaps and resolve ambiguities the document doesn't cover.
+
+**Investigate between question rounds to make your questions smarter.** Before each round of questions, do enough lightweight research that your questions are grounded in reality — not guesses about what exists or what's possible.
+
+- Check library docs (`resolve_library` / `get_library_docs`) when the user mentions tech you need current facts about — capabilities, constraints, API shapes, version-specific behavior
+- Do web searches (`search-the-web`) to verify the landscape — what solutions exist, what's changed recently, what's the current best practice. Use `freshness` for recency-sensitive queries, `domain` to target specific sites. Use `fetch_page` to read the full content of promising URLs when snippets aren't enough.
+- Scout the codebase (`ls`, `find`, `rg`, or `scout` for broad unfamiliar areas) to understand what already exists, what patterns are established, what constraints current code imposes
+
+Don't go deep — just enough that your next question reflects what's actually true rather than what you assume.
+
+**Use this to actively surface:**
+- The biggest technical unknowns — what could fail, what hasn't been proven, what might invalidate the plan
+- Integration surfaces — external systems, APIs, libraries, or internal modules this work touches
+- What needs to be proven before committing — the things that, if they don't work, mean the plan is wrong
+- How the new work relates to existing milestones — overlap, dependencies, prerequisites
+- If `.gsd/REQUIREMENTS.md` exists: which unmet Active or Deferred requirements this queued work advances
+
+**Then use ask_user_questions** to dig into gray areas — architecture choices, scope boundaries, tech preferences, what's in vs out. 1-3 questions per round.
+
+If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during discuss/planning work, but do not let it override the required discuss flow or artifact requirements.
+
+**Self-regulate:** After about 10-15 questions total (3-5 rounds), or when you feel you have a solid understanding, include a question like:
+"I think I have a good picture. Ready to queue this, or are there more things to discuss?"
+with options: "Ready to queue (Recommended)", "I have more to discuss"
+
+If the user wants to keep going, keep asking. If they're ready, proceed.
+
+## Existing Milestone Awareness
+
+{{existingMilestonesContext}}
+
+Before writing anything, assess the new work against what already exists:
+
+1. **Dedup check** — Is this already covered (fully or partially) by an existing milestone? If so, tell the user and explain what's already planned. Don't create duplicate milestones.
+2. **Extension check** — Should this be added to an existing *pending* (not yet started) milestone rather than creating a new one? If the scope naturally belongs with existing pending work, propose extending that milestone's context instead.
+3. **Dependency check** — Does the new work depend on something that's currently in progress or planned? Note the dependency so context files capture it.
+4. **Requirement check** — If `.gsd/REQUIREMENTS.md` exists, identify whether this queued work advances unmet Active requirements, promotes Deferred work, or introduces entirely new scope that should also update the requirement contract.
+
+If the new work is already fully covered, say so and stop — don't create anything.
+
+## Scope Assessment
+
+Before writing artifacts, assess whether this is **single-milestone** or **multi-milestone** scope.
+
+**Single milestone** if the work is one coherent body of deliverables that fits in roughly 2-12 slices.
+
+**Multi-milestone** if:
+- The work has natural phase boundaries
+- Different parts could ship independently on different timelines
+- The full scope is too large for one milestone to stay focused
+- The document/spec describes what is clearly multiple major efforts
+
+If multi-milestone: propose the split to the user before writing artifacts.
+
+## Sequencing
+
+Determine where the new milestones should go in the overall sequence. Consider dependencies, prerequisites, and independence.
+
+## Output Phase
+
+Once the user is satisfied, in a single pass for **each** new milestone (starting from {{nextId}}):
+
+1. `mkdir -p .gsd/milestones/<ID>/slices`
+2. Write `.gsd/milestones/<ID>/<ID>-CONTEXT.md` — use the **Context** output template below. Capture intent, scope, risks, constraints, integration points, and relevant requirements. Mark the status as "Queued — pending auto-mode execution."
+
+Then, after all milestone directories and context files are written:
+
+3. Update `.gsd/PROJECT.md` — add the new milestones to the Milestone Sequence. Keep existing entries exactly as they are. Only add new lines.
+4. If `.gsd/REQUIREMENTS.md` exists and the queued work introduces new in-scope capabilities or promotes Deferred items, update it.
+5. If discussion produced decisions relevant to existing work, append to `.gsd/DECISIONS.md`.
+6. Append to `.gsd/QUEUE.md`.
+7. Commit: `docs: queue <milestone list>`
+
+**Do NOT write roadmaps for queued milestones.**
+**Do NOT update `.gsd/STATE.md`.**
+
+After writing the files and committing, say exactly: "Queued N milestone(s). Auto-mode will pick them up after current work completes." — nothing else.
+
+{{inlinedTemplates}}

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

@@ -0,0 +1,48 @@
+You are executing GSD auto-mode.
+
+## UNIT: Reassess Roadmap — Milestone {{milestoneId}} after {{completedSliceId}}
+
+All relevant context has been preloaded below — the current roadmap, completed slice summary, project state, and decisions are inlined. Start working immediately without re-reading these files.
+
+{{inlinedContext}}
+
+If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during reassessment, without relaxing required verification or artifact rules.
+
+Then assess whether the remaining roadmap still makes sense given what was just built.
+
+**Bias strongly toward "roadmap is fine."** Most of the time, the plan is still good. Only rewrite if you have concrete evidence that remaining slices need to change. Don't rewrite for cosmetic reasons, minor optimization, or theoretical improvements.
+
+Ask yourself:
+- Did this slice retire the risk it was supposed to? If not, does a remaining slice need to address it?
+- Did new risks or unknowns emerge that should change slice ordering?
+- Are the boundary contracts in the boundary map still accurate given what was actually built?
+- Should any remaining slices be reordered, merged, split, or adjusted based on concrete evidence?
+- Did assumptions in remaining slice descriptions turn out wrong?
+- If `.gsd/REQUIREMENTS.md` exists: did this slice validate, invalidate, defer, block, or newly surface requirements?
+- If `.gsd/REQUIREMENTS.md` exists: does the remaining roadmap still provide credible coverage for Active requirements, including launchability, primary user loop, continuity, and failure visibility where relevant?
+
+### Success-Criterion Coverage Check
+
+Before deciding whether changes are needed, enumerate each success criterion from the roadmap's `## Success Criteria` section and map it to the remaining (unchecked) slice(s) that prove it. Each criterion must have at least one remaining owning slice. If any criterion has no remaining owner after the proposed changes, flag it as a **blocking issue** — do not accept changes that leave a criterion unproved.
+
+Format each criterion as a single line:
+
+- `Criterion text → S02, S03` (covered by at least one remaining slice)
+- `Criterion text → ⚠ no remaining owner — BLOCKING` (no slice proves this criterion)
+
+If all criteria have at least one remaining owning slice, the coverage check passes. If any criterion has no remaining owner, resolve it before finalizing the assessment — either by keeping a slice that was going to be removed, adding coverage to another slice, or explaining why the criterion is no longer relevant.
+
+**If the roadmap is still good:**
+
+Write `{{assessmentPath}}` with a brief confirmation that roadmap coverage still holds after {{completedSliceId}}. If requirements exist, explicitly note whether requirement coverage remains sound.
+
+**If changes are needed:**
+
+1. Rewrite the remaining (unchecked) slices in `{{roadmapPath}}`. Keep completed slices exactly as they are (`[x]`). Update the boundary map for changed slices. Update the proof strategy if risks changed. Update requirement coverage if ownership or scope changed.
+2. Write `{{assessmentPath}}` explaining what changed and why — keep it brief and concrete.
+3. If `.gsd/REQUIREMENTS.md` exists and requirement ownership or status changed, update it.
+4. Commit: `docs({{milestoneId}}): reassess roadmap after {{completedSliceId}}`
+
+**You MUST write the file `{{assessmentPath}}` before finishing.**
+
+When done, say: "Roadmap reassessed."

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

@@ -0,0 +1,39 @@
+You are executing GSD auto-mode.
+
+## UNIT: Replan Slice {{sliceId}} ("{{sliceTitle}}") — Milestone {{milestoneId}}
+
+A completed task reported `blocker_discovered: true`, meaning the current slice plan cannot be executed as-is. Your job is to rewrite the remaining tasks in the slice plan to address the blocker while preserving all completed work.
+
+All relevant context has been preloaded below — the roadmap, current slice plan, the blocker task summary, and decisions are inlined. Start working immediately without re-reading these files.
+
+{{inlinedContext}}
+
+## Hard Constraints
+
+- **Do NOT renumber or remove completed tasks.** All `[x]` tasks and their IDs must remain exactly as they are in the plan.
+- **Do NOT change completed task descriptions, estimates, or metadata.** They are historical records.
+- **Preserve completed task summaries.** Do not modify any `T0x-SUMMARY.md` files for completed tasks.
+- Only modify `[ ]` (incomplete) tasks. You may rewrite, reorder, add, or remove incomplete tasks as needed to address the blocker.
+- New tasks must follow the existing ID numbering sequence (e.g., if T01–T03 exist, new tasks start at T04 or continue from the highest existing ID).
+
+## Instructions
+
+1. Read the blocker task summary carefully. Understand exactly what was discovered and why it blocks the current plan.
+2. Analyze the remaining `[ ]` tasks in the slice plan. Determine which are still valid, which need modification, and which should be replaced.
+3. Write `{{replanPath}}` documenting:
+   - What blocker was discovered and in which task
+   - What changed in the plan and why
+   - Which incomplete tasks were modified, added, or removed
+   - Any new risks or considerations introduced by the replan
+4. Rewrite `{{planPath}}` with the updated slice plan:
+   - Keep all `[x]` tasks exactly as they were (same IDs, same descriptions, same checkmarks)
+   - Update the `[ ]` tasks to address the blocker
+   - Ensure the slice Goal and Demo sections are still achievable with the new tasks, or update them if the blocker fundamentally changes what the slice can deliver
+   - Update the Files Likely Touched section if the replan changes which files are affected
+5. If any incomplete task had a `T0x-PLAN.md`, remove or rewrite it to match the new task description.
+6. Do not commit manually — the system auto-commits your changes after this unit completes.
+7. Update `.gsd/STATE.md`
+
+**You MUST write `{{replanPath}}` and the updated slice plan before finishing.**
+
+When done, say: "Slice {{sliceId}} replanned."

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

@@ -0,0 +1,37 @@
+You are executing GSD auto-mode.
+
+## UNIT: Research Milestone {{milestoneId}} ("{{milestoneTitle}}")
+
+All relevant context has been preloaded below — start working immediately without re-reading these files.
+
+{{inlinedContext}}
+
+Then research the codebase and relevant technologies. Narrate key findings and surprises as you go — what exists, what's missing, what constrains the approach.
+1. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during research, without relaxing required verification or artifact rules
+2. **Skill Discovery ({{skillDiscoveryMode}}):**{{skillDiscoveryInstructions}}
+3. Explore relevant code. For small/familiar codebases, use `rg`, `find`, and targeted reads. For large or unfamiliar codebases, use `scout` to build a broad map efficiently before diving in.
+4. Use `resolve_library` / `get_library_docs` for unfamiliar libraries
+5. Use the **Research** output template from the inlined context above
+6. If `.gsd/REQUIREMENTS.md` exists, research against it. Identify which Active requirements are table stakes, likely omissions, overbuilt risks, or domain-standard behaviors the user may or may not want.
+7. Write `{{outputPath}}` with:
+   - Summary (2-3 paragraphs, primary recommendation)
+   - Don't Hand-Roll table (problems with existing solutions)
+   - Common Pitfalls (what goes wrong, how to avoid)
+   - Relevant Code (existing files, patterns, integration points)
+   - Sources
+
+## Strategic Questions to Answer
+
+- What should be proven first?
+- What existing patterns should be reused?
+- What boundary contracts matter?
+- What constraints does the existing codebase impose?
+- Are there known failure modes that should shape slice ordering?
+- If requirements exist: what table stakes, expected behaviors, continuity expectations, launchability expectations, or failure-visibility expectations are missing, optional, or clearly out of scope?
+- Which research findings should become candidate requirements versus remaining advisory only?
+
+**Research is advisory, not auto-binding.** Surface candidate requirements clearly instead of silently expanding scope.
+
+**You MUST write the file `{{outputPath}}` before finishing.**
+
+When done, say: "Milestone {{milestoneId}} researched."

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

@@ -0,0 +1,28 @@
+You are executing GSD auto-mode.
+
+## UNIT: Research Slice {{sliceId}} ("{{sliceTitle}}") — Milestone {{milestoneId}}
+
+All relevant context has been preloaded below — start working immediately without re-reading these files.
+
+{{inlinedContext}}
+
+### Dependency Slice Summaries
+
+Pay particular attention to **Forward Intelligence** sections — they contain hard-won knowledge about what's fragile, what assumptions changed, and what to watch out for.
+
+{{dependencySummaries}}
+
+Then research what this slice needs. Narrate key findings and surprises as you go — what exists, what's missing, what constrains the approach.
+0. If `REQUIREMENTS.md` was preloaded above, identify which Active requirements this slice owns or supports. Research should target these requirements — surfacing risks, unknowns, and implementation constraints that could affect whether the slice actually delivers them.
+1. If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during research, without relaxing required verification or artifact rules
+2. **Skill Discovery ({{skillDiscoveryMode}}):**{{skillDiscoveryInstructions}}
+3. Explore relevant code for this slice's scope. For targeted exploration, use `rg`, `find`, and reads. For broad or unfamiliar subsystems, use `scout` to map the relevant area first.
+4. Use `resolve_library` / `get_library_docs` for unfamiliar libraries
+5. Use the **Research** output template from the inlined context above
+6. Write `{{outputPath}}`
+
+The slice directory already exists at `{{slicePath}}/`. Do NOT mkdir — just write the file.
+
+**You MUST write the file `{{outputPath}}` before finishing.**
+
+When done, say: "Slice {{sliceId}} researched."

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

@@ -0,0 +1,66 @@
+## Review Migrated .gsd Directory
+
+A `/gsd migrate` command just wrote a `.gsd/` directory from an old `.planning` source. Your job is to audit the output and verify it meets GSD-2 standards before the user starts working with it.
+
+### Source
+- Old `.planning` directory: `{{sourcePath}}`
+- Written `.gsd` directory: `{{gsdPath}}`
+
+### Migration Stats
+{{previewStats}}
+
+### Review Checklist
+
+Work through each check. Report PASS/FAIL with specifics. Fix anything fixable in-place.
+
+#### 1. Structure Validation
+- Run `deriveState()` on the `.gsd` directory (import from `state.ts`, pass the **project root** as basePath)
+- Confirm it returns a coherent phase (not `pre-planning` unless the project is truly empty)
+- Confirm activeMilestone, activeSlice, activeTask are sensible for the project's completion state
+- Confirm progress counts match the migration preview stats
+
+#### 2. Roadmap Quality
+- Read `M001-ROADMAP.md` (and any other milestone roadmaps)
+- Confirm slice entries have meaningful titles (not file paths or garbled text)
+- Confirm `[x]`/`[ ]` completion markers are correct relative to the old roadmap
+- Confirm vision statement is present and meaningful (not empty or "Migration")
+
+#### 3. Content Spot-Check
+- Pick 2-3 slices with the most tasks and read their plan files
+- Confirm task titles and descriptions carry over meaningfully from the old plans
+- Confirm summary files exist for completed tasks and contain relevant content
+- Check that research files (if present) contain consolidated content, not empty stubs
+
+#### 4. Requirements (if any)
+- Read REQUIREMENTS.md
+- Confirm requirement IDs are present and non-duplicate
+- Confirm statuses make sense: completed old requirements should be `validated`, in-progress should be `active`
+
+#### 5. PROJECT.md
+- Read the written PROJECT.md
+- Confirm it contains the old project's description, not boilerplate
+- Confirm it reads like a useful project summary
+
+#### 6. Decisions
+- If DECISIONS.md was written, confirm it contains extracted decisions from old summaries (or is empty if no decisions existed)
+
+### Output Format
+
+Summarize your findings as:
+
+```
+Migration Review: <project name>
+================================
+Structure:     PASS/FAIL — <details>
+Roadmap:       PASS/FAIL — <details>
+Content:       PASS/FAIL — <details>
+Requirements:  PASS/FAIL/SKIP — <details>
+Project:       PASS/FAIL — <details>
+Decisions:     PASS/FAIL/SKIP — <details>
+
+Overall: PASS / PASS WITH NOTES / FAIL
+Issues: <list any problems found>
+Fixes applied: <list any in-place fixes made>
+```
+
+If the overall result is FAIL, explain what needs manual attention. If PASS WITH NOTES, explain what's imperfect but acceptable. If PASS, confirm the `.gsd` directory is ready for GSD-2 auto-mode.

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

@@ -0,0 +1,109 @@
+You are executing GSD auto-mode.
+
+## UNIT: Run UAT — {{milestoneId}}/{{sliceId}}
+
+All relevant context has been preloaded below. Start working immediately without re-reading these files.
+
+{{inlinedContext}}
+
+If a `GSD Skill Preferences` block is present in system context, use it to decide which skills to load and follow during UAT execution, without relaxing required verification or artifact rules.
+
+---
+
+## UAT Instructions
+
+**UAT file:** `{{uatPath}}`
+**UAT type:** `{{uatType}}`
+**Result file to write:** `{{uatResultPath}}`
+
+### If UAT type is `artifact-driven`
+
+You are the test runner. Execute every check defined in `{{uatPath}}` directly:
+
+- Run shell commands with `bash`
+- Run `grep` / `rg` checks against files
+- Run `node` / script invocations
+- Read files and verify their contents
+- Check that expected artifacts exist and have correct structure
+
+For each check, record:
+- The check description (from the UAT file)
+- The command or action taken
+- The actual result observed
+- PASS or FAIL verdict
+
+After running all checks, compute the **overall verdict**:
+- `PASS` — all checks passed
+- `FAIL` — one or more checks failed
+- `PARTIAL` — some checks passed, some failed or were skipped
+
+Write `{{uatResultPath}}` with:
+
+```markdown
+---
+sliceId: {{sliceId}}
+uatType: {{uatType}}
+verdict: PASS | FAIL | PARTIAL
+date: <ISO 8601 timestamp>
+---
+
+# UAT Result — {{sliceId}}
+
+## Checks
+
+| Check | Result | Notes |
+|-------|--------|-------|
+| <check description> | PASS / FAIL | <observed output or reason> |
+
+## Overall Verdict
+
+<PASS / FAIL / PARTIAL> — <one sentence summary>
+
+## Notes
+
+<any additional context, errors encountered, or follow-up items>
+```
+
+### If UAT type is NOT `artifact-driven` (type is `{{uatType}}`)
+
+This UAT type requires human execution or live-runtime observation that you cannot perform mechanically. Your role is to surface it clearly for review.
+
+Write `{{uatResultPath}}` with:
+
+```markdown
+---
+sliceId: {{sliceId}}
+uatType: {{uatType}}
+verdict: surfaced-for-human-review
+date: <ISO 8601 timestamp>
+---
+
+# UAT Result — {{sliceId}}
+
+## UAT Type
+
+`{{uatType}}` — requires human execution or live-runtime verification.
+
+## Status
+
+Surfaced for human review. Auto-mode will pause after this unit so the UAT can be performed manually.
+
+## UAT File
+
+See `{{uatPath}}` for the full UAT specification and acceptance criteria.
+
+## Instructions for Human Reviewer
+
+Review `{{uatPath}}`, perform the described UAT steps, then update this file with:
+- The actual verdict (PASS / FAIL / PARTIAL)
+- Results for each check
+- Date completed
+
+Once updated, run `/gsd auto` to resume auto-mode.
+```
+
+---
+
+**You MUST write `{{uatResultPath}}` before finishing.**
+
+When done, say: "UAT {{sliceId}} complete."