Use when asked to work in a continuous loop until done or truly blocked. Orchestrates pickup, planning, TDD execution, implementation waves when needed, debugging side-chains, verification, and resume behavior.

2026-04-110

dr-clarify-spec

mikkihugo/aicoder-opencode

Use before planning when a feature or change request is underspecified. Resolve high-impact ambiguity around scope, consumers, security, failure handling, and acceptance criteria before writing the implementation plan.

2026-04-110

dr-code-review

mikkihugo/aicoder-opencode

Use for both preparing work for review and responding to review feedback. Keep review evidence local, concrete, and scoped to the real contract. Verify technically before agreeing or changing code.

2026-04-110

dr-design-and-planning

mikkihugo/aicoder-opencode

Use before implementation. Merge design discovery and plan writing into one DR-specific flow: identify the consumer, inspect the repo, debate boundaries with partner and combatant, and produce an execution-ready plan that hands off cleanly into DR-native tasks, TDD, and implementation waves.

2026-04-110

dr-finish-and-verify

mikkihugo/aicoder-opencode

Use for the last mile: rerun verification, inspect diffs, commit or push if requested, and perform local docker-compose checks when needed. This is the DR local-tools replacement for MCP-style finish/deploy carryovers.

2026-04-110

dr-generate-tasks

mikkihugo/aicoder-opencode

Use after planning and before implementation when you need a concrete, dependency-ordered task list. Turn the DR feature spec and plan into independently testable task slices with exact file paths and verification commands.

2026-04-110

name	control-plane-maintenance-base
description	Shared maintenance topology and policy for aicoder-opencode — one server per repo, shared plugins, overlay-first changes
user-invocable	false
models	["ollama-cloud/kimi-k2-thinking","ollama-cloud/glm-5.1","ollama-cloud/minimax-m2.7"]
routing_role	architect
routing_complexity	large

control-plane-maintenance-base

Shared maintenance/control-plane base for repos that attach to the aicoder-opencode server.

Use this skill when work is about:

shared maintenance workflows
shared OpenCode control-plane behavior
cross-repo maintenance plugin baselines
per-repo server topology that should stay consistent across product repos

Responsibilities

Keep one OpenCode server per repo.
Keep shared maintenance logic in aicoder-opencode.
Push repo-specific overlays back into the product repo only when they are truly product-specific.
Prefer thin install shims in product repos over copied plugin implementations.
Change maintenance topology in small reversible steps and verify one target repo path before rolling the same pattern wider.

Contract

aicoder-opencode owns shared maintenance plugins and skills.
Product repos may install shared base shims, then add local overlays.
Control-plane changes should not silently fork per repo.

Topology

aicoder-opencode on 8080
dr-repo on 8082
letta-workspace on 8084
OpenChamber attaches to one repo server at a time

Shared Base

Shared plugin source belongs in src/plugins/
Shared skill source belongs in .agents/skills/
Product repos consume shared base via repo-local shims

Runtime: Model Provider Priority

Use config/models.jsonc as the authoritative allowlist. Only models listed there are approved. Provider priority within each registry entry follows provider_order[].priority.

Key providers in the registry:

Provider	Status	Notes
`ollama-cloud/*`	Free (rate-capped daily)	Best when cap not exhausted
`iflowcn/*`	Free	Major free provider; priority 1 for many registry entries
`mistral/*`	Subscription	codestral, devstral variants
`minimax/*`	Subscription (minimax.io)	Reliable fallback
`kimi-for-coding/*`	Subscription	User-Agent gated, works via opencode
`xiaomi-token-plan-ams/*`	Subscription (direct)	mimo-v2-pro priority 1 via token-plan-ams.xiaomimimo.com
`openrouter/:free`	Free tier	Allowed; use curated models only
`openrouter/*` (paid)	Pay-per-token	Last resort; only models in registry
`longcat-openai/*`	Free	Special use only — not general fallback

