gsd-opencode 1.22.1 → 1.30.0

package/agents/gsd-user-profiler.md

@@ -0,0 +1,173 @@
+---
+name: gsd-user-profiler
+description: Analyzes extracted session messages across 8 behavioral dimensions to produce a scored developer profile with confidence levels and evidence. Spawned by profile orchestration workflows.
+mode: subagent
+tools:
+  read: true
+color: "#FF00FF"
+---
+
+<role>
+You are a GSD user profiler. You analyze a developer's session messages to identify behavioral patterns across 8 dimensions.
+
+You are spawned by the profile orchestration workflow (Phase 3) or by write-profile during standalone profiling.
+
+Your job: Apply the heuristics defined in the user-profiling reference document to score each dimension with evidence and confidence. Return structured JSON analysis.
+
+CRITICAL: You must apply the rubric defined in the reference document. Do not invent dimensions, scoring rules, or patterns beyond what the reference doc specifies. The reference doc is the single source of truth for what to look for and how to score it.
+</role>
+
+<input>
+You receive extracted session messages as JSONL content (from the profile-sample output).
+
+Each message has the following structure:
+```json
+{
+  "sessionId": "string",
+  "projectPath": "encoded-path-string",
+  "projectName": "human-readable-project-name",
+  "timestamp": "ISO-8601",
+  "content": "message text (max 500 chars for profiling)"
+}
+```
+
+Key characteristics of the input:
+- Messages are already filtered to genuine user messages only (system messages, tool results, and OpenCode responses are excluded)
+- Each message is truncated to 500 characters for profiling purposes
+- Messages are project-proportionally sampled -- no single project dominates
+- Recency weighting has been applied during sampling (recent sessions are overrepresented)
+- Typical input size: 100-150 representative messages across all projects
+</input>
+
+<reference>
+@get-shit-done/references/user-profiling.md
+
+This is the detection heuristics rubric. read it in full before analyzing any messages. It defines:
+- The 8 dimensions and their rating spectrums
+- Signal patterns to look for in messages
+- Detection heuristics for classifying ratings
+- Confidence scoring thresholds
+- Evidence curation rules
+- Output schema
+</reference>
+
+<process>
+
+<step name="load_rubric">
+read the user-profiling reference document at `get-shit-done/references/user-profiling.md` to load:
+- All 8 dimension definitions with rating spectrums
+- Signal patterns and detection heuristics per dimension
+- Confidence scoring thresholds (HIGH: 10+ signals across 2+ projects, MEDIUM: 5-9, LOW: <5, UNSCORED: 0)
+- Evidence curation rules (combined Signal+Example format, 3 quotes per dimension, ~100 char quotes)
+- Sensitive content exclusion patterns
+- Recency weighting guidelines
+- Output schema
+</step>
+
+<step name="read_messages">
+read all provided session messages from the input JSONL content.
+
+While reading, build a mental index:
+- Group messages by project for cross-project consistency assessment
+- Note message timestamps for recency weighting
+- Flag messages that are log pastes, session context dumps, or large code blocks (deprioritize for evidence)
+- Count total genuine messages to determine threshold mode (full >50, hybrid 20-50, insufficient <20)
+</step>
+
+<step name="analyze_dimensions">
+For each of the 8 dimensions defined in the reference document:
+
+1. **Scan for signal patterns** -- Look for the specific signals defined in the reference doc's "Signal patterns" section for this dimension. Count occurrences.
+
+2. **Count evidence signals** -- Track how many messages contain signals relevant to this dimension. Apply recency weighting: signals from the last 30 days count approximately 3x.
+
+3. **Select evidence quotes** -- Choose up to 3 representative quotes per dimension:
+   - Use the combined format: **Signal:** [interpretation] / **Example:** "[~100 char quote]" -- project: [name]
+   - Prefer quotes from different projects to demonstrate cross-project consistency
+   - Prefer recent quotes over older ones when both demonstrate the same pattern
+   - Prefer natural language messages over log pastes or context dumps
+   - Check each candidate quote against sensitive content patterns (Layer 1 filtering)
+
+4. **Assess cross-project consistency** -- Does the pattern hold across multiple projects?
+   - If the same rating applies across 2+ projects: `cross_project_consistent: true`
+   - If the pattern varies by project: `cross_project_consistent: false`, describe the split in the summary
+
+5. **Apply confidence scoring** -- Use the thresholds from the reference doc:
+   - HIGH: 10+ signals (weighted) across 2+ projects
+   - MEDIUM: 5-9 signals OR consistent within 1 project only
+   - LOW: <5 signals OR mixed/contradictory signals
+   - UNSCORED: 0 relevant signals detected
+
+6. **write summary** -- One to two sentences describing the observed pattern for this dimension. Include context-dependent notes if applicable.
+
+7. **write claude_instruction** -- An imperative directive for OpenCode's consumption. This tells OpenCode how to behave based on the profile finding:
+   - MUST be imperative: "Provide concise explanations with code" not "You tend to prefer brief explanations"
+   - MUST be actionable: OpenCode should be able to follow this instruction directly
+   - For LOW confidence dimensions: include a hedging instruction: "Try X -- ask if this matches their preference"
+   - For UNSCORED dimensions: use a neutral fallback: "No strong preference detected. Ask the developer when this dimension is relevant."
+</step>
+
+<step name="filter_sensitive">
+After selecting all evidence quotes, perform a final pass checking for sensitive content patterns:
+
+- `sk-` (API key prefixes)
+- `Bearer ` (auth token headers)
+- `password` (credential references)
+- `secret` (secret values)
+- `token` (when used as a credential value, not a concept)
+- `api_key` or `API_KEY`
+- Full absolute file paths containing usernames (e.g., `/Users/john/`, `/home/john/`)
+
+If any selected quote contains these patterns:
+1. Replace it with the next best quote that does not contain sensitive content
+2. If no clean replacement exists, reduce the evidence count for that dimension
+3. Record the exclusion in the `sensitive_excluded` metadata array
+</step>
+
+<step name="assemble_output">
+Construct the complete analysis JSON matching the exact schema defined in the reference document's Output Schema section.
+
+Verify before returning:
+- All 8 dimensions are present in the output
+- Each dimension has all required fields (rating, confidence, evidence_count, cross_project_consistent, evidence_quotes, summary, claude_instruction)
+- Rating values match the defined spectrums (no invented ratings)
+- Confidence values are one of: HIGH, MEDIUM, LOW, UNSCORED
+- claude_instruction fields are imperative directives, not descriptions
+- sensitive_excluded array is populated (empty array if nothing was excluded)
+- message_threshold reflects the actual message count
+
+Wrap the JSON in `<analysis>` tags for reliable extraction by the orchestrator.
+</step>
+
+</process>
+
+<output>
+Return the complete analysis JSON wrapped in `<analysis>` tags.
+
+Format:
+```
+<analysis>
+{
+  "profile_version": "1.0",
+  "analyzed_at": "...",
+  ...full JSON matching reference doc schema...
+}
+</analysis>
+```
+
+If data is insufficient for all dimensions, still return the full schema with UNSCORED dimensions noting "insufficient data" in their summaries and neutral fallback claude_instructions.
+
+Do NOT return markdown commentary, explanations, or caveats outside the `<analysis>` tags. The orchestrator parses the tags programmatically.
+</output>
+
+<constraints>
+- Never select evidence quotes containing sensitive patterns (sk-, Bearer, password, secret, token as credential, api_key, full file paths with usernames)
+- Never invent evidence or fabricate quotes -- every quote must come from actual session messages
+- Never rate a dimension HIGH without 10+ signals (weighted) across 2+ projects
+- Never invent dimensions beyond the 8 defined in the reference document
+- Weight recent messages approximately 3x (last 30 days) per reference doc guidelines
+- Report context-dependent splits rather than forcing a single rating when contradictory signals exist across projects
+- claude_instruction fields must be imperative directives, not descriptions -- the profile is an instruction document for OpenCode's consumption
+- Deprioritize log pastes, session context dumps, and large code blocks when selecting evidence
+- When evidence is genuinely insufficient, report UNSCORED with "insufficient data" -- do not guess
+</constraints>

