Skip to content
Back to skills

Opencode Implement

ASecurity

Delegate a well-scoped implementation to the OpenCode CLI's free model pool in an isolated git worktree with a machine-enforced no-push permission config, then verify independently before merge. Use for LOW-risk mechanical work where the free pool is the cheapest capable tier, when paid quota should be preserved, or when the user asks to let opencode implement something.

  • 3 stars
  • 0 votes
  • 0 copies
  • 4 views
  • Added September 19, 2026
ai-agentsrustgoshellbashtestinggit

Works with

  • terminal
  • cli

Security analysis

A100/100

Scanned September 25, 2026

npx -y skills add aarontzeng/dev-lead --skill opencode-implement --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Opencode Implement?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Opencode Implement
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/aarontzeng-opencode-implement/badge)](https://www.skillsdirectory.com/skills/aarontzeng-opencode-implement)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: opencode-implement
description: Delegate a well-scoped implementation to the OpenCode CLI's free model pool in an isolated git worktree with a machine-enforced no-push permission config, then verify independently before merge. Use for LOW-risk mechanical work where the free pool is the cheapest capable tier, when paid quota should be preserved, or when the user asks to let opencode implement something.
---

# Delegate implementation to opencode, then verify

**Measured 2026-09-12, `muse-spark-1.3` `--variant xhigh`, first implement round
on this account:** good enough to delegate spec-clear work to, with one
standing condition — **pair it with a falsifiability review leg**. It gets
judgement calls right (it reasoned back through a row filter to decide which
schema fields may be `Optional`), respects an out-of-scope instruction and
reports the defect instead of fixing it, and — rarest of all — its self-report
was accurate: six claimed mutants, six confirmed by the lead's own re-run, plus
unprompted disclosure of an `npm ci` and of pre-existing lint errors the lead's
own gate summary had swallowed. Its one systematic weakness is that it writes
tests that pass rather than tests that can fail: every finding from the
falsifiability leg was that shape, including two repaired fixtures that could
not go red outside market hours — a guard it had correctly described in
someone else's test minutes earlier and did not generalise to its own. Full row
in the runtime file's calibration table.

The free pool's implement niche: **cheapest capable tier for LOW-risk,
well-specified work** — it costs no quota at all, and it **runs the test
suite natively** (bash is allowed under the write config; there is no
allow-list spelling to pin). The trade-off is best-effort capacity:
congestion is normal, so give it the tasks nobody is waiting on.

## Before the first run of a session

Read **[`../opencode-adversarial-review/references/opencode-runtime.md`](../opencode-adversarial-review/references/opencode-runtime.md)**.
The two permission traps (zero-commit binding, last-match-wins), the
congestion retry loop, the model catalogue and the stealth-model
family-unknown caveat, and the audit log lines all live there and are
assumed here.

## Worktree + config, always

```bash
RUN_DIR=$(mktemp -d "${TMPDIR:-/tmp}/opencode-implement.XXXXXX")   # FIRST — snapshots below land here
BASE=$(git rev-parse HEAD)   # from a clean checkout, recorded before anything
WORKTREE=../<repo>-opencode-<short-task-slug>
git worktree add -b opencode/<short-task-slug> "$WORKTREE" "$BASE"
# The helper lives in the SUITE's tree, cwd is the TARGET repo — a bare
# `scripts/…` resolves against the target and exits 127.
DEV_LEAD=${DEV_LEAD_ROOT:-$(ls -d "$HOME"/.claude/plugins/cache/dev-lead/dev-lead/* 2>/dev/null | sort -V | tail -1)}
[ -x "$DEV_LEAD/scripts/snapshot-refs.sh" ] || { echo "dev-lead root unresolved — set DEV_LEAD_ROOT to your checkout"; exit 1; }
"$DEV_LEAD/scripts/snapshot-refs.sh" save "$WORKTREE" "$RUN_DIR/remote-refs.before"
```

Then write the write-role config into the worktree as `opencode.json` —
a fresh worktree cannot already have one, but if the repo *tracks* an
`opencode.json` of its own, set it aside first and restore at teardown
(same collision note as the review skill). Wildcard FIRST — last match
wins; see runtime:

```json
{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "bash": {
      "*": "allow",
      "git push*": "deny",
      "git reset*": "deny",
      "git checkout*": "deny",
      "git clean*": "deny",
      "git worktree*": "deny"
    },
    "edit": "allow"
  }
}
```

No-push machine-enforced (measured: the deny fires, the model is told,
reports MACHINE-DENIED, and continues — no silent death), tests and file
edits free. The instruction layer is the belt on top — measured: a free-pool
delegate refused a push by quoting the user's global no-push rule before the
machine layer ever saw it. The config file stays untracked; never stage it,
remove at teardown.

On the FIRST run, confirm the log's `projectID=` is a hash, not `global` —
`global` means the config (including the push deny) silently is not in force
(runtime, trap 1). The worktree has commits so this should never happen;
checking costs one grep.

## Run it

```bash
# RUN_DIR was created in the worktree step above.
# Write the task prompt to "$RUN_DIR/task.md" in its own FOREGROUND step.

cd "$WORKTREE" && opencode run --print-logs --log-level INFO \
  -m opencode/<free-model> \
  --variant <effort> \
  < "$RUN_DIR/task.md" > "$RUN_DIR/impl.log" 2>&1
```

**`--variant` is not optional here either.** Omitting it silently takes the
provider default -- measured on the review side 2026-09-08, where the default
returned 8 findings against `xhigh`'s 10 on an identical brief and frozen
commit. This launch block lacked it until a lint rule caught the omission.

**The task prompt goes on STDIN, not in argv** — an argv prompt over ~1–2 KB
hangs before the session is created, silently and in every model. See the
runtime file for the measured size table and how to tell this stall apart
from genuine congestion.

Background launch, generous timeout (20m+), retry across models on
congestion per the runtime loop.

**Model choice: the fast terminal-tuned named model by default** — the
read/grep/edit/bash/test loop is many short turns, which rewards few active
parameters per token; it was also the fastest responder measured. The
huge-context named model earns its place only when the task genuinely needs
to hold a lot at once (a sweep across a whole subsystem). A stealth model
when the task needs more judgment — remembering its family is unknown, so
the review leg must then come from a KNOWN family that also isn't the
lead's.

## Writing the task prompt

Identical discipline to the other implement skills — premise preflight (STOP
on a wrong premise, report with evidence), exact scope and acceptance
criteria, the worktree's absolute path as working root, **name the existing
tests/mocks whose seams the change moves**, **anchor every new test to a
position** ("class X, immediately after test_y"), no recursive delegation.
This family's specifics:

- **Tests: ask it to run the suite itself** and report honest counts — the
  config permits any test command, no pinned spelling. The lead re-runs
  everything afterward regardless; delegate self-testing is its feedback
  loop, not the verification.
- Git rules to state verbatim: MAY `git add`/`git commit` on the worktree
  branch, plain-English messages, no AI-authorship trailers, NEVER
  push/reset/checkout/clean (the config enforces it; saying it saves a
  denied attempt).

## After it finishes: verify before anything is trusted

The same lead sequence as every implement skill, none of it optional:

1. `git status --short`, `git log "$BASE"..HEAD --oneline`,
   `git diff "$BASE"...HEAD` — scope verified, not assumed; expect
   `?? opencode.json` (yours) and nothing else untracked; check commit
   messages for trailers.
2. **Push check** — a later step is a NEW shell and `$DEV_LEAD` does not
   survive into it, so re-resolve before using it:

   ```bash
   DEV_LEAD=${DEV_LEAD_ROOT:-$(ls -d "$HOME"/.claude/plugins/cache/dev-lead/dev-lead/* 2>/dev/null | sort -V | tail -1)}
   "$DEV_LEAD/scripts/snapshot-refs.sh" check "$WORKTREE" "$RUN_DIR/remote-refs.before" || exit 1
   ```

   Any delta is a stop-and-report incident.
3. **Run the full suite yourself** in the worktree — the delegate's counts
   are claims (a measured delegate self-reported 150 on a 445-test suite;
   the code was fine, the number was not).
4. **Mutation-proof every new regression test** (commit the work first;
   editor-tool mutations, not sed; capture-then-report, never `&&`-chain the
   verdict — the full mechanics are in
   [`dev-lead/references/mutation-runbook.md`](../dev-lead/references/mutation-runbook.md)).
5. Cross-family adversarial review. A NAMED-family implementer makes every
   other family cross-family by construction. A stealth-model implementer
   makes cross-family UNVERIFIABLE — so when family accounting matters,
   either implement with a named model in the first place or take two
   reviewers from two different KNOWN families.
6. Merge gate: user sees the diff and verified findings; fast-forward, push
   and tear down (including the untracked `opencode.json`) only on approval
   — the person's, or, where the roster sets `merge_gate.mode = lead`, a
   fully green verdict itself; anything not green, and any stricter project
   contract, still goes to the person. The delegate never pushes.

The fix-round loop (findings quoted verbatim, same worktree, new commit,
re-verify including new mutations) is `dev-lead` Phase 2 — this skill adds
nothing to it.

## What this is not

Not a way to make big changes free. Congestion makes turnaround
unpredictable, and a task worth real supervision belongs with a delegate
whose capacity is paid for. Give this family the mechanical sweeps, the
bounded refactors, the second implementation attempt — the work that is
cheap to redo if the queue eats a run.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.