use-other-model

Use Other Model

Goal

Reliably delegate suitable tasks to other models or independent reviewers, while retaining the main agent's ultimate responsibility, failure layering, and reviewable evidence.

This is adelegation routing skill, not a second agent platform. The main file only retains stable entry points, hard boundaries, and quick checks; task contracts, state machines, verification details, failure triage, and startup templates are read on demand references/。

Core Principles

1. Quality and determinism take priority over token savings

   • Delegate only when boundaries are clear and acceptance can be independent.
   • When coordination cost exceeds the benefit, the main agent completes it directly.

2. Being able to start does not mean being able to finish

   • Exit code 0, an agent self-reporting success, or a single passing test cannot alone prove task completion.
   • Provider/model, permissions, tool errors, expected artifacts, and independent verification must be checked layer by layer.

1. The executor cannot also serve as the final acceptor

   • The executing agent can only propose a candidate status.
   • Verifier status is generated by an independent read-only reviewer, deterministic validation, or the main agent.
   • Human acceptance status can only be decided by the user/human.

2. Prefer minimal official commands; do not expand the launcher

   • First run the CLI's official, minimal, observable command or smoke check.
   • Without raw failure evidence, do not add complex process trees, state machines, redaction, cleanup, or custom execution protocols.

3. Externally distributed skills take the post-installation directory perspective and are self-contained at runtime

   • Examples use only relative paths within the skill directory.
   • Do not write local absolute paths, development-period reports, monorepo-internal test/CI paths, or user-private directories.
   • Any rules, templates, failure boundaries, verification conditions, and current design rationale required for normal execution must be located in this use-other-model/ directory's SKILL.md、references/ or scripts/ .
   • The source monorepo's .agents/、docs/reports/, hardening archive, and root-level AI memory can only serve as development-period evidence and cannot become runtime dependencies after independent installation.
   • External technical reports are allowed only as optional background; when the network is unavailable, the normal process must still be completable from this skill directory.
   • For the causal memory of the current hard gate, see references/design-memory.md; when maintaining or extending this skill, it is not necessary to go back to the monorepo archive to understand the current design.

When to Delegate

Suitable

• Batch or multi-file operations, format conversion, repetitive editing.
• Work expected to exceed 5 minutes and whose task boundaries can be packaged.
• Independent subtasks that can be parallelized.
• Independent verification, red-team review, or security audit.
• OpenCode provider/model, default model, variant, and headless pipeline checks.
• When a choice must be made among MCP, an independent Claude Code session, and the OpenCode path.

Not Suitable

• A single-file short change or query that can be completed at a glance.
• Tasks whose requirements are still changing and that require frequent follow-up questions to the user.
• Tasks for which the read/write scope, acceptance commands, or completion conditions cannot be listed.
• Delegating complex root causes, security judgments, architectural trade-offs, or final merge decisions to a weak execution model.

The user has already given the complete opencode run / claude -p / skills add command, respect the original command by default; do not automatically expand it into a wrapper, agent team, release process, or synchronous fallback just to be "safer."

A-D Routing

Path	Applicable Scenario	Minimum Evidence
A: MCP Tool	Simple task, single call	connector/tool, actual parameters, real result
B: Independent Claude Code Session	Multi-step coding, batch operations, requiring independent read/write and verification	Actual commands, working directory, permission/tools, raw output, exit code
C: OpenCode provider mode	Explicit provider, API key/baseURL,provider/model	provider/model/variant/session, authentication chain, structured events, exit reason
D: OpenCode default internal model	Default model smoke check, headless, unspecified --model	Default selection chain, variant/session, observable actual model identity, raw events

Hard rules:

• C and D are not substitutes for each other; an explicit provider/model goes through C, the default internal model goes through D.
• OpenCode direct launch and native temporary subagents are mutually exclusive by default; combine them only when the user explicitly requests nesting.
• "The model is discoverable" does not mean "this session has selected it." Models with the same name must be distinguished by provider/model。
• A-D are invocation paths and do not represent model strength. Complex diagnosis, security audits, and final judgments are still handed to a strong model/main agent.

For the detailed capability contract, role boundaries, and identity levels, see references/delegation-contract.md。

Weak Executor Model Hard Gate

A weak model may only take onexecution tasks that have already been flattened by a strong main agent, and cannot run the entire skill decision process.

A weak executor model may be used only when all of the following conditions are met:

• The set of target files can be listed precisely before startup.
• The modifications can be written as deterministic step-by-step actions and do not require architecture, root cause, security, or product judgment.
• The verification commands have been frozen.
• No need to ask the user during execution.
• Any unexpected situation can be safely stopped and handed back to the main agent.