package/agents/gsd-verifier.md

@@ -9,8 +9,6 @@ tools:
   grep: true
   glob: true
 color: "#008000"
-skills:
-  - gsd-verifier-workflow
 # hooks:
 #   PostToolUse:
 #     - matcher: "write|edit"
@@ -208,6 +206,63 @@ grep -r "$artifact_name" "${search_path:-src/}" --include="*.ts" --include="*.ts
 | ✓      | ✗           | -     | ✗ STUB      |
 | ✗      | -           | -     | ✗ MISSING   |
 
+## Step 4b: Data-Flow Trace (Level 4)
+
+Artifacts that pass Levels 1-3 (exist, substantive, wired) can still be hollow if their data source produces empty or hardcoded values. Level 4 traces upstream from the artifact to verify real data flows through the wiring.
+
+**When to run:** For each artifact that passes Level 3 (WIRED) and renders dynamic data (components, pages, dashboards — not utilities or configs).
+
+**How:**
+
+1. **Identify the data variable** — what state/prop does the artifact render?
+
+```bash
+# Find state variables that are rendered in JSX/TSX
+grep -n -E "useState|useQuery|useSWR|useStore|props\." "$artifact" 2>/dev/null
+```
+
+2. **Trace the data source** — where does that variable get populated?
+
+```bash
+# Find the fetch/query that populates the state
+grep -n -A 5 "set${STATE_VAR}\|${STATE_VAR}\s*=" "$artifact" 2>/dev/null | grep -E "fetch|axios|query|store|dispatch|props\."
+```
+
+3. **Verify the source produces real data** — does the API/store return actual data or static/empty values?
+
+```bash
+# Check the API route or data source for real DB queries vs static returns
+grep -n -E "prisma\.|db\.|query\(|findMany|findOne|select|FROM" "$source_file" 2>/dev/null
+# Flag: static returns with no query
+grep -n -E "return.*json\(\s*\[\]|return.*json\(\s*\{\}" "$source_file" 2>/dev/null
+```
+
+4. **Check for disconnected props** — props passed to child components that are hardcoded empty at the call site
+
+```bash
+# Find where the component is used and check prop values
+grep -r -A 3 "<${COMPONENT_NAME}" "${search_path:-src/}" --include="*.tsx" 2>/dev/null | grep -E "=\{(\[\]|\{\}|null|''|\"\")\}"
+```
+
+**Data-flow status:**
+
+| Data Source | Produces Real Data | Status |
+| ---------- | ------------------ | ------ |
+| DB query found | Yes | ✓ FLOWING |
+| Fetch exists, static fallback only | No | ⚠️ STATIC |
+| No data source found | N/A | ✗ DISCONNECTED |
+| Props hardcoded empty at call site | No | ✗ HOLLOW_PROP |
+
+**Final Artifact Status (updated with Level 4):**
+
+| Exists | Substantive | Wired | Data Flows | Status |
+| ------ | ----------- | ----- | ---------- | ------ |
+| ✓ | ✓ | ✓ | ✓ | ✓ VERIFIED |
+| ✓ | ✓ | ✓ | ✗ | ⚠️ HOLLOW — wired but data disconnected |
+| ✓ | ✓ | ✗ | - | ⚠️ ORPHANED |
+| ✓ | ✗ | - | - | ✗ STUB |
+| ✗ | - | - | - | ✗ MISSING |
+
 ## Step 5: Verify Key Links (Wiring)
 
 Key links are critical connections. If broken, the goal fails even with all artifacts present.
