gsd-opencode 1.4.2 → 1.5.0

package/get-shit-done/references/plan-format.md

@@ -1,13 +1,13 @@
 <overview>
-Claude-executable plans have a specific format that enables Claude to implement without interpretation. This reference defines what makes a plan executable vs. vague.
+Claude-executable plans have a specific format that enables Opencode agent to implement without interpretation. This reference defines what makes a plan executable vs. vague.
 
-**Key insight:** PLAN.md IS the executable prompt. It contains everything Claude needs to execute the phase, including objective, context references, tasks, verification, success criteria, and output specification.
+**Key insight:** PLAN.md IS the executable prompt. It contains everything Opencode agent needs to execute the phase, including objective, context references, tasks, verification, success criteria, and output specification.
 </overview>
 
 <core_principle>
-A plan is Claude-executable when Claude can read the PLAN.md and immediately start implementing without asking clarifying questions.
+A plan is Claude-executable when Opencode agent can read the PLAN.md and immediately start implementing without asking clarifying questions.
 
-If Claude has to guess, interpret, or make assumptions - the task is too vague.
+If Opencode agent has to guess, interpret, or make assumptions - the task is too vague.
 </core_principle>
 
 <frontmatter>
@@ -37,7 +37,7 @@ domain: [optional]          # Domain skill if loaded
 | `autonomous` | Yes | `true` if no checkpoints, `false` if has checkpoints |
 | `domain` | No | Domain skill if loaded (e.g., `next-js`) |
 
-**Wave is pre-computed:** `/gsd:plan-phase` assigns wave numbers based on `depends_on`. `/gsd:execute-phase` reads `wave` directly from frontmatter and groups plans by wave number. No runtime dependency analysis needed.
+**Wave is pre-computed:** `/gsd-plan-phase` assigns wave numbers based on `depends_on`. `/gsd-execute-phase` reads `wave` directly from frontmatter and groups plans by wave number. No runtime dependency analysis needed.
 
 **Checkpoint handling:** Plans with `autonomous: false` require user interaction. They run in their assigned wave but pause at checkpoints.
 </frontmatter>
@@ -88,7 +88,7 @@ Output: [...]
 </task>
 
 <task type="checkpoint:human-verify" gate="blocking">
-  <what-built>[what Claude automated]</what-built>
+  <what-built>[what Opencode agent automated]</what-built>
   <how-to-verify>[numbered verification steps]</how-to-verify>
   <resume-signal>[how to continue - "approved" or describe issues]</resume-signal>
 </task>
@@ -170,7 +170,7 @@ Should be testable without subjective judgment.
 Tasks have a `type` attribute that determines how they execute:
 
 <type name="auto">
-**Default task type** - Claude executes autonomously.
+**Default task type** - Opencode agent executes autonomously.
 
 **Structure:**
 
@@ -184,11 +184,11 @@ Tasks have a `type` attribute that determines how they execute:
 </task>
 ```
 
-Use for: Everything Claude can do independently (code, tests, builds, file operations).
+Use for: Everything Opencode agent can do independently (code, tests, builds, file operations).
 </type>
 
 <type name="checkpoint:human-action">
-**RARELY USED** - Only for actions with NO CLI/API. Claude automates everything possible first.
+**RARELY USED** - Only for actions with NO CLI/API. Opencode agent automates everything possible first.
 
 **Structure:**
 
@@ -196,10 +196,10 @@ Use for: Everything Claude can do independently (code, tests, builds, file opera
 <task type="checkpoint:human-action" gate="blocking">
   <action>[Unavoidable manual step - email link, 2FA code]</action>
   <instructions>
-    [What Claude already automated]
+    [What Opencode agent already automated]
     [The ONE thing requiring human action]
   </instructions>
-  <verification>[What Claude can check afterward]</verification>
+  <verification>[What Opencode agent can check afterward]</verification>
   <resume-signal>[How to continue]</resume-signal>
 </task>
 ```
