opencode-delegate

name

opencode-delegate

description

Delegate a coding task directly to OpenCode without a planning phase. **Trigger this skill whenever the user's request starts with or contains a direct delegation verb** — "delegate to opencode", "delegate this to opencode", "use opencode to X", "have opencode do X", "just use opencode", "run this through opencode", "ask opencode to X", "hand this to opencode" — REGARDLESS of how large or complex the task itself is. The user's explicit instruction to delegate is authoritative; do not second-guess it based on task size, scope, or complexity. Also trigger when the user names a specific OpenCode-supported model (GLM-5.1, GPT-5, Gemini, Kimi, DeepSeek, Claude via opencode, local Ollama) and asks to use it. If the user wants Claude to plan first before delegating ("plan and implement", "plan this and then delegate", "design first then implement", "think through the approach"), use the `opencode-implement` skill instead — but only if the user's phrasing explicitly asks for planning. "Delegate" without "plan" means direct delegation, even for big tasks.

opencode-delegate

Run a coding task through OpenCode immediately, without writing a plan first. Claude still handles model selection, permissions, and verification — but skips the plan-then-approve gate.

This skill is for direct delegation. If the user wants Claude to plan the work first and get approval before delegating, use opencode-implement instead.

When to use this skill

• The user uses a direct delegation verb: "delegate to opencode", "use opencode to X", "have opencode do X", "run this through opencode", "ask opencode to X", "hand this to opencode", "just use opencode".
• Task size doesn't matter for this decision. "Delegate to opencode and add 12 features" still triggers this skill, because the user said "delegate." Trust the user's verb.
• The user names a specific OpenCode model and gives a concrete task.
• The user phrases the task as a direct command rather than a planning request.

When NOT to use this skill

• The user explicitly asks to plan first: "plan and implement", "plan and delegate", "design first", "think through the approach" → use opencode-implement.
• The task has no clear scope and the user is asking what to do, not how to do it → that's a conversation, not a delegation.
• When opencode isn't installed — stop and direct the user to install.

Note on large tasks: If the user says "delegate" but the work seems substantial enough that planning would help, you can briefly mention this once after triggering — "this is a sizable task; would you prefer to plan first via opencode-implement?" — but only as an optional suggestion. If the user confirms direct delegation or doesn't address the suggestion, proceed with this skill. Don't override the user's verb.

---

Interaction rules

Use AskUserQuestion for every decision point. One decision per call. Do not batch questions as prose.

Decision points, in order:

1. Model selection — authed models as options plus "Other".
2. Permission selection — "Read-only", "Implement", "Implement, no shell".

Wait for each answer before asking the next. Don't combine them into one message.

---

Preflight — required, not optional

Run these two bash commands before anything else, every delegation:

opencode --version
opencode auth list

This is mandatory. The output of opencode auth list is what drives model selection — without it, you don't know which models the user is authed for, and any model list you present from memory is wrong.

See references/preflight.md for full details and references/model-selection.md for how to build the actual model list from the auth output.

Failure modes to avoid:

• Hardcoded marketing list: "GPT-5 (Recommended) / GLM-5.1 / Claude Sonnet" — that's training-data marketing, not the user's actual options.
• Editorial commentary in options: "opencode/big-pickle — Largest available", "opencode/gpt-5-nano — may struggle", "opencode/minimax-m2.5-free — Free-tier alternative". Each option must be just the literal provider/model string, no description, no recommendation, no speculation about behavior.
• Truncated lists from a stale cache: if opencode models returns only a handful when more should be available, run opencode models --refresh and retry. If still short, try OPENCODE_ENABLE_EXPERIMENTAL_MODELS=true opencode models.
• Querying a single provider: never use opencode models <provider>. Use opencode models with no argument. Some providers expose models under multiple provider IDs (e.g., opencode and opencode-go are separate, but a single subscription can give access to both), so querying just one ID hides models the user actually has.
• Showing models from non-authed providers: if the user only authed opencode, don't pad the list with anthropic/... or openai/... options they can't use.

If you catch yourself doing any of these, stop and re-read references/model-selection.md.

---

The delegation flow

Step 1: Confirm scope (only if needed)

For most direct delegations the user's message is already the prompt. If the task is truly clear — "have opencode fix the typo in src/login.tsx line 42" — go straight to step 2.

If the task seems to need a specific file attached but the user hasn't named it, check the repo quickly (1-2 Grep/Read calls) to identify the file. Don't do deep exploration — this skill is about speed. If scope is genuinely unclear, ask one short clarifying question before proceeding, or suggest the user might want opencode-implement (planning) instead.

Step 2: Ask for model

See references/model-selection.md — but only after running opencode models (no provider argument) via bash_tool. The model list MUST come from that bash output, not from memory. Single AskUserQuestion call. Wait for the answer.

Step 3: Ask for permissions

See references/permissions.md for the three presets. Single AskUserQuestion call. Wait for the answer.

For direct delegation, the natural default is "Implement" unless the user's phrasing suggests otherwise ("just show me what it would do" → read-only).

Step 4: Run opencode

Construct and run the command per references/argument-order.md.

Pattern:

OPENCODE_PERMISSION='<preset JSON>' \
  opencode run \
  -m <model> \
  --title "<short desc of task>" \
  -f <relevant file paths if obvious from task> \
  "<user's task, cleaned up into an imperative instruction>"

Prompt construction notes:

• Rephrase the user's ask as an imperative for the model. "can you have opencode fix the login bug" becomes "Fix the login bug in src/auth/login.tsx where the form silently fails for special characters."
• Add file paths you identified in step 1 via -f, if any. Don't attach files the task doesn't touch.
• Include the definition of done if it's not obvious. "Fix the bug and add a test covering the special-character case" is clearer than "fix the bug".
• Don't invent constraints the user didn't state. If they said "fix X", don't add "and also update the docs" unless they asked.

For running the command (timeouts, handling mid-run exits), see references/running.md.

Step 5: Verify

When opencode returns, verify the result. Even without a plan to check against, verification is required — don't blindly trust the model's self-report.

1. Read the diff. What did opencode actually change? Does it match the task?
2. Run tests if relevant. If the task had a testable outcome, run the project's tests yourself. Don't take "tests pass" on faith.
3. Flag anything unexpected. If opencode touched files outside the scope you expected, surface that explicitly.

Report back concisely:

• What opencode did (one or two sentences, not a replay of its output)
• What you verified (tests run, diff read)
• Anything off (unexpected file changes, model self-reports that don't match the code)
• Session ID (for resume)
• Next step: accept, resume with follow-up, or revert

---

Troubleshooting

See references/troubleshooting.md for common errors and fixes.

---

Reference files

• references/preflight.md — opencode version + auth check.
• references/model-selection.md — building the model list from authed providers.
• references/permissions.md — the three permission presets.
• references/argument-order.md — the File not found trap and how to avoid it.
• references/running.md — timeouts, mid-run exits, session continuation.
• references/troubleshooting.md — common errors and fixes.
• references/cli-flags.md — full opencode run flag reference.