The strong main agent must first complete A-D routing, preflight, scope freezing, and failure strategy, then generate Weak Executor Packet. The packet received by the weak executor model must contain DECISION_BUDGET: 0、EXACT_ACTIONS、STOP_IF and a fixed RETURN schema。

The weak executor model is forbidden from:

• Selecting A-D, the model tier, or the implementation plan on its own.
• Reading this skill's references on its own to fill in the process.
• Expanding the read/write scope, switching tools, switching provider/model, or installing dependencies on its own.
• Recovering from failures that are not predefined on its own.
• Modifying acceptance rules or writing verifier_status / human_accepted。

Any choice whose answer is not explicitly given in the packet must return BLOCKED, and must not continue reasoning to solve it.

For the complete weak model contract and fixed packet, see references/weak-executor-contract.md。

Fixed Execution Card Before Startup

Execute in order; do not skip:

1. Establish evidence directory

   • For the current project root directory use .use-other-model/task-YYYYMMDD-<slug>/。
   • .use-other-model/.gitignore The content must be a single line *。
   • context, prompt, raw output, stderr, execution log, and derived summaries are all placed in that task directory.

2. Freeze role and scope

   • Explicit execution / diagnostic / audit。
   • freeze working_directory, read/write allowlist,expected_changed_files, forbidden paths/actions, acceptance commands, and expected artifacts.
   • See the full schema at references/context-packet-template.md。

3. Complete preflight

   • The working directory and allowed paths must be genuinely reachable; cross-workspace paths must be explicitly included in the read allowlist.
   • Explicit provider paths record the full provider/model; when the default model identity cannot be obtained, keep it unknown and do not guess.
   • Only check whether credential/authentication configuration exists; do not read or record secret values.
   • Record the actual permission mode, tool scope, and observable auto-loaded skills.
   • verify_commands, tests, scoring, verifier, CI, and acceptance schema are frozen before execution.
   • When the CLI does not support capabilities such as allowlist/dry-run/read-only, record the capability gap and compensate with external validation; do not fabricate parameters.

4. Compile the execution package according to model capability

   • Medium/strong execution agents can use the full Task Packet.
   • For weak execution agents, the main agent must flatten the full contract into Weak Executor Packet; weak models must not read references, choose routes, or supplement plans on their own.

5. Run the minimal smoke check

   • The command templates for B/C/D read the corresponding reference as needed.
   • --auto is not a default switch; read-only tasks do not enable it, and write tasks use it only when the user explicitly authorizes it, the scope is enumerable, and it is rollback-capable.

6. Execute the task and preserve raw evidence

   • Save stdout, stderr, and JSON/JSONL as-is.
   • Save derived summaries separately; do not overwrite or "beautify" the raw output.
   • Retries must not overwrite the previous round of evidence.

7. Independent verification

   • Precisely compare changed files with expected_changed_files。
   • Check for out-of-bounds paths, secret values, dangerous actions, and tampering with acceptance rules.
   • Also verify exit codes, structured tool/permission events, expected artifacts, and frozen verification commands.
   • Only VERIFIER_PASS can report "candidate complete" to the user.

8. Cleanup and closure

   • Only clean up secret values and temporary credentials that should clearly be deleted; retain evidence according to the task policy.
   • Cleanup risks are reported independently and must not be masked by the success of earlier steps.

For the full preflight, prompt contract, state machine, and verifier rules, see:

• references/delegation-contract.md
• references/evidence-verification.md
• references/failure-routing.md

Role boundaries

Role	Default model tier	Responsible for	Not responsible for
Main agent	Strong	Planning, complex root-cause analysis, integration, final acceptance	Does not outsource completion claims and merge decisions
Execution subagent	Weak/medium	Clear diffs, batch operations, checklist-based execution	Does not expand requirements or perform architecture/root-cause/security sign-off
Diagnostic collaborator	Strong	Independent evidence collection, candidate hypotheses, reproduction	Does not make final decisions on behalf of the main agent
Audit subagent	Strong and independent	Read-only review after freezing the working tree	Does not modify the implementation or treat the executor's conclusions as evidence

Supplement: a weak execution agent can only use Weak Executor Packet，decision_budget = 0; diagnosis, auditing, routing, preflight, and final acceptance must not be delegated to a weak model.

Recommended order:

主代理冻结范围 → 编译执行包 → 执行/诊断取证 → 主代理整合 → 工作树冻结 → 独立审计 → 主代理最终验收

Additional hard boundary of Option B

Option B is an unattended coding agent, not an ordinary Q&A session:

• Write the context packet first, then start the sub-session.
• The sub-session must be able to read files, modify files, run frozen verification commands, write an execution log, and then exit.
• When a weak model uses Option B, it still only receives the Weak Executor Packet generated by the main agent, and the complete SKILL / references are not handed to it for its own interpretation.
• The default startup template, browser acceptance template, and detailed execution contract are read on demand:
  • references/method-b-independent-session.md
  • references/claude-code-launch-templates.md
  • references/frontend-browser-verification-template.md