@@ -208,7 +208,7 @@ Use ONLY for: Email verification links, SMS 2FA codes, manual approvals with no
 
 Do NOT use for: Anything with a CLI (Vercel, Stripe, Upstash, Railway, GitHub), builds, tests, file creation, deployments.
 
-**Execution:** Claude automates everything with CLI/API, stops only for truly unavoidable manual steps.
+**Execution:** Opencode agent automates everything with CLI/API, stops only for truly unavoidable manual steps.
 </type>
 
 <type name="checkpoint:human-verify">
@@ -233,7 +233,7 @@ Do NOT use for: Anything with a CLI (Vercel, Stripe, Upstash, Railway, GitHub),
 
 Use for: UI/UX verification, visual design checks, animation smoothness, accessibility testing.
 
-**Execution:** Claude builds the feature, stops, provides testing instructions, waits for approval/feedback.
+**Execution:** Opencode agent builds the feature, stops, provides testing instructions, waits for approval/feedback.
 </type>
 
 <type name="checkpoint:decision">
@@ -268,23 +268,23 @@ Use for: UI/UX verification, visual design checks, animation smoothness, accessi
 
 Use for: Technology selection, architecture decisions, design choices, feature prioritization.
 
-**Execution:** Claude presents options with balanced pros/cons, waits for decision, proceeds with chosen direction.
+**Execution:** Opencode agent presents options with balanced pros/cons, waits for decision, proceeds with chosen direction.
 </type>
 
 **When to use checkpoints:**
 
-- Visual/UX verification (after Claude builds) → `checkpoint:human-verify`
+- Visual/UX verification (after Opencode agent builds) → `checkpoint:human-verify`
 - Implementation direction choice → `checkpoint:decision`
 - Truly unavoidable manual actions (email links, 2FA) → `checkpoint:human-action` (rare)
 
 **When NOT to use checkpoints:**
 
-- Anything with CLI/API (Claude automates it) → `type="auto"`
+- Anything with CLI/API (Opencode agent automates it) → `type="auto"`
 - Deployments (Vercel, Railway, Fly) → `type="auto"` with CLI
 - Creating resources (Upstash, Stripe, GitHub) → `type="auto"` with CLI/API
 - File operations, tests, builds → `type="auto"`
 
-**Golden rule:** If Claude CAN automate it, Claude MUST automate it.
+**Golden rule:** If Opencode agent CAN automate it, Opencode agent MUST automate it.
 
 **Checkpoint impact on parallelization:**
 - Plans with checkpoints set `autonomous: false` in frontmatter
@@ -341,7 +341,7 @@ Use @file references to load context for the prompt:
 </context>
 ```
 
-Reference files that Claude needs to understand before implementing.
+Reference files that Opencode agent needs to understand before implementing.
 
 **Anti-pattern:** Reflexive chaining (02 refs 01, 03 refs 02). Only reference what you actually need.
 </context_references>
@@ -416,7 +416,7 @@ Claude: "How? What type? What library? Where?"
 </task>
 ```
 
-Claude can implement this immediately.
+Opencode agent can implement this immediately.
 </just_right>
 
 <note_on_tdd>
@@ -426,7 +426,7 @@ If email validation warrants TDD, create a TDD plan for it. See `./tdd.md` for T
 </note_on_tdd>
 
 <too_detailed>
-Writing the actual code in the plan. Trust Claude to implement from clear instructions.
+Writing the actual code in the plan. Trust Opencode agent to implement from clear instructions.
 </too_detailed>
 </specificity_levels>
 
@@ -438,7 +438,7 @@ Writing the actual code in the plan. Trust Claude to implement from clear instru
 - "Make it production-ready"
 - "Add proper error handling"
 
-These require Claude to decide WHAT to do. Specify it.
+These require Opencode agent to decide WHAT to do. Specify it.
 </vague_actions>
 
 <unverifiable_completion>
@@ -457,12 +457,12 @@ These require subjective judgment. Make it objective.
 - "Follow best practices"
 - "Like the other endpoints"
 
-Claude doesn't know your standards. Be explicit.
+Opencode agent doesn't know your standards. Be explicit.
 </missing_context>
 </anti_patterns>
 
 <sizing_tasks>