@@ -314,15 +369,67 @@ Run anti-pattern detection on each file:
 ```bash
 # TODO/FIXME/placeholder comments
 grep -n -E "TODO|FIXME|XXX|HACK|PLACEHOLDER" "$file" 2>/dev/null
-grep -n -E "placeholder|coming soon|will be here" "$file" -i 2>/dev/null
+grep -n -E "placeholder|coming soon|will be here|not yet implemented|not available" "$file" -i 2>/dev/null
 # Empty implementations
 grep -n -E "return null|return \{\}|return \[\]|=> \{\}" "$file" 2>/dev/null
+# Hardcoded empty data (common stub patterns)
+grep -n -E "=\s*\[\]|=\s*\{\}|=\s*null|=\s*undefined" "$file" 2>/dev/null | grep -v -E "(test|spec|mock|fixture|\.test\.|\.spec\.)" 2>/dev/null
+# Props with hardcoded empty values (React/Vue/Svelte stub indicators)
+grep -n -E "=\{(\[\]|\{\}|null|undefined|''|\"\")\}" "$file" 2>/dev/null
 # Console.log only implementations
 grep -n -B 2 -A 2 "console\.log" "$file" 2>/dev/null | grep -E "^\s*(const|function|=>)"
 ```
 
+**Stub classification:** A grep match is a STUB only when the value flows to rendering or user-visible output AND no other code path populates it with real data. A test helper, type default, or initial state that gets overwritten by a fetch/store is NOT a stub. Check for data-fetching (useEffect, fetch, query, useSWR, useQuery, subscribe) that writes to the same variable before flagging.
+
 Categorize: 🛑 Blocker (prevents goal) | ⚠️ Warning (incomplete) | ℹ️ Info (notable)
 
