gsd-opencode 1.5.0 → 1.5.2

package/command/gsd/add-phase.md

@@ -174,7 +174,7 @@ Project state updated: .planning/STATE.md
 
 `/gsd-plan-phase {N}`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 

package/command/gsd/add-todo.md

@@ -110,7 +110,7 @@ files:
 
 ## Problem
 
-[problem description - enough context for future Opencode agent to understand weeks later]
+[problem description - enough context for future OpenCode to understand weeks later]
 
 ## Solution
 
@@ -176,7 +176,7 @@ Would you like to:
 <success_criteria>
 - [ ] Directory structure exists
 - [ ] Todo file created with valid frontmatter
-- [ ] Problem section has enough context for future Claude
+- [ ] Problem section has enough context for future OpenCode
 - [ ] No duplicates (checked and resolved)
 - [ ] Area consistent with existing todos
 - [ ] STATE.md updated if exists

package/command/gsd/create-roadmap.md

@@ -85,7 +85,7 @@ Roadmap created:
 
 `/gsd-plan-phase 1`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 

package/command/gsd/debug.md

@@ -13,7 +13,7 @@ allowed-tools:
 ---
 
 <objective>
-Debug issues using scientific method with a persistent debug document that survives `/clear`.
+Debug issues using scientific method with a persistent debug document that survives `/new`.
 
 If resuming (no arguments and active session exists): pick up where you left off.
 If starting new: gather symptoms, then investigate autonomously.
@@ -45,7 +45,7 @@ Follow the workflow in @~/.config/opencode/get-shit-done/workflows/debug.md
 5. **Fix and verify** - Minimal fix, verify against original symptoms
 6. **Archive** - Move to `.planning/debug/resolved/`
 
-**Key principle:** The DEBUG.md is your memory. Update it constantly. It survives `/clear`.
+**Key principle:** The DEBUG.md is your memory. Update it constantly. It survives `/new`.
 </process>
 
 <success_criteria>

package/command/gsd/help.md

@@ -247,7 +247,7 @@ Systematic debugging with persistent state across context resets.
 - Gathers symptoms through adaptive questioning
 - Creates `.planning/debug/[slug].md` to track investigation
 - Investigates using scientific method (evidence → hypothesis → test)
-- Survives `/clear` — run `/gsd-debug` with no args to resume
+- Survives `/new` — run `/gsd-debug` with no args to resume
 - Archives resolved issues to `.planning/debug/resolved/`
 
 Usage: `/gsd-debug "login button doesn't work"`
@@ -379,7 +379,7 @@ Change anytime by editing `.planning/config.json`
 ```
 /gsd-debug "form submission fails silently"  # Start debug session
 # ... investigation happens, context fills up ...
-/clear
+/new
 /gsd-debug                                    # Resume from where you left off
 ```
 

package/command/gsd/insert-phase.md

@@ -191,7 +191,7 @@ Project state updated: .planning/STATE.md
 
 `/gsd-plan-phase {decimal_phase}`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 

package/command/gsd/new-project.md

@@ -57,7 +57,7 @@ Creates `.planning/` with PROJECT.md and config.json.
    HAS_CODEBASE_MAP=$([ -d .planning/codebase ] && echo "yes")
    ```
 
-   **You MUST run all bash commands above using the Bash tool before proceeding.**
+   **You MUST run all bash commands above using the bash tool before proceeding.**
 
 </step>
 
@@ -307,7 +307,7 @@ Project initialized:
 
 `/gsd-create-roadmap`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 ```

package/command/gsd/pause-work.md

@@ -86,7 +86,7 @@ Start with: [specific first action when resuming]
 </next_action>
 ```
 
-Be specific enough for a fresh Opencode agent to understand immediately.
+Be specific enough for a fresh OpenCode to understand immediately.
 </step>
 
 <step name="commit">

package/command/gsd/progress.md

@@ -149,7 +149,7 @@ Read its `<objective>` section.
 
 `/gsd-execute-plan [full-path-to-PLAN.md]`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 ```