-Good task size: 15-60 minutes of Claude work.
+Good task size: 15-60 minutes of Opencode agent work.
 
 **Too small**: "Add import statement for bcrypt" (combine with related task)
 **Just right**: "Create login endpoint with JWT validation" (focused, specific)

package/get-shit-done/references/principles.md

@@ -6,8 +6,8 @@ Core principles for the Gets Shit Done planning system.
 You are planning for ONE person (the user) and ONE implementer (Claude).
 - No teams, stakeholders, ceremonies, coordination overhead
 - User is the visionary/product owner
-- Claude is the builder
-- Estimate effort in Claude execution time, not human dev time
+- Opencode agent is the builder
+- Estimate effort in Opencode agent execution time, not human dev time
 </solo_developer_claude>
 
 <plans_are_prompts>
@@ -49,7 +49,7 @@ Plans must complete within reasonable context usage.
 
 <claude_automates>
 
-If Claude CAN do it via CLI/API/tool, Claude MUST do it.
+If Opencode agent CAN do it via CLI/API/tool, Opencode agent MUST do it.
 
 Checkpoints are for:
 - **Verification** - Human confirms Claude's work (visual, UX)
@@ -129,7 +129,7 @@ Each task gets its own commit immediately after completion:
 - One final metadata commit per plan: `docs({phase}-{plan}): complete [plan-name]`
 
 **Why per-task commits:**
-- Git history becomes primary context source for future Claude sessions
+- Git history becomes primary context source for future Opencode agent sessions
 - `git bisect` finds exact failing task, not just failing plan
 - Each task independently revertable
 - Better failure recovery (task 1 committed ✅, retry task 2)
@@ -148,7 +148,7 @@ NEVER include:
 - Team structures, RACI matrices
 - Stakeholder management
 - Sprint ceremonies
-- Human dev time estimates (hours, days, weeks—Claude works differently)
+- Human dev time estimates (hours, days, weeks—Opencode agent works differently)
 - Change management processes
 - Documentation for documentation's sake
 

package/get-shit-done/references/questioning.md

@@ -85,7 +85,7 @@ Use question:
 **BAD — Corporate speak:**
 - "What are your success criteria?"
 - "What's your budget?"
-- "Have you done X before?" (irrelevant — Claude builds)
+- "Have you done X before?" (irrelevant — Opencode agent builds)
 
 **GOOD — Concrete options that help them think:**
 - header: "Done"
@@ -155,7 +155,7 @@ Loop until "Create PROJECT.md" selected.
 - **Corporate speak** - "What are your success criteria?" "Who are your stakeholders?"
 - **Rushing** - Minimizing questions to get to "the work"
 - **Assuming** - Filling gaps with assumptions instead of asking
-- **User skills** - NEVER ask about user's technical experience. Claude builds — user's skills are irrelevant.
+- **User skills** - NEVER ask about user's technical experience. Opencode agent builds — user's skills are irrelevant.
 - **Premature constraints** - Asking about tech stack before understanding the idea
 - **Shallow acceptance** - Taking vague answers without probing for specifics
 </anti_patterns>

package/get-shit-done/references/research-pitfalls.md

@@ -58,13 +58,13 @@ Search queries (use WebSearch):
 
 <pitfall_tool_variations>
 **What**: Conflating capabilities across different tools/environments