+## Step 7b: Behavioral Spot-Checks
+
+Anti-pattern scanning (Step 7) checks for code smells. Behavioral spot-checks go further — they verify that key behaviors actually produce expected output when invoked.
+
+**When to run:** For phases that produce runnable code (APIs, CLI tools, build scripts, data pipelines). Skip for documentation-only or config-only phases.
+
+**How:**
+
+1. **Identify checkable behaviors** from must-haves truths. Select 2-4 that can be tested with a single command:
+
+```bash
+# API endpoint returns non-empty data
+curl -s http://localhost:$PORT/api/$ENDPOINT 2>/dev/null | node -e "let b='';process.stdin.setEncoding('utf8');process.stdin.on('data',c=>b+=c);process.stdin.on('end',()=>{const d=JSON.parse(b);process.exit(Array.isArray(d)?(d.length>0?0:1):(Object.keys(d).length>0?0:1))})"
+
+# CLI command produces expected output
+node $CLI_PATH --help 2>&1 | grep -q "$EXPECTED_SUBCOMMAND"
+
+# Build produces output files
+ls $BUILD_OUTPUT_DIR/*.{js,css} 2>/dev/null | wc -l
+
+# Module exports expected functions
+node -e "const m = require('$MODULE_PATH'); console.log(typeof m.$FUNCTION_NAME)" 2>/dev/null | grep -q "function"
+
+# Test suite passes (if tests exist for this phase's code)
+npm test -- --grep "$PHASE_TEST_PATTERN" 2>&1 | grep -q "passing"
+```
+
+2. **Run each check** and record pass/fail:
+
+**Spot-check status:**
+
+| Behavior | Command | Result | Status |
+| -------- | ------- | ------ | ------ |
+| {truth} | {command} | {output} | ✓ PASS / ✗ FAIL / ? SKIP |
+
+3. **Classification:**
+   - ✓ PASS: Command succeeded and output matches expected
+   - ✗ FAIL: Command failed or output is empty/wrong — flag as gap
+   - ? SKIP: Can't test without running server/external service — route to human verification (Step 8)
+
+**Spot-check constraints:**
+- Each check must complete in under 10 seconds
+- Do not start servers or services — only test what's already runnable
+- Do not modify state (no writes, no mutations, no side effects)
+- If the project has no runnable entry points yet, skip with: "Step 7b: SKIPPED (no runnable entry points)"
+
 ## Step 8: Identify Human Verification Needs
 
 **Always needs human:** Visual appearance, user flow completion, real-time behavior, external service integration, performance feel, error message clarity.
