Loading ToolBench
Claude Code orchestrates OpenCode worker agents: dynamic model routing, parallel-write safety, independent verification and read-only review.
Strong domain-specific design with clear role-based composition and safety guardrails. Tool names follow verb_noun pattern (massa_env, massa_plan, massa_run, etc.). All 6 tools have substantive descriptions (100-250 chars) explaining WHAT, WHEN, and WHY. Input schemas are complete with typed parameters and descriptions. However, output schemas are not documented in the visible code, responses are inferred from implementation. Error handling is present (GuardError with actionable messages) but not uniformly applied across all tools. Security is well-designed (destructive operation guards, secret redaction) but not exposed as tool-level permission declarations.
Check the OpenCode backend and discover the live model catalog and the role->model routing table. Call once at the start of a run. Reports blockers (no OpenCode, no models) explicitly rather than degrading silently.
Create a run with an objective, measurable acceptance criteria and a task plan; or resume/inspect prior runs. Use route 'audit' with resume=true for 'continue' / 'what's left?' requests - it reconstructs prior state instead of restarting work. Criteria should be observable (a command, a file, a checkable outcome), never subjective.
Generate a human-readable report of the run: objective, plan, worker results, verification outcomes, review findings, and completion status.
Request an independent read-only review of the implementation against the original request and acceptance criteria. The reviewer role is read-only by construction and uses a different model family for decorrelated review.
Delegate work to OpenCode workers. Execute a batch of tasks (scout, architect, builder, debugger, tester, reviewer) with role-based model routing, parallel-write safety, and isolated worktrees.
Output schemas not documented. Tool descriptions explain inputs but do not specify what fields/structure the LLM should expect in responses. This forces LLMs to infer output shape, risking misuse of returned data in downstream tool calls.
No tool-level permission declarations. Guards are implemented in code (destructive operation checks, secret redaction) but not exposed as tool annotations (readOnlyHint, destructiveHint). LLMs cannot see which tools are safe to retry or which require authorization.
Error recovery guidance incomplete. GuardError provides actionable messages for destructive operations, but other failure modes (missing project_dir, invalid run_id, OpenCode backend unavailable) lack recovery hints. LLMs need 'what to do next' for each error class.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Run acceptance criteria checks and verification commands. Execute shell commands to validate that acceptance criteria pass and that the implementation meets requirements.
Parameter dependencies undocumented. massa_plan accepts both 'objective' (for new runs) and 'resume' (for loading prior runs), these are mutually exclusive modes but the descriptions do not state this. LLMs may pass both, causing ambiguous behavior.
No pagination or result limits documented. massa_run accepts an array of tasks and massa_verify accepts arrays of criteria/commands, but no guidance on maximum batch size. Unbounded arrays risk context window exhaustion or API timeouts.