-**Example**: "Claude Desktop supports X" ≠ "OpenCode supports X"
+**Example**: "OpenCode or Desktop supports X" ≠ "OpenCode supports X"
 **Why it happens**: Not explicitly checking each environment separately
 **Prevention**:
 ```xml
 <verification_checklist>
-□ Claude Desktop capabilities
 □ OpenCode capabilities
+□ OpenCode or Desktop capabilities
 □ VS Code extension capabilities
 □ API/SDK capabilities
 Document which environment supports which features

package/get-shit-done/references/scope-estimation.md

@@ -2,7 +2,7 @@
 Plans must maintain consistent quality from first task to last. This requires understanding quality degradation and splitting aggressively.
 
 <quality_insight>
-Claude degrades when it *perceives* context pressure and enters "completion mode."
+Opencode agent degrades when it *perceives* context pressure and enters "completion mode."
 
 | Context Usage | Quality | Claude's State |
 |---------------|---------|----------------|
@@ -11,7 +11,7 @@ Claude degrades when it *perceives* context pressure and enters "completion mode
 | 50-70% | DEGRADING | Efficiency mode begins |
 | 70%+ | POOR | Rushed, minimal |
 
-**The 40-50% inflection point:** Claude sees context mounting and thinks "I'd better conserve now." Result: "I'll complete the remaining tasks more concisely" = quality crash.
+**The 40-50% inflection point:** Opencode agent sees context mounting and thinks "I'd better conserve now." Result: "I'll complete the remaining tasks more concisely" = quality crash.
 
 **The rule:** Stop BEFORE quality degrades, not at context limit.
 </quality_insight>

package/get-shit-done/templates/DEBUG.md

@@ -67,8 +67,8 @@ files_changed: []
 
 **Current Focus:**
 - OVERWRITE entirely on each update
-- Always reflects what Claude is doing RIGHT NOW
-- If Claude reads this after /clear, it knows exactly where to resume
+- Always reflects what Opencode agent is doing RIGHT NOW
+- If Opencode agent reads this after /clear, it knows exactly where to resume
 - Fields: hypothesis, test, expecting, next_action
 
 **Symptoms:**
@@ -99,7 +99,7 @@ files_changed: []
 
 <lifecycle>
 
-**Creation:** Immediately when /gsd:debug is called
+**Creation:** Immediately when /gsd-debug is called
 - Create file with trigger from user input
 - Set status to "gathering"
 - Current Focus: next_action = "gather symptoms"
@@ -135,7 +135,7 @@ files_changed: []
 
 <resume_behavior>
 
-When Claude reads this file after /clear:
+When Opencode agent reads this file after /clear:
 
 1. Parse frontmatter → know status
 2. Read Current Focus → know exactly what was happening
@@ -143,7 +143,7 @@ When Claude reads this file after /clear:
 4. Read Evidence → know what's been learned
 5. Continue from next_action
 
-The file IS the debugging brain. Claude should be able to resume perfectly from any interruption point.
+The file IS the debugging brain. Opencode agent should be able to resume perfectly from any interruption point.
 
 </resume_behavior>
 

package/get-shit-done/templates/agent-history.md

@@ -230,7 +230,7 @@ jq '.entries[] | select(.status == "spawned" and .parallel_group != null)' .plan
 
 ### Resume Command
 
-`/gsd:resume-task` accepts:
+`/gsd-resume-task` accepts:
 - No argument: Resume most recent interrupted agent
 - Agent ID: Resume specific agent
 - `--batch`: Resume entire parallel group

package/get-shit-done/templates/checkpoint-return.md

@@ -63,7 +63,7 @@ Type "approved" or describe issues to fix.
 ### Checkpoint Details
 
 **Automation attempted:**
-[What Claude tried to do]
+[What Opencode agent tried to do]
 
 **Error encountered:**
 [Exact error message or auth failure]
@@ -73,7 +73,7 @@ Type "approved" or describe issues to fix.
 2. [Step 2]
 
 **I'll verify after:**
-[How Claude will confirm completion]
+[How Opencode agent will confirm completion]
 
 ### Awaiting
 

package/get-shit-done/templates/codebase/architecture.md

@@ -238,7 +238,7 @@ Template for `.planning/codebase/ARCHITECTURE.md` - captures conceptual code org
 - Implementation details of specific features
 
 **File paths ARE welcome:**
-Include file paths as concrete examples of abstractions. Use backtick formatting: `src/services/user.ts`. This makes the architecture document actionable for Claude when planning.
+Include file paths as concrete examples of abstractions. Use backtick formatting: `src/services/user.ts`. This makes the architecture document actionable for Opencode agent when planning.
 
 **When filling this template:**
 - Read main entry points (index, server, main)

package/get-shit-done/templates/codebase/concerns.md

@@ -302,7 +302,7 @@ Template for `.planning/codebase/CONCERNS.md` - captures known issues and areas
 - Estimating risk of changes
 - Understanding where to be careful
 - Prioritizing improvements
-- Onboarding new Claude contexts
+- Onboarding new Opencode agent contexts
 - Planning refactoring work
 
 **How this gets populated:**

package/get-shit-done/templates/codebase/conventions.md

@@ -2,7 +2,7 @@
 
 Template for `.planning/codebase/CONVENTIONS.md` - captures coding style and patterns.
 
-**Purpose:** Document how code is written in this codebase. Prescriptive guide for Claude to match existing style.
+**Purpose:** Document how code is written in this codebase. Prescriptive guide for Opencode agent to match existing style.
 
 ---
 

package/get-shit-done/templates/context.md

@@ -116,10 +116,10 @@ The user is the visionary. They know:
 - References to things they like
 
 The user does NOT know (and shouldn't be asked):
-- Codebase patterns (Claude reads the code)
-- Technical risks (Claude identifies during research)
-- Implementation constraints (Claude figures out)
-- Success metrics (Claude infers from the work)
+- Codebase patterns (Opencode agent reads the code)
+- Technical risks (Opencode agent identifies during research)
+- Implementation constraints (Opencode agent figures out)
+- Success metrics (Opencode agent infers from the work)
 
 **Content should read like:**
 - A founder describing their product vision

package/get-shit-done/templates/continue-here.md

@@ -71,7 +71,7 @@ Required YAML frontmatter:
 </yaml_fields>
 
 <guidelines>
-- Be specific enough that a fresh Claude instance understands immediately
+- Be specific enough that a fresh Opencode agent instance understands immediately
 - Include WHY decisions were made, not just what
 - The `<next_action>` should be actionable without reading anything else
 - This file gets DELETED after resume - it's not permanent storage

package/get-shit-done/templates/discovery.md

@@ -4,7 +4,7 @@ Template for `.planning/phases/XX-name/DISCOVERY.md` - shallow research for libr
 
 **Purpose:** Answer "which library/option should we use" questions during mandatory discovery in plan-phase.
 
-For deep ecosystem research ("how do experts build this"), use `/gsd:research-phase` which produces RESEARCH.md.
+For deep ecosystem research ("how do experts build this"), use `/gsd-research-phase` which produces RESEARCH.md.
 
 ---
 
@@ -142,5 +142,5 @@ Create `.planning/phases/XX-name/DISCOVERY.md`:
 - Niche/complex domains (3D, games, audio, shaders)
 - Need ecosystem knowledge, not just library choice
 - "How do experts build this" questions
-- Use `/gsd:research-phase` for these
+- Use `/gsd-research-phase` for these
 </guidelines>

package/get-shit-done/templates/milestone-context.md

@@ -2,7 +2,7 @@
 
 Template for `.planning/MILESTONE-CONTEXT.md` - temporary handoff file from discuss-milestone to create-milestone.
 
-**Purpose:** Persist milestone discussion context so `/clear` can be used between commands. This file is consumed by `/gsd:new-milestone` and deleted after the milestone is created.
+**Purpose:** Persist milestone discussion context so `/clear` can be used between commands. This file is consumed by `/gsd-new-milestone` and deleted after the milestone is created.
 
 ---
 
@@ -12,7 +12,7 @@ Template for `.planning/MILESTONE-CONTEXT.md` - temporary handoff file from disc
 # Milestone Context
 
 **Generated:** [date]
-**Status:** Ready for /gsd:new-milestone
+**Status:** Ready for /gsd-new-milestone
 
 <features>
 ## Features to Build
@@ -64,7 +64,7 @@ Template for `.planning/MILESTONE-CONTEXT.md` - temporary handoff file from disc
 
 ---
 
-*This file is temporary. It will be deleted after /gsd:new-milestone creates the milestone.*
+*This file is temporary. It will be deleted after /gsd-new-milestone creates the milestone.*
 ```
 
 <guidelines>