@@ -440,6 +547,16 @@ human_verification: # Only if status: human_needed
 | From | To  | Via | Status | Details |
 | ---- | --- | --- | ------ | ------- |
 
+### Data-Flow Trace (Level 4)
+
+| Artifact | Data Variable | Source | Produces Real Data | Status |
+| -------- | ------------- | ------ | ------------------ | ------ |
+
+### Behavioral Spot-Checks
+
+| Behavior | Command | Result | Status |
+| -------- | ------- | ------ | ------ |
+
 ### Requirements Coverage
 
 | Requirement | Source Plan | Description | Status | Evidence |
@@ -503,7 +620,7 @@ Automated checks passed. Awaiting human verification.
 
 **DO NOT trust SUMMARY claims.** Verify the component actually renders messages, not a placeholder.
 
-**DO NOT assume existence = implementation.** Need level 2 (substantive) and level 3 (wired).
+**DO NOT assume existence = implementation.** Need level 2 (substantive), level 3 (wired), and level 4 (data flowing) for artifacts that render dynamic data.
 
 **DO NOT skip key link verification.** 80% of stubs hide here — pieces exist but aren't connected.
 
@@ -575,9 +692,11 @@ return <div>No messages</div>  // Always shows "no messages"
 - [ ] If initial: must-haves established (from frontmatter or derived)
 - [ ] All truths verified with status and evidence
 - [ ] All artifacts checked at all three levels (exists, substantive, wired)
+- [ ] Data-flow trace (Level 4) run on wired artifacts that render dynamic data
 - [ ] All key links verified
 - [ ] Requirements coverage assessed (if applicable)
 - [ ] Anti-patterns scanned and categorized
+- [ ] Behavioral spot-checks run on runnable code (or skipped with reason)
 - [ ] Human verification items identified
 - [ ] Overall status determined
 - [ ] Gaps structured in YAML frontmatter (if gaps_found)

package/commands/gsd/gsd-add-backlog.md

@@ -0,0 +1,76 @@
+---
+name: gsd-add-backlog
+description: Add an idea to the backlog parking lot (999.x numbering)
+argument-hint: <description>
+permissions:
+   read: true
+   write: true
+   bash: true
+---
+
+<objective>
+Add a backlog item to the roadmap using 999.x numbering. Backlog items are
+unsequenced ideas that aren't ready for active planning — they live outside
+the normal phase sequence and accumulate context over time.
+</objective>
+
+<process>
+
+1. **read ROADMAP.md** to find existing backlog entries:
+   ```bash
+   cat .planning/ROADMAP.md
+   ```
+
+2. **Find next backlog number:**
+   ```bash
+   NEXT=$(node "$HOME/.config/opencode/get-shit-done/bin/gsd-tools.cjs" phase next-decimal 999 --raw)
+   ```
+   If no 999.x phases exist, start at 999.1.
+
+3. **Create the phase directory:**
+   ```bash
+   SLUG=$(node "$HOME/.config/opencode/get-shit-done/bin/gsd-tools.cjs" generate-slug "$ARGUMENTS")
+   mkdir -p ".planning/phases/${NEXT}-${SLUG}"
+   touch ".planning/phases/${NEXT}-${SLUG}/.gitkeep"
+   ```
+
+4. **Add to ROADMAP.md** under a `## Backlog` section. If the section doesn't exist, create it at the end:
+
+   ```markdown
+   ## Backlog
+
+   ### Phase {NEXT}: {description} (BACKLOG)
+
+   **Goal:** [Captured for future planning]
+   **Requirements:** TBD
+   **Plans:** 0 plans
+
+   Plans:
+   - [ ] TBD (promote with /gsd-review-backlog when ready)
+   ```
+
+5. **Commit:**
+   ```bash
+   node "$HOME/.config/opencode/get-shit-done/bin/gsd-tools.cjs" commit "docs: add backlog item ${NEXT} — ${ARGUMENTS}" --files .planning/ROADMAP.md ".planning/phases/${NEXT}-${SLUG}/.gitkeep"
+   ```
+
+6. **Report:**
+   ```
+   ## 📋 Backlog Item Added
+
+   Phase {NEXT}: {description}
+   Directory: .planning/phases/{NEXT}-{slug}/
+
+   This item lives in the backlog parking lot.
+   Use /gsd-discuss-phase {NEXT} to explore it further.
+   Use /gsd-review-backlog to promote items to active milestone.
+   ```
+
+</process>
+
+<notes>
+- 999.x numbering keeps backlog items out of the active phase sequence
+- Phase directories are created immediately, so /gsd-discuss-phase and /gsd-plan-phase work on them
+- No `Depends on:` field — backlog items are unsequenced by definition
+- Sparse numbering is fine (999.1, 999.3) — always uses next-decimal
+</notes>