Launcher Complexity Red Line

A one-off launcher is only responsible for preparing paths, invoking the CLI, saving the real output, and returning the exit code. If any of the following signs appear, stop first:

• Adding a large number of functions or complex process tree governance for a single CLI call.
• Without direct evidence of command failure, introducing ProcessStartInfo, asynchronous pipelines, manual quoting protocols, or custom state machines.
• The launcher itself fabricating the success/blocked/partial status of result.json .
• Putting redaction, batch kill, cleanup, or long-term state into the launcher.
• Treating ANTHROPIC_MODEL as a universal hard gate for all Claude Code tasks.

The red line may be crossed only when "the standard template has actually failed + the raw stdout/stderr/exit code are reproducible + the new code corresponds one-to-one with the failure evidence".

Failures and Retries

Failures must first be stratified, then handled:

• PREFLIGHT_BLOCKED
• CLI startup failure
• provider/auth failure
• tool/permission failure
• task execution failure
• artifact/verifier failure
• browser verification failure
• cleanup risk

the same taskat most one failure retry, and the failure layer or input conditions must be changed, for example correcting the path/permissions before retrying. Polling in place under the same command, context, and permission conditions is an invalid retry, and the main agent takes over.

The weak model exception is stricter: the weak model may perform one fixed recovery only when the packet has already predefined the specific failure signal and the next action; any failure that is not predefined immediately BLOCKED, and it must not switch plans on its own.

For detailed signals, first actions, and fallback rules, see references/failure-routing.md。

Budget

The task packet records the time budget; when real token consumption can be obtained, also record the token budget/usage; if it cannot be obtained, write unavailable。

• Simple: within 5 minutes
• Medium: 10–20 minutes
• Complex: 20–45 minutes
• Expected to exceed 45 minutes: split the task first

Insufficient budget cannot be a reason to loosen the write allowlist, disable the verifier, or repeatedly retry with the same parameters.

Security Boundary

• Do not copy API keys, authentication headers, or private tokens into prompts, context, logs, or results; only reference environment variable names.
• The execution agent does not modify tests, evaluations, scoring, the verifier, CI, or the acceptance schema to make itself pass, unless these files are themselves the user's explicit target and there is separate independent acceptance.
• Do not automatically commit, push, release, deploy, perform database migrations, production operations, long-term memory writes, or external task state modifications, unless the user explicitly authorizes it and it is handled by the corresponding dedicated process.
• Do not access sibling workspaces, user directories, or whole-disk files by default.
• Frontend tasks cannot use build/test as a substitute for browser acceptance; when the browser is unavailable, explicitly mark as blocked.

Minimal acceptance checklist

• The working directory, paths, model identity, permissions, and acceptance rules were frozen before invocation.
• When cross-workspace access is unreachable, obtain it before the model invocation PREFLIGHT_BLOCKED。
• The weak model task satisfies the weak-executor applicability threshold and actually received DECISION_BUDGET: 0、EXACT_ACTIONS、STOP_IF and fixed RETURN schema。
• The weak model did not read references on its own, choose A-D, expand scope, switch provider/model, or recover from an undefined failure.
• When the exit code is 0 but there are permission denials, tool errors, missing artifacts, or verifier failures, it was not marked as success.
• The changed files exactly match the expected set and all are within the write allowlist.
• The raw stdout/stderr/JSONL is independently reviewable, and derived summaries do not overwrite the raw evidence.
• The executor did not write verifier_status / human_accepted, nor modify the frozen acceptance rules.
• Retry at most once and change the failure condition; the weak model only performs predefined recovery.
• The main agent personally reviews the final diff and completes independent verification matching the task risk.

For the complete state machine and deterministic checks, see references/evidence-verification.md。

Read on demand

• Weak executor model compilation → references/weak-executor-contract.md
• A：MCP → references/method-a-mcp-tools.md
• B: Claude Code independent session → references/method-b-independent-session.md + references/claude-code-launch-templates.md
• C：OpenCode provider → references/opencode-provider-launch-templates.md
• D: OpenCode default/headless → references/opencode-headless-launch-templates.md
• Task packet → references/context-packet-template.md
• Failure triage → references/failure-routing.md
• Independent verification → references/evidence-verification.md
• Frontend browser acceptance → references/frontend-browser-verification-template.md
• Environment variable identification → references/environment-variables.md
• Maintenance/design reasons → references/design-memory.md
• Cases and background → references/case-study-git-commits.md、references/technical-reports.md
• Complete reference navigation → references/README.md