@@ -73,11 +73,11 @@ Template for `.planning/MILESTONE-CONTEXT.md` - temporary handoff file from disc
 The file exists only to pass context from `discuss-milestone` to `create-milestone` across a `/clear` boundary.
 
 **Lifecycle:**
-1. `/gsd:discuss-milestone` creates this file at end of discussion
+1. `/gsd-discuss-milestone` creates this file at end of discussion
 2. User runs `/clear` (safe now - context is persisted)
-3. `/gsd:new-milestone` reads this file
-4. `/gsd:new-milestone` uses context to populate milestone
-5. `/gsd:new-milestone` deletes this file after successful creation
+3. `/gsd-new-milestone` reads this file
+4. `/gsd-new-milestone` uses context to populate milestone
+5. `/gsd-new-milestone` deletes this file after successful creation
 
 **Content should include:**
 - Features identified (the core of what to build)

package/get-shit-done/templates/phase-prompt.md

@@ -85,7 +85,7 @@ Output: [What artifacts will be created]
 </task>
 
 <task type="checkpoint:human-verify" gate="blocking">
-  <what-built>[What Claude just built that needs verification]</what-built>
+  <what-built>[What Opencode agent just built that needs verification]</what-built>
   <how-to-verify>
     1. Run: [command to start dev server/app]
     2. Visit: [URL to check]