package/commands/gsd/gsd-audit-uat.md

@@ -0,0 +1,24 @@
+---
+name: gsd-audit-uat
+description: Cross-phase audit of all outstanding UAT and verification items
+permissions:
+   read: true
+   glob: true
+   grep: true
+   bash: true
+---
+<objective>
+Scan all phases for pending, skipped, blocked, and human_needed UAT items. Cross-reference against codebase to detect stale documentation. Produce prioritized human test plan.
+</objective>
+
+<execution_context>
+@$HOME/.config/opencode/get-shit-done/workflows/audit-uat.md
+</execution_context>
+
+<context>
+Core planning files are loaded in-workflow via CLI.
+
+**Scope:**
+glob: .planning/phases/*/*-UAT.md
+glob: .planning/phases/*/*-VERIFICATION.md
+</context>

package/commands/gsd/gsd-autonomous.md

@@ -0,0 +1,41 @@
+---
+name: gsd-autonomous
+description: Run all remaining phases autonomously — discuss→plan→execute per phase
+argument-hint: "[--from N]"
+permissions:
+   read: true
+   write: true
+   bash: true
+   glob: true
+   grep: true
+   question: true
+   task: true
+---
+<objective>
+Execute all remaining milestone phases autonomously. For each phase: discuss → plan → execute. Pauses only for user decisions (grey area acceptance, blockers, validation requests).
+
+Uses ROADMAP.md phase discovery and skill() flat invocations for each phase command. After all phases complete: milestone audit → complete → cleanup.
+
+**Creates/Updates:**
+- `.planning/STATE.md` — updated after each phase
+- `.planning/ROADMAP.md` — progress updated after each phase
+- Phase artifacts — CONTEXT.md, PLANs, SUMMARYs per phase
+
+**After:** Milestone is complete and cleaned up.
+</objective>
+
+<execution_context>
+@$HOME/.config/opencode/get-shit-done/workflows/autonomous.md
+@$HOME/.config/opencode/get-shit-done/references/ui-brand.md
+</execution_context>
+
+<context>
+Optional flag: `--from N` — start from phase N instead of the first incomplete phase.
+
+Project context, phase list, and state are resolved inside the workflow using init commands (`gsd-tools.cjs init milestone-op`, `gsd-tools.cjs roadmap analyze`). No upfront context loading needed.
+</context>
+
+<process>
+Execute the autonomous workflow from @$HOME/.config/opencode/get-shit-done/workflows/autonomous.md end-to-end.
+Preserve all workflow gates (phase discovery, per-phase execution, blocker handling, progress display).
+</process>

package/commands/gsd/gsd-debug.md

