gsd-opencode 1.4.15 → 1.5.2

package/get-shit-done/references/git-integration.md

@@ -231,14 +231,14 @@ Each plan produces 2-4 commits (tasks + metadata). Clear, granular, bisectable.
 ## Why Per-Task Commits?
 
 **Context engineering for AI:**
-- Git history becomes primary context source for future Claude sessions
+- Git history becomes primary context source for future OpenCode sessions
 - `git log --grep="{phase}-{plan}"` shows all work for a plan
 - `git diff <hash>^..<hash>` shows exact changes per task
 - Less reliance on parsing SUMMARY.md = more context for actual work
 
 **Failure recovery:**
 - Task 1 committed ✅, Task 2 failed ❌
-- Claude in next session: sees task 1 complete, can retry task 2
+- OpenCode in next session: sees task 1 complete, can retry task 2
 - Can `git reset --hard` to last successful task
 
 **Debugging:**
@@ -247,8 +247,8 @@ Each plan produces 2-4 commits (tasks + metadata). Clear, granular, bisectable.
 - Each commit is independently revertable
 
 **Observability:**
-- Solo developer + Claude workflow benefits from granular attribution
+- Solo developer + OpenCode workflow benefits from granular attribution
 - Atomic commits are git best practice
-- "Commit noise" irrelevant when consumer is Claude, not humans
+- "Commit noise" irrelevant when consumer is OpenCode, not humans
 
 </commit_strategy_rationale>

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.
+OpenCode-executable plans have a specific format that enables OpenCode 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 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 OpenCode-executable when OpenCode 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 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 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 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 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 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 already automated]
     [The ONE thing requiring human action]
   </instructions>
-  <verification>[What Claude can check afterward]</verification>
+  <verification>[What OpenCode can check afterward]</verification>
   <resume-signal>[How to continue]</resume-signal>
 </task>
 ```
@@ -208,11 +208,11 @@ 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 automates everything with CLI/API, stops only for truly unavoidable manual steps.
 </type>
 
 <type name="checkpoint:human-verify">
-**Human must verify Claude's work** - Visual checks, UX testing.
+**Human must verify OpenCode's work** - Visual checks, UX testing.
 
 **Structure:**
 
@@ -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 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 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 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 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 CAN automate it, OpenCode 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 needs to understand before implementing.
 
 **Anti-pattern:** Reflexive chaining (02 refs 01, 03 refs 02). Only reference what you actually need.
 </context_references>
@@ -401,7 +401,7 @@ After completion, create `.planning/phases/XX-name/{phase}-{plan}-SUMMARY.md`
 </task>
 ```
 
-Claude: "How? What type? What library? Where?"
+OpenCode: "How? What type? What library? Where?"
 </too_vague>
 
 <just_right>
@@ -416,7 +416,7 @@ Claude: "How? What type? What library? Where?"
 </task>
 ```
 
-Claude can implement this immediately.
+OpenCode 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 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 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 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 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

@@ -1,14 +1,14 @@
 <principles>
 Core principles for the Gets Shit Done planning system.
 
-<solo_developer_claude>
+<solo_developer_opencode>
 
-You are planning for ONE person (the user) and ONE implementer (Claude).
+You are planning for ONE person (the user) and ONE implementer (OpenCode).
 - 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
-</solo_developer_claude>
+- OpenCode is the builder
+- Estimate effort in OpenCode execution time, not human dev time
+</solo_developer_opencode>
 
 <plans_are_prompts>
 
@@ -47,20 +47,20 @@ Plans must complete within reasonable context usage.
 - Better to have many small plans than few large ones
 </scope_control>
 
-<claude_automates>
+<opencode_automates>
 
-If Claude CAN do it via CLI/API/tool, Claude MUST do it.
+If OpenCode CAN do it via CLI/API/tool, OpenCode MUST do it.
 
 Checkpoints are for:
-- **Verification** - Human confirms Claude's work (visual, UX)
+- **Verification** - Human confirms OpenCode's work (visual, UX)
 - **Decision** - Human makes implementation choice
 
 Not for:
 - Deploying (use CLI)
 - Creating resources (use CLI/API)
-- Running builds/tests (use Bash)
-- Writing files (use Write tool)
-</claude_automates>
+- Running builds/tests (use bash tool)
+- Writing files (use write/edit tools)
+</opencode_automates>
 
 <deviation_rules>
 
@@ -121,7 +121,7 @@ Milestones mark shipped versions (v1.0 → v1.1 → v2.0).
 
 <atomic_commits>
 
-**Git commits = context engineering for Claude.**
+**Git commits = context engineering for OpenCode.**
 
 Each task gets its own commit immediately after completion:
 - Format: `{type}({phase}-{plan}): {task-description}`
@@ -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 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 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 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 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,16 +2,16 @@
 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 degrades when it *perceives* context pressure and enters "completion mode."
 
-| Context Usage | Quality | Claude's State |
+| Context Usage | Quality | OpenCode's State |
 |---------------|---------|----------------|
 | 0-30% | PEAK | Thorough, comprehensive |
 | 30-50% | GOOD | Confident, solid work |
 | 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 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

@@ -32,7 +32,7 @@ reproduction: [how to trigger]
 started: [when it broke / always broken]
 
 ## Eliminated
-<!-- APPEND only - prevents re-investigating after /clear -->
+<!-- APPEND only - prevents re-investigating after /new -->
 
 - hypothesis: [theory that was wrong]
   evidence: [what disproved it]
@@ -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 is doing RIGHT NOW
+- If OpenCode reads this after /new, it knows exactly where to resume
 - Fields: hypothesis, test, expecting, next_action
 
 **Symptoms:**
@@ -81,7 +81,7 @@ files_changed: []
 - APPEND only - never remove entries
 - Prevents re-investigating dead ends after context reset
 - Each entry: hypothesis, evidence that disproved it, timestamp
-- Critical for efficiency across /clear boundaries
+- Critical for efficiency across /new boundaries
 
 **Evidence:**
 - APPEND only - never remove entries
@@ -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 reads this file after /new:
 
 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 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 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 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 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 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 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 reads the code)
+- Technical risks (OpenCode identifies during research)
+- Implementation constraints (OpenCode figures out)
+- Success metrics (OpenCode 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 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 `/new` 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,20 +64,20 @@ 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>
 **This is a handoff artifact, not permanent documentation.**
 
-The file exists only to pass context from `discuss-milestone` to `create-milestone` across a `/clear` boundary.
+The file exists only to pass context from `discuss-milestone` to `create-milestone` across a `/new` boundary.
 
 **Lifecycle:**
-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
+1. `/gsd-discuss-milestone` creates this file at end of discussion
+2. User runs `/new` (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
 
 **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 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 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 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 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 needs to know to implement a phase well - not just "which library" but "how do experts build this."
 
 ---
 
@@ -501,7 +501,7 @@ function useVehicleControls(rigidBodyRef) {
 
 **When to create:**
 - Before planning phases in niche/complex domains
-- When Claude's training data is likely stale or sparse
+- When OpenCode's training data is likely stale or sparse
 - When "how do experts do this" matters more than "which library"
 
 **Structure:**

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