@@ -172,7 +172,7 @@ Check if `{phase}-CONTEXT.md` exists in phase directory.
 
 `/gsd-plan-phase {phase-number}`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 ```
@@ -188,7 +188,7 @@ Check if `{phase}-CONTEXT.md` exists in phase directory.
 
 `/gsd-plan-phase {phase}`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 
@@ -215,7 +215,7 @@ ISSUES.md exists without matching FIX.md. User needs to plan fixes.
 
 `/gsd-plan-fix {plan}`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 
@@ -262,7 +262,7 @@ Read ROADMAP.md to get the next phase's name and goal.
 
 `/gsd-plan-phase {Z+1}`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 
@@ -291,7 +291,7 @@ All {N} phases finished!
 
 `/gsd-complete-milestone`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 

package/command/gsd/status.md

@@ -110,7 +110,7 @@ All parallel agents finished. Review results:
 
 `/gsd-progress`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 ```

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

@@ -1,21 +1,21 @@
 <overview>
 Plans execute autonomously. Checkpoints formalize interaction points where human verification or decisions are needed.
 
-**Core principle:** Opencode agent automates everything with CLI/API. Checkpoints are for verification and decisions, not manual work.
+**Core principle:** OpenCode automates everything with CLI/API. Checkpoints are for verification and decisions, not manual work.
 </overview>
 
 <checkpoint_types>
 
 ## checkpoint:human-verify (90% of checkpoints)
 
-**When:** Opencode agent completed automated work, human confirms it works correctly.
+**When:** OpenCode completed automated work, human confirms it works correctly.
 
 **Use for:** Visual UI checks, interactive flows, functional verification, audio/video quality, animation smoothness, accessibility testing.
 
 **Structure:**
 ```xml
 <task type="checkpoint:human-verify" gate="blocking">
-  <what-built>[What Opencode agent automated]</what-built>
+  <what-built>[What OpenCode automated]</what-built>
   <how-to-verify>[Numbered steps - URLs, commands, expected behavior]</how-to-verify>
   <resume-signal>[How to continue - "approved" or describe issues]</resume-signal>
 </task>
@@ -80,14 +80,14 @@ Plans execute autonomously. Checkpoints formalize interaction points where human
 
 **Use ONLY for:** Email verification links, SMS 2FA codes, manual account approvals, 3D Secure payment flows, OAuth app approvals.
 
-**Do NOT use for:** Deployments (use CLI), creating resources (use CLI/API), builds/tests (use Bash), file operations (use Write/Edit).
+**Do NOT use for:** Deployments (use CLI), creating resources (use CLI/API), builds/tests (use bash tool), file operations (use write/edit tools).
 
 **Structure:**
 ```xml
 <task type="checkpoint:human-action" gate="blocking">
   <action>[Unavoidable manual step]</action>
-  <instructions>[What Opencode agent automated] [ONE thing requiring human action]</instructions>
-  <verification>[What Opencode agent checks afterward]</verification>
+  <instructions>[What OpenCode automated] [ONE thing requiring human action]</instructions>
+  <verification>[What OpenCode checks afterward]</verification>
   <resume-signal>[How to continue]</resume-signal>
 </task>
 ```
@@ -109,7 +109,7 @@ Plans execute autonomously. Checkpoints formalize interaction points where human
 
 <execution_protocol>
 
-When Opencode agent encounters `type="checkpoint:*"`:
+When OpenCode encounters `type="checkpoint:*"`:
 
 1. **Stop immediately** - do not proceed to next task
 2. **Display checkpoint clearly:**
@@ -135,9 +135,9 @@ Task [X] of [Y]: [Name]
 
 <authentication_gates>
 
-**Critical:** When Opencode agent tries CLI/API and gets auth error, this is NOT a failure - it's a gate requiring human input to unblock automation.
+**Critical:** When OpenCode tries CLI/API and gets auth error, this is NOT a failure - it's a gate requiring human input to unblock automation.
 
-**Pattern:** Opencode agent tries automation → auth error → creates checkpoint → you authenticate → Opencode agent retries → continues
+**Pattern:** OpenCode tries automation → auth error → creates checkpoint → you authenticate → OpenCode retries → continues
 
 **Gate protocol:**
 1. Recognize it's not a failure - missing auth is expected
@@ -150,7 +150,7 @@ Task [X] of [Y]: [Name]
 
 **Example (Vercel auth gate):**
 ```xml
