gsd-opencode 1.5.0 → 1.5.2

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
-- Opencode agent is the builder
-- Estimate effort in Opencode agent 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 Opencode agent CAN do it via CLI/API/tool, Opencode agent 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 Opencode agent 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—Opencode agent 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 — Opencode agent 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. Opencode agent 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/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>
-Opencode agent 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:** Opencode agent 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 Opencode agent is doing RIGHT NOW
-- If Opencode agent 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
@@ -135,7 +135,7 @@ files_changed: []
 
 <resume_behavior>
 
-When Opencode agent 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 Opencode agent reads this file after /clear:
 4. Read Evidence → know what's been learned
 5. Continue from next_action
 
-The file IS the debugging brain. Opencode agent 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/checkpoint-return.md

@@ -63,7 +63,7 @@ Type "approved" or describe issues to fix.
 ### Checkpoint Details
 
 **Automation attempted:**
-[What Opencode agent 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 Opencode agent 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 Opencode agent 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 Opencode agent 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 Opencode agent 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 (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)
+- 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 Opencode agent 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/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.
 
 ---
 
@@ -70,11 +70,11 @@ Template for `.planning/MILESTONE-CONTEXT.md` - temporary handoff file from disc
 <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)
+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

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 Opencode agent 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]
@@ -274,7 +274,7 @@ See `~/.config/opencode/get-shit-done/references/tdd.md` for TDD plan structure.
 
 | Type | Use For | Autonomy |
 |------|---------|----------|
-| `auto` | Everything Opencode agent 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 Opencode agent 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

@@ -179,6 +179,6 @@ See: .planning/PROJECT.md (updated [date])
 **Current focus:** [Current phase name]
 ```
 
-This ensures Opencode agent 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 Opencode agent 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)
 
-Opencode agent 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:

package/get-shit-done/workflows/_archive/execute-phase.md

@@ -844,7 +844,7 @@ All {N} plans finished via parallel execution.
 
 `/gsd-plan-phase {X+1}`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 

package/get-shit-done/workflows/complete-milestone.md

@@ -575,7 +575,7 @@ Tag: v[X.Y]
 
 `/gsd-discuss-milestone`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 

package/get-shit-done/workflows/create-milestone.md

@@ -368,7 +368,7 @@ Milestone v[X.Y] [Name] created:
 
 `/gsd-plan-phase [N]`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 

package/get-shit-done/workflows/create-roadmap.md

@@ -386,7 +386,7 @@ Resume file: None
 **Key points:**
 
 - Project Reference points to PROJECT.md for full context
-- Opencode agent reads PROJECT.md directly for requirements, constraints, decisions
+- OpenCode reads PROJECT.md directly for requirements, constraints, decisions
 - This file will be read first in every future operation
 - This file will be updated after every execution
 
@@ -432,7 +432,7 @@ Project initialized:
 
 `/gsd-plan-phase 1`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 

package/get-shit-done/workflows/debug.md

@@ -5,7 +5,7 @@ You are the debugger. The user knows what's wrong (behavior), not why (root caus
 </purpose>
 
 <philosophy>
-**User = reporter. Opencode agent = investigator.**
+**User = reporter. OpenCode = investigator.**
 
 The user knows:
 - What they expected to happen
@@ -281,7 +281,7 @@ If ELIMINATED:
 
 After significant investigation (5+ evidence entries), check if context is heavy.
 If so, ensure Current Focus is fully updated and suggest:
-"Context filling up. Safe to /clear - run /gsd-debug to resume."
+"Context filling up. Safe to /new - run /gsd-debug to resume."
 </step>
 
 <step name="resume_from_file">
@@ -420,7 +420,7 @@ Use question:
 - [ ] Current Focus always reflects NOW
 - [ ] Evidence appended for every finding
 - [ ] Eliminated prevents re-investigation
-- [ ] Can resume perfectly from any /clear
+- [ ] Can resume perfectly from any /new
 - [ ] Root cause confirmed with evidence before fixing
 - [ ] Fix verified against original symptoms
 </success_criteria>

package/get-shit-done/workflows/discovery-phase.md

@@ -22,7 +22,7 @@ NOTE: For comprehensive ecosystem research ("how do experts build this"), use /g
 <source_hierarchy>
 **MANDATORY: Context7 BEFORE WebSearch**
 
-Claude's training data is 6-18 months stale. Always verify.
+OpenCode's training data is 6-18 months stale. Always verify.
 
 1. **Context7 MCP FIRST** - Current docs, no hallucination
 2. **Official docs** - When Context7 lacks coverage

package/get-shit-done/workflows/discuss-milestone.md

@@ -216,7 +216,7 @@ Context saved to `.planning/MILESTONE-CONTEXT.md`
 
 `/gsd-new-milestone`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 ```