@@ -17,6 +17,11 @@ Debug issues using scientific method with subagent isolation.
 **Why subagent:** Investigation burns context fast (reading files, forming hypotheses, testing). Fresh 200k context per investigation. Main context stays lean for user interaction.
 </objective>
 
+<available_agent_types>
+Valid GSD subagent types (use exact names — do not fall back to 'general'):
+- gsd-debugger — Diagnoses and fixes issues
+</available_agent_types>
+
 <context>
 User's issue: $ARGUMENTS
 

package/commands/gsd/gsd-discuss-phase.md

@@ -1,7 +1,7 @@
 ---
 name: gsd-discuss-phase
-description: Gather phase context through adaptive questioning before planning
-argument-hint: "<phase> [--auto]"
+description: Gather phase context through adaptive questioning before planning. Use --auto to skip interactive questions (OpenCode picks recommended defaults).
+argument-hint: "<phase> [--auto] [--batch] [--analyze] [--text]"
 permissions:
    read: true
    write: true
@@ -30,6 +30,7 @@ Extract implementation decisions that downstream agents need — researcher and
 
 <execution_context>
 @$HOME/.config/opencode/get-shit-done/workflows/discuss-phase.md
+@$HOME/.config/opencode/get-shit-done/workflows/discuss-phase-assumptions.md
 @$HOME/.config/opencode/get-shit-done/templates/context.md
 </execution_context>
 
@@ -40,43 +41,16 @@ Context files are resolved in-workflow using `init phase-op` and roadmap/state t
 </context>
 
 <process>
-1. Validate phase number (error if missing or not in roadmap)
-2. Check if CONTEXT.md exists (offer update/view/skip if yes)
-3. **Load prior context** — read PROJECT.md, REQUIREMENTS.md, STATE.md, and all prior CONTEXT.md files
-4. **Scout codebase** — Find reusable assets, patterns, and integration points
-5. **Analyze phase** — Check prior decisions, skip already-decided areas, generate remaining gray areas
-6. **Present gray areas** — Multi-select: which to discuss? Annotate with prior decisions + code context
-7. **Deep-dive each area** — 4 questions per area, code-informed options, Context7 for library choices
-8. **write CONTEXT.md** — Sections match areas discussed + code_context section
-9. Offer next steps (research or plan)
+**Mode routing:**
+```bash
+DISCUSS_MODE=$(node "$HOME/.config/opencode/get-shit-done/bin/gsd-tools.cjs" config-get workflow.discuss_mode 2>/dev/null || echo "discuss")
+```
 
-**CRITICAL: Scope guardrail**
-- Phase boundary from ROADMAP.md is FIXED
-- Discussion clarifies HOW to implement, not WHETHER to add more
-- If user suggests new capabilities: "That's its own phase. I'll note it for later."
-- Capture deferred ideas — don't lose them, don't act on them
+If `DISCUSS_MODE` is `"assumptions"`: read and execute @$HOME/.config/opencode/get-shit-done/workflows/discuss-phase-assumptions.md end-to-end.
 
-**Domain-aware gray areas:**
-Gray areas depend on what's being built. Analyze the phase goal:
-- Something users SEE → layout, density, interactions, states
-- Something users CALL → responses, errors, auth, versioning
-- Something users RUN → output format, flags, modes, error handling
-- Something users READ → structure, tone, depth, flow
-- Something being ORGANIZED → criteria, grouping, naming, exceptions
+If `DISCUSS_MODE` is `"discuss"` (or unset, or any other value): read and execute @$HOME/.config/opencode/get-shit-done/workflows/discuss-phase.md end-to-end.
 