-<!-- Opencode agent tries to deploy -->
+<!-- OpenCode tries to deploy -->
 <task type="auto">
   <name>Deploy to Vercel</name>
   <action>Run `vercel --yes` to deploy</action>
@@ -167,7 +167,7 @@ Task [X] of [Y]: [Name]
   <resume-signal>Type "done" when authenticated</resume-signal>
 </task>
 
-<!-- After auth, Opencode agent retries automatically -->
+<!-- After auth, OpenCode retries automatically -->
 <task type="auto">
   <name>Retry deployment</name>
   <action>Run `vercel --yes` (now authenticated)</action>
@@ -175,14 +175,14 @@ Task [X] of [Y]: [Name]
 ```
 
 **Key distinction:**
-- Pre-planned checkpoint: "I need you to do X" (wrong - Opencode agent should automate)
+- Pre-planned checkpoint: "I need you to do X" (wrong - OpenCode should automate)
 - Auth gate: "I tried to automate X but need credentials" (correct - unblocks automation)
 
 </authentication_gates>
 
 <automation_reference>
 
-**The rule:** If it has CLI/API, Opencode agent does it. Never ask human to perform automatable work.
+**The rule:** If it has CLI/API, OpenCode does it. Never ask human to perform automatable work.
 
 | Service | CLI/API | Key Commands | Auth Gate |
 |---------|---------|--------------|-----------|
@@ -197,15 +197,15 @@ Task [X] of [Y]: [Name]
 | Node | `npm`/`pnpm` | `install`, `run build`, `test` | N/A |
 | Xcode | `xcodebuild` | `-project`, `-scheme`, `build`, `test` | N/A |
 
-**Env files:** Use Write/Edit tools. Never ask human to create .env manually.
+**Env files:** Use write/edit tools. Never ask human to create .env manually.
 
 **Quick reference:**
 
-| Action | Automatable? | Opencode agent does it? |
+| Action | Automatable? | OpenCode does it? |
 |--------|--------------|-----------------|
 | Deploy to Vercel | Yes (`vercel`) | YES |
 | Create Stripe webhook | Yes (API) | YES |
-| Write .env file | Yes (Write tool) | YES |
+| Write .env file | Yes (write/edit tools) | YES |
 | Create Upstash DB | Yes (`upstash`) | YES |
 | Run tests | Yes (`npm test`) | YES |
 | Click email verification link | No | NO |
@@ -223,7 +223,7 @@ Task [X] of [Y]: [Name]
 - Make verification executable
 
 **DON'T:**
-- Ask human to do work Opencode agent can automate
+- Ask human to do work OpenCode can automate
 - Assume knowledge: "Configure the usual settings"
 - Mix multiple verifications in one checkpoint
 - Use checkpoints too frequently (verification fatigue)
@@ -256,7 +256,7 @@ Why bad: Vercel has CLI. Use `vercel --yes`.
 ```
 Why bad: Verification fatigue. Combine into one checkpoint at end.
 