Never use: xai/grok-*, openai/* (ChatGPT), togetherai/*, uncurated openrouter auto-selection.

Autopilot model selection (per task matrix)

Task type	Primary	Fallback
Autonomous coding iteration (dr-repo)	`ollama-cloud/qwen3-coder:480b`	`xiaomi-token-plan-ams/mimo-v2-pro`
Maintenance / type fixes (letta-workspace)	`ollama-cloud/devstral-2:123b`	`xiaomi-token-plan-ams/mimo-v2-pro`
Fast general iteration	`ollama-cloud/kimi-k2.5`	`xiaomi-token-plan-ams/mimo-v2-pro`
Architecture / heavy reasoning	`ollama-cloud/kimi-k2-thinking`	`xiaomi-token-plan-ams/mimo-v2-pro`

Model selection is handled by OpenCode plus the model-registry plugin. The plugin can reroute task launches when the requested provider is in quota backoff, when an agent exposes ordered models: metadata, or when the task falls back to curated registry routing. Do not override model choice with env vars.

Runtime: Model Selection

The model-registry plugin exposes two tools:

list_curated_models — all registry entries; use freeOnly: true to scope to free providers
select_models_for_role — models recommended for a named role (e.g. "autonomous-agent", "code-review")
get_quota_backoff_status — providers currently in quota backoff and when they expire

Rules:

Before starting a long autonomous task, call get_quota_backoff_status. If a needed provider is in backoff, let the plugin reroute task launches using the current agent models: list or the curated registry fallback.
Never fall back to longcat, claude, gpt, or grok models automatically. These are subscription-gated or architecturally undesirable as automatic fallbacks.
Free providers (ollama-cloud, openrouter free-tier) are preferred for autonomous/maintenance loops. Paid providers (openrouter paid models) only when no free alternative covers the capability tier.
Temperature is set automatically by the model-registry plugin based on the model's capability_tier. Do not override temperature in prompts.

Runtime: Autonomous Execution

These rules apply to all repo maintenance sessions (dr-repo autopilot, letta-workspace maintenance, aicoder unblock-and-patch):

Default to sustained execution. Do substantial work before reporting back.
Take your own best evidence-backed recommendation for reversible decisions.
Ask only when the next action is destructive, irreversible, or preference-shaped in a way that materially changes the path.
If confidence is low on a critical sub-decision, spawn a specialist subagent for review before proceeding — do not interrupt the human.
When a maintenance loop fires and finds no pending work, log and exit cleanly. Do not spin on empty queues.
If a session was previously interrupted, re-read the last checkpoint or session-id file before starting new work to resume cleanly.

Autopilot continuation

When the autopilot timer fires:

Check if the runner unit is already active — if yes, exit immediately (do not start a second runner).
Check the session-id file. If it contains a valid session ID, resume that session with --session <id>.
If no session-id file exists, start a new session with the configured title.
Use get_quota_backoff_status before starting a long chain — if the configured model's provider is in backoff, switch to the next provider in the priority table above.
On quota error (429) mid-session, the model-registry plugin records the backoff. The next timer cycle will start a fresh attempt — do not retry in a tight loop within the same session.

Runtime: Quota and Provider Events

The plugin tracks quota events automatically and backs off providers for 1 hour on HTTP 429 or quota-keyword errors. No manual action is needed during normal operation.

If you observe a provider persistently failing (beyond the 1-hour window), call get_quota_backoff_status and route around it using the curated fallback in provider_order.

Verification contract

Downstream skills and agents that consume this base inherit the following verification rules:

Every verification report ends with a final line: VERDICT: PASS, VERDICT: FAIL, or VERDICT: PARTIAL. Plain text, no markdown, no hedging.
PARTIAL is reserved for environmental blockers only (tool missing, service will not start, no test framework). Ambiguous findings are FAIL, not PARTIAL.
A PASS requires at least one executed adversarial probe across concurrency, boundary values, idempotency, or orphan/dangling state — reading code is not verification.
Each check must record the exact command run and the observed output. Uncited claims do not count as verified.

See targets/dr-repo/overlay/.opencode/agents/verifier.md for the full probe checklist and output block format.

Avoid

Copy-pasting shared plugin logic into product repos
Moving product doctrine into aicoder-opencode
Adding extra OpenCode servers when one per repo is enough
Large topology rewrites without verifying the next real maintenance path
Overriding temperature manually (the plugin sets it from capability tier)