package/get-shit-done/workflows/discuss-phase.md

@@ -5,7 +5,7 @@ You are a thinking partner, not an interviewer. The user is the visionary — yo
 </purpose>
 
 <philosophy>
-**User = founder/visionary. Opencode agent = builder.**
+**User = founder/visionary. OpenCode = builder.**
 
 The user doesn't know (and shouldn't need to know):
 - Codebase patterns (you read the code)
@@ -192,7 +192,7 @@ Created: .planning/phases/${PHASE}-${SLUG}/${PHASE}-CONTEXT.md
 
 `/gsd-plan-phase ${PHASE}`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 

package/get-shit-done/workflows/execute-phase.md

@@ -316,7 +316,7 @@ Present next steps based on milestone status:
 
 `/gsd-plan-phase {X+1}`
 
-*`/clear` first for fresh context*
+*`/new` first for fresh context*
 ```
 
 **If milestone complete:**

package/get-shit-done/workflows/execute-plan.md

@@ -1069,7 +1069,7 @@ TASK_COMMITS+=("Task ${TASK_NUM}: ${TASK_COMMIT}")
 - Each task independently revertable
 - Git bisect finds exact failing task
 - Git blame traces line to specific task context
-- Clear history for Opencode agent in future sessions
+- Clear history for OpenCode in future sessions
 - Better observability for AI-automated workflow
 
 </task_commit>
@@ -1077,7 +1077,7 @@ TASK_COMMITS+=("Task ${TASK_NUM}: ${TASK_COMMIT}")
 <step name="checkpoint_protocol">
 When encountering `type="checkpoint:*"`:
 
-**Critical: Opencode agent automates everything with CLI/API before checkpoints.** Checkpoints are for verification and decisions, not manual work.
+**Critical: OpenCode automates everything with CLI/API before checkpoints.** Checkpoints are for verification and decisions, not manual work.
 
 **Display checkpoint clearly:**
 
@@ -1129,7 +1129,7 @@ Options:
 **For checkpoint:human-action (1% - rare, only for truly unavoidable manual steps):**
 
 ```
-I automated: [what Opencode agent already did via CLI/API]
+I automated: [what OpenCode already did via CLI/API]
 
 Need your help with: [the ONE thing with no CLI/API - email link, 2FA code]
 
@@ -1685,7 +1685,7 @@ Summary: .planning/phases/{phase-dir}/{phase}-{plan}-SUMMARY.md
 
 `/gsd-execute-plan .planning/phases/{phase-dir}/{phase}-{next-plan}-PLAN.md`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 
@@ -1746,7 +1746,7 @@ All {Y} plans finished.
 
 `/gsd-plan-phase {Z+1}`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 
@@ -1786,7 +1786,7 @@ Milestone is 100% done.
 
 `/gsd-complete-milestone`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 

package/get-shit-done/workflows/list-phase-assumptions.md

@@ -1,7 +1,7 @@
 <purpose>
-Surface Claude's assumptions about a phase before planning, enabling users to correct misconceptions early.
+Surface OpenCode's assumptions about a phase before planning, enabling users to correct misconceptions early.
 