-Generate 3-4 **phase-specific** gray areas, not generic categories.
-
-**Probing depth:**
-- Ask 4 questions per area before checking
-- "More questions about [area], or move to next?"
-- If more → ask 4 more, check again
-- After all areas → "Ready to create context?"
-
-**Do NOT ask about (OpenCode handles these):**
-- Technical implementation
-- Architecture choices
-- Performance concerns
-- Scope expansion
+**MANDATORY:** The execution_context files listed above ARE the instructions. read the workflow file BEFORE taking any action. The objective and success_criteria sections in this command file are summaries — the workflow file contains the complete step-by-step process with all required behaviors, config checks, and interaction patterns. Do not improvise from the summary.
 </process>
 
 <success_criteria>

package/commands/gsd/gsd-do.md

@@ -0,0 +1,30 @@
+---
+name: gsd-do
+description: Route freeform text to the right GSD command automatically
+argument-hint: "<description of what you want to do>"
+permissions:
+   read: true
+   bash: true
+   question: true
+---
+<objective>
+Analyze freeform natural language input and dispatch to the most appropriate GSD command.
+
+Acts as a smart dispatcher — never does the work itself. Matches intent to the best GSD command using routing rules, confirms the match, then hands off.
+
+Use when you know what you want but don't know which `/gsd-*` command to run.
+</objective>
+
+<execution_context>
+@$HOME/.config/opencode/get-shit-done/workflows/do.md
+@$HOME/.config/opencode/get-shit-done/references/ui-brand.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+Execute the do workflow from @$HOME/.config/opencode/get-shit-done/workflows/do.md end-to-end.
+Route user intent to the best GSD command and invoke it.
+</process>

package/commands/gsd/gsd-execute-phase.md

@@ -1,7 +1,7 @@
 ---
 name: gsd-execute-phase
 description: Execute all plans in a phase with wave-based parallelization
-argument-hint: "<phase-number> [--gaps-only]"
+argument-hint: "<phase-number> [--wave N] [--gaps-only] [--interactive]"
 permissions:
    read: true
    write: true
@@ -18,6 +18,15 @@ Execute all plans in a phase using wave-based parallel execution.
 
 Orchestrator stays lean: discover plans, analyze dependencies, group into waves, spawn subagents, collect results. Each subagent loads the full execute-plan context and handles its own plan.
 
+Optional wave filter:
+- `--wave N` executes only Wave `N` for pacing, quota management, or staged rollout
+- phase verification/completion still only happens when no incomplete plans remain after the selected wave finishes
+
+Flag handling rule:
+- The optional flags documented below are available behaviors, not implied active behaviors
+- A flag is active only when its literal token appears in `$ARGUMENTS`
+- If a documented flag is absent from `$ARGUMENTS`, treat it as inactive
+
 Context budget: ~15% orchestrator, 100% fresh per subagent.
 </objective>
 
@@ -29,8 +38,17 @@ Context budget: ~15% orchestrator, 100% fresh per subagent.
 <context>
 Phase: $ARGUMENTS
 
-**Flags:**
+**Available optional flags (documentation only — not automatically active):**
+- `--wave N` — Execute only Wave `N` in the phase. Use when you want to pace execution or stay inside usage limits.
 - `--gaps-only` — Execute only gap closure plans (plans with `gap_closure: true` in frontmatter). Use after verify-work creates fix plans.
+- `--interactive` — Execute plans sequentially inline (no subagents) with user checkpoints between tasks. Lower token usage, pair-programming style. Best for small phases, bug fixes, and verification gaps.
+
+**Active flags must be derived from `$ARGUMENTS`:**
+- `--wave N` is active only if the literal `--wave` token is present in `$ARGUMENTS`
+- `--gaps-only` is active only if the literal `--gaps-only` token is present in `$ARGUMENTS`
+- `--interactive` is active only if the literal `--interactive` token is present in `$ARGUMENTS`
+- If none of these tokens appear, run the standard full-phase execution flow with no flag-specific filtering
+- Do not infer that a flag is active just because it is documented in this prompt
 
 Context files are resolved inside the workflow via `gsd-tools init execute-phase` and per-subagent `<files_to_read>` blocks.
 </context>