-**GOOD: Opencode agent automates, human verifies once**
+**GOOD: OpenCode automates, human verifies once**
 ```xml
 <task type="auto">Create schema</task>
 <task type="auto">Create API</task>
@@ -272,16 +272,16 @@ Why bad: Verification fatigue. Combine into one checkpoint at end.
 
 <summary>
 
-**The golden rule:** If Opencode agent CAN automate it, Opencode agent MUST automate it.
+**The golden rule:** If OpenCode CAN automate it, OpenCode MUST automate it.
 
 **Checkpoint priority:**
-1. **checkpoint:human-verify** (90%) - Opencode agent automated, human confirms visual/functional correctness
+1. **checkpoint:human-verify** (90%) - OpenCode automated, human confirms visual/functional correctness
 2. **checkpoint:decision** (9%) - Human makes architectural/technology choices
 3. **checkpoint:human-action** (1%) - Truly unavoidable manual steps with no API/CLI
 
 **When NOT to use checkpoints:**
-- Things Opencode agent can verify programmatically (tests, builds)
-- File operations (Opencode agent can read/write)
+- Things OpenCode can verify programmatically (tests, builds)
+- File operations (OpenCode can read/write)
 - Anything with CLI/API available
 
 </summary>

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

@@ -13,7 +13,7 @@ Standard format for presenting next steps after completing a command or workflow
 
 `{command to copy-paste}`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 
@@ -29,7 +29,7 @@ Standard format for presenting next steps after completing a command or workflow
 1. **Always show what it is** — name + description, never just a command path
 2. **Pull context from source** — ROADMAP.md for phases, PLAN.md `<objective>` for plans
 3. **Command in inline code** — backticks, easy to copy-paste, renders as clickable link
-4. **`/clear` explanation** — always include, keeps it concise but explains why
+4. **`/new` explanation** — always include, keeps it concise but explains why
 5. **"Also available" not "Other options"** — sounds more app-like
 6. **Visual separators** — `---` above and below to make it stand out
 
@@ -46,7 +46,7 @@ Standard format for presenting next steps after completing a command or workflow
 
 `/gsd-execute-plan .planning/phases/02-auth/02-03-PLAN.md`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 
@@ -71,7 +71,7 @@ Add note that this is the last plan and what comes after:
 
 `/gsd-execute-plan .planning/phases/02-auth/02-03-PLAN.md`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 
@@ -93,7 +93,7 @@ Add note that this is the last plan and what comes after:
 
 `/gsd-plan-phase 2`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 
@@ -122,7 +122,7 @@ Show completion status before next action:
 
 `/gsd-plan-phase 3`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 
@@ -151,7 +151,7 @@ When there's no clear primary action:
 
 **To research unknowns:** `/gsd-research-phase 3`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 ```
@@ -171,7 +171,7 @@ All 4 phases shipped
 
 `/gsd-discuss-milestone`
 
-*`/clear` first → fresh context window*
+*`/new` first → fresh context window*
 
 ---
 
@@ -219,18 +219,18 @@ Extract: `**02-03: Refresh Token Rotation** — Add /api/auth/refresh with slidi
 ```
 ## To Continue
 
-Run `/clear`, then paste:
+Run `/new`, then paste:
 /gsd-execute-plan .planning/phases/02-auth/02-03-PLAN.md
 ```
 
 User has no idea what 02-03 is about.
 
-### Don't: Missing /clear explanation
+### Don't: Missing /new explanation
 
 ```
 `/gsd-plan-phase 3`
 
-Run /clear first.
+Run /new first.
 ```
 
 Doesn't explain why. User might skip it.

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 Opencode agent 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 ❌
-- Opencode agent 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 + Opencode agent 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 Opencode agent 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 Opencode agent 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 Opencode agent 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 Opencode agent 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>
@@ -88,7 +88,7 @@ Output: [...]
 </task>
 
 <task type="checkpoint:human-verify" gate="blocking">
-  <what-built>[what Opencode agent 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** - Opencode agent 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 Opencode agent 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. Opencode agent 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 Opencode agent can do independently (code, tests, builds, fi
 <task type="checkpoint:human-action" gate="blocking">
   <action>[Unavoidable manual step - email link, 2FA code]</action>
   <instructions>
-    [What Opencode agent already automated]
+    [What OpenCode already automated]
     [The ONE thing requiring human action]
   </instructions>
-  <verification>[What Opencode agent 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:** Opencode agent 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:** Opencode agent 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:** Opencode agent 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 Opencode agent 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 (Opencode agent 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 Opencode agent CAN automate it, Opencode agent 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 Opencode agent 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>
 ```
 
-Opencode agent 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 Opencode agent 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 Opencode agent to implement from clea
 - "Make it production-ready"
 - "Add proper error handling"
 
-These require Opencode agent 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"
 
-Opencode agent 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 Opencode agent 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)