-Key difference from discuss-phase: This is ANALYSIS of what Opencode agent thinks, not INTAKE of what user knows. No file output - purely conversational to prompt discussion.
+Key difference from discuss-phase: This is ANALYSIS of what OpenCode thinks, not INTAKE of what user knows. No file output - purely conversational to prompt discussion.
 </purpose>
 
 <process>
@@ -53,31 +53,31 @@ Continue to analyze_phase.
 Based on roadmap description and project context, identify assumptions across five areas:
 
 **1. Technical Approach:**
-What libraries, frameworks, patterns, or tools would Opencode agent use?
+What libraries, frameworks, patterns, or tools would OpenCode use?
 - "I'd use X library because..."
 - "I'd follow Y pattern because..."
 - "I'd structure this as Z because..."
 
 **2. Implementation Order:**
-What would Opencode agent build first, second, third?
+What would OpenCode build first, second, third?
 - "I'd start with X because it's foundational"
 - "Then Y because it depends on X"
 - "Finally Z because..."
 
 **3. Scope Boundaries:**
-What's included vs excluded in Claude's interpretation?
+What's included vs excluded in OpenCode's interpretation?
 - "This phase includes: A, B, C"
 - "This phase does NOT include: D, E, F"
 - "Boundary ambiguities: G could go either way"
 
 **4. Risk Areas:**
-Where does Opencode agent expect complexity or challenges?
+Where does OpenCode expect complexity or challenges?
 - "The tricky part is X because..."
 - "Potential issues: Y, Z"
 - "I'd watch out for..."
 
 **5. Dependencies:**
-What does Opencode agent assume exists or needs to be in place?
+What does OpenCode assume exists or needs to be in place?
 - "This assumes X from previous phases"
 - "External dependencies: Y, Z"
 - "This will be consumed by..."

package/get-shit-done/workflows/map-codebase.md

@@ -15,7 +15,7 @@ Each agent has fresh context and focuses on specific aspects. Output is concise
 Include enough detail to be useful as reference. Prioritize practical examples (especially code patterns) over arbitrary brevity. A 200-line TESTING.md with real patterns is more valuable than a 74-line summary.
 
 **Always include file paths:**
-Documents are reference material for Opencode agent when planning/executing. Vague descriptions like "UserService handles users" are not actionable. Always include actual file paths formatted with backticks: `src/services/user.ts`. This allows Opencode agent to navigate directly to relevant code without re-searching. Do NOT include line numbers (they go stale), just file paths.
+Documents are reference material for OpenCode when planning/executing. Vague descriptions like "UserService handles users" are not actionable. Always include actual file paths formatted with backticks: `src/services/user.ts`. This allows OpenCode to navigate directly to relevant code without re-searching. Do NOT include line numbers (they go stale), just file paths.
 </philosophy>
 
 <process>
@@ -405,7 +405,7 @@ Created .planning/codebase/:
 
 `/gsd-new-project`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 

package/get-shit-done/workflows/plan-phase.md

@@ -32,7 +32,7 @@ Decimal phases enable urgent work insertion without renumbering:
 <purpose>
 Create executable phase prompts (PLAN.md files) optimized for parallel execution.
 
-PLAN.md IS the prompt that Opencode agent executes. Plans are grouped into execution waves based on dependencies - independent plans run in parallel, dependent plans wait for predecessors.
+PLAN.md IS the prompt that OpenCode executes. Plans are grouped into execution waves based on dependencies - independent plans run in parallel, dependent plans wait for predecessors.
 </purpose>
 
 <planning_principles>
@@ -645,7 +645,7 @@ Wave 2: {plan-03}
 
 `/gsd-execute-phase {X}`
 
-*`/clear` first - fresh context window*
+*`/new` first - fresh context window*
 
 ---
 
@@ -679,7 +679,7 @@ If you can't specify Files + Action + Verify + Done, the task is too vague.
 - No acceptance criteria committees
 - No sub-sub-sub tasks
 - **No reflexive sequential chaining** (Plan 02 depends on 01 "just because")
-Tasks are instructions for Claude, not Jira tickets.
+Tasks are instructions for OpenCode, not Jira tickets.
 </anti_patterns>
 
 <success_criteria>