@@ -132,7 +132,7 @@ After completion, create `.planning/phases/XX-name/{phase}-{plan}-SUMMARY.md`
 | `autonomous` | Yes | `true` if no checkpoints, `false` if has checkpoints |
 | `domain` | No | Domain skill if loaded (e.g., `next-js`) |
 
-**Wave is pre-computed:** Wave numbers are assigned during `/gsd:plan-phase`. Execute-phase reads `wave` directly from frontmatter and groups plans by wave number. No runtime dependency analysis needed.
+**Wave is pre-computed:** Wave numbers are assigned during `/gsd-plan-phase`. Execute-phase reads `wave` directly from frontmatter and groups plans by wave number. No runtime dependency analysis needed.
 
 ---
 
@@ -274,7 +274,7 @@ See `~/.config/opencode/get-shit-done/references/tdd.md` for TDD plan structure.
 
 | Type | Use For | Autonomy |
 |------|---------|----------|
-| `auto` | Everything Claude can do independently | Fully autonomous |
+| `auto` | Everything Opencode agent can do independently | Fully autonomous |
 | `checkpoint:human-verify` | Visual/functional verification | Pauses, returns to orchestrator |
 | `checkpoint:decision` | Implementation choices | Pauses, returns to orchestrator |
 | `checkpoint:human-action` | Truly unavoidable manual steps (rare) | Pauses, returns to orchestrator |
@@ -455,7 +455,7 @@ files_modified: [...]
 
 ## Guidelines
 
-- Always use XML structure for Claude parsing
+- Always use XML structure for Opencode agent parsing
 - Include `wave`, `depends_on`, `files_modified`, `autonomous` in every plan
 - Prefer vertical slices over horizontal layers
 - Only reference prior SUMMARYs when genuinely needed

package/get-shit-done/templates/project.md

@@ -147,7 +147,7 @@ PROJECT.md evolves throughout the project lifecycle.
 
 For existing codebases:
 
-1. **Map codebase first** via `/gsd:map-codebase`
+1. **Map codebase first** via `/gsd-map-codebase`
 
 2. **Infer Validated requirements** from existing code:
    - What does the codebase actually do?
@@ -179,6 +179,6 @@ See: .planning/PROJECT.md (updated [date])
 **Current focus:** [Current phase name]
 ```
 
-This ensures Claude reads current PROJECT.md context.
+This ensures Opencode agent reads current PROJECT.md context.
 
 </state_reference>

package/get-shit-done/templates/research.md

@@ -2,7 +2,7 @@
 
 Template for `.planning/phases/XX-name/{phase}-RESEARCH.md` - comprehensive ecosystem research before planning.
 
-**Purpose:** Document what Claude needs to know to implement a phase well - not just "which library" but "how do experts build this."
+**Purpose:** Document what Opencode agent needs to know to implement a phase well - not just "which library" but "how do experts build this."
 
 ---
 

package/get-shit-done/templates/state.md

@@ -127,7 +127,7 @@ Points to PROJECT.md for full context. Includes:
 - Current focus (which phase)
 - Last update date (triggers re-read if stale)
 
-Claude reads PROJECT.md directly for requirements, constraints, and decisions.
+Opencode agent reads PROJECT.md directly for requirements, constraints, and decisions.
 
 ### Current Position
 Where we are right now:
@@ -158,10 +158,10 @@ Updated after each plan completion.
 - Effort estimate if known
 - Helps phase planning identify what to address
 
-**Pending Todos:** Ideas captured via /gsd:add-todo
+**Pending Todos:** Ideas captured via /gsd-add-todo
 - Count of pending todos
 - Reference to .planning/todos/pending/
-- Brief list if few, count if many (e.g., "5 pending todos — see /gsd:check-todos")
+- Brief list if few, count if many (e.g., "5 pending todos — see /gsd-check-todos")
 
 **Blockers/Concerns:** From "Next Phase Readiness" sections
 - Issues that affect future work

package/get-shit-done/templates/uat-issues.md

@@ -2,7 +2,7 @@
 
 Template for `.planning/phases/XX-name/{phase}-{plan}-ISSUES.md` - phase-scoped issues discovered during user acceptance testing.
 
-**Purpose:** Capture issues found during /gsd:verify-work. Unlike global ISSUES.md (for deferred enhancements), this file tracks bugs and problems in specific delivered work.
+**Purpose:** Capture issues found during /gsd-verify-work. Unlike global ISSUES.md (for deferred enhancements), this file tracks bugs and problems in specific delivered work.
 
 **Location:** Same directory as the SUMMARY.md being tested.
 
@@ -15,7 +15,7 @@ Template for `.planning/phases/XX-name/{phase}-{plan}-ISSUES.md` - phase-scoped
 
 **Tested:** [date]
 **Source:** [path to SUMMARY.md that was tested]
-**Tester:** User via /gsd:verify-work
+**Tester:** User via /gsd-verify-work
 
 ## Open Issues
 
@@ -36,7 +36,7 @@ Template for `.planning/phases/XX-name/{phase}-{plan}-ISSUES.md` - phase-scoped
 
 ## Resolved Issues
 
-[Moved here after /gsd:plan-fix executes and fixes are verified]
+[Moved here after /gsd-plan-fix executes and fixes are verified]
 
 ### UAT-001: [Brief description]
 **Resolved:** [date] - Fixed in [phase]-[plan]-FIX.md
@@ -76,7 +76,7 @@ Template for `.planning/phases/XX-name/{phase}-{plan}-ISSUES.md` - phase-scoped
 
 **Tested:** 2025-01-15
 **Source:** .planning/phases/05-auth/05-02-SUMMARY.md
-**Tester:** User via /gsd:verify-work
+**Tester:** User via /gsd-verify-work
 
 ## Open Issues
 
@@ -119,7 +119,7 @@ Template for `.planning/phases/XX-name/{phase}-{plan}-ISSUES.md` - phase-scoped
 
 <guidelines>
 **When to create:**
-- First time /gsd:verify-work finds an issue for a plan
+- First time /gsd-verify-work finds an issue for a plan
 - One file per plan tested
 
 **Location:**
@@ -131,8 +131,8 @@ Template for `.planning/phases/XX-name/{phase}-{plan}-ISSUES.md` - phase-scoped
 - UAT ISSUES.md: Actual problems found during testing
 
 **Workflow:**
-1. /gsd:verify-work creates this file with issues
-2. /gsd:plan-fix reads this file and creates FIX.md plan
+1. /gsd-verify-work creates this file with issues
+2. /gsd-plan-fix reads this file and creates FIX.md plan
 3. After FIX.md executes, issues move to "Resolved" section
 4. File becomes historical record of what was found and fixed