{"slug": "autonomous-multi-agent-workflow-for-opencode-plan-review-implement-pr-from-a", "title": "Autonomous multi-agent workflow for OpenCode — plan, review, implement, PR from a Linear issue", "summary": "Autonomous multi-agent workflow for OpenCode that takes a Linear issue ID and automatically plans, implements, tests, and opens a draft pull request without user interaction. The workflow uses five specialized agents—including a design reviewer and a complexity reviewer—that operate in isolated contexts to provide fresh perspectives and prevent context pollution. Key design principles include test-first development, evidence-calibrated severity ratings for code reviews, and a fire-and-forget model where the user is notified upon completion.", "body_md": "# Autonomous Multi-Agent Workflow for OpenCode\n\nA fire-and-forget workflow that takes a Linear issue ID and autonomously plans, tests, implements, and opens a draft PR — with TDD baked in. You walk away; it notifies you when done.\n\nBuilt for [OpenCode](https://opencode.ai) using custom agents and slash commands.\n\n> **Important:** The `/workflow` command must run with `agent: build` (OpenCode's default agent with full tool access). The orchestrator needs unrestricted access to do git operations, dispatch subagents, and create PRs. If you're in a restricted mode, switch to build first.\n\n**Why this exists:**\n- **Fire and forget.** Kick off a task and walk away. You get notified when it's done or needs attention.\n- **Fresh perspectives.** Each subagent starts with clean context — no accumulated assumptions from the main session. Reviewers see the work with genuinely fresh eyes, not colored by having watched it being built.\n- **Context isolation.** The main agent's context window stays clean. Instead of one agent accumulating thousands of lines of implementation detail, each `@make` task runs in a fresh session with only the relevant code snippets. The orchestrator stays light.\n- **Test-first by default.** `@test` writes failing tests before `@make` touches any production code. Specs get validated as executable assertions before a single line of implementation.\n\n## How It Works\n\n```\n/workflow SUN-123\nmermaid\nsequenceDiagram\n    participant User\n    participant Main as Main Agent\n    participant PM as @pm (Linear)\n    participant Check as @check (Reviewer)\n    participant Simplify as @simplify (Reviewer)\n    participant Test as @test (TDD)\n    participant Make as @make (Implementor)\n\n    User->>Main: /workflow SUN-123\n    Note over User: User walks away\n\n    Main->>Main: 1. Verify repo setup (bare clone, gh auth)\n    Main->>PM: 2. Fetch issue context\n    PM-->>Main: Title, description, acceptance criteria\n    Main->>Main: 3. Create git worktree from master\n\n    Main->>Main: 4. Create implementation plan (with Test Design)\n    par 5. Review plan\n        Main->>Check: Review for risks/gaps + testability\n        Main->>Simplify: Review for overengineering\n    end\n    Note over Main: Max 3 review cycles with convergence detection\n\n    Main->>Main: 6. Split plan into discrete tasks\n    loop 7. For each task\n        Main->>Test: Write failing tests (RED)\n        Test-->>Main: Test files + failure classification\n    end\n    loop 8. For each task\n        Main->>Make: TDD mode: verify RED → implement GREEN\n        Make-->>Main: Implementation + RED→GREEN evidence\n    end\n\n    par 9. Final review\n        Main->>Check: Review full implementation\n        Main->>Simplify: Review full implementation\n    end\n\n    Main->>Main: 10. Commit (conventional), gh pr create --draft\n    Main->>PM: Post PR link on Linear issue\n    Note over User: Notification: workflow complete\n```\n\n**Ten phases, five agents, zero interaction required.**\n\n## The Agents\n\nEach agent has a single job and constrained tool access. See the raw files for the full definitions.\n\n### `@check` — Design Reviewer ([check.md](#file-check-md))\n\nReviews plans and code for risks, gaps, and flaws using an 8-point framework (Assumptions, Failure Modes, Edge Cases, Compatibility, Security, Ops, Scale, Testability).\n\n**Key design choices:**\n- Read-only — no write, edit, or bash. It cannot modify what it reviews.\n- Uses a different model (`gpt-5.3-codex`) than the main agent to get a genuinely different perspective.\n- Severity is evidence-calibrated: BLOCK requires a concrete failure path, not speculation.\n- Defers pure complexity concerns to `@simplify` — no overlap.\n- Reviews test code from `@test` when escalated (real behavior assertions, not mock existence).\n- Signs off on NOT_TESTABLE verdicts (allowed reason? evidence of attempt?).\n\n**Annotated highlight — the severity calibration:**\n```\n| BLOCK  | Will cause outage/data loss/security breach | Concrete failure path |\n| HIGH   | Likely significant problems                  | Clear mechanism       |\n| MEDIUM | Could cause edge-case problems               | Plausible scenario    |\n| LOW    | Code smell, style, minor                     | Observation only      |\n```\nWithout evidence, findings are capped at MEDIUM. This prevents review theater where everything is \"critical.\"\n\n### `@simplify` — Complexity Reviewer ([simplify.md](#file-simplify-md))\n\nSpots overengineering: YAGNI violations, indirection without payoff, accidental complexity, premature optimization.\n\n**Key design choices:**\n- Also read-only. Same trust boundary as `@check`.\n- Explicit precedence rule: `@check` safety findings are hard constraints. If `@simplify` recommends removing something `@check` flags as needed, `@check` wins.\n- Protected patterns (retries, circuit breakers, auth) are never flagged unless clearly unused.\n\n**Annotated highlight — the core question:**\n> For each component, ask: \"What if we deleted this?\" Justify its existence in one sentence. Can't? Flag it.\n\n### `@test` — TDD Test Author ([test.md](#file-test-md))\n\nWrites meaningful failing tests from task specs, verifies they fail for the right reason (RED), then hands off to `@make` for implementation (GREEN). This is the newest agent — it makes TDD the default workflow.\n\n**Key design choices:**\n- Writes test files only — **cannot modify production code under any circumstances**. This is enforced by file pattern matching and a post-step file gate in the orchestrator.\n- Uses `claude-sonnet-4-6-1m` (1M context) — same model as `@make`, needs to understand the codebase deeply to write meaningful tests.\n- Has bash access but sandboxed to test runners and read-only commands. Same deny list as `@make`.\n- Classifies every failure with structured codes: `MISSING_BEHAVIOR`, `ASSERTION_MISMATCH`, `TEST_BROKEN`, `ENV_BROKEN`. Only the first two qualify as valid RED.\n- Reports an escalation flag when tests need `@check` review (mixed failure codes, nondeterministic behavior, >2 mocks).\n- Can return `NOT_TESTABLE` for config-only changes, pure wiring, etc. — but only with justification and `@check` sign-off.\n\n**Annotated highlight — the failure classification:**\n```\n| MISSING_BEHAVIOR    | Function/class doesn't exist yet  | ImportError, AttributeError | Valid RED |\n| ASSERTION_MISMATCH  | Code exists but wrong behavior    | AssertionError with diff    | Valid RED |\n| TEST_BROKEN         | Test itself has errors             | Collection/fixture error    | Fix first |\n| ENV_BROKEN          | Environment issue                 | Missing dependency          | BLOCKED   |\n```\nThis classification prevents false RED — a test that fails because of a typo in the test file is not the same as a test that fails because the behavior doesn't exist yet.\n\n### `@make` — Task Implementor ([make.md](#file-make-md))\n\nReceives a task spec with acceptance criteria and implements it. Each invocation gets fresh context — only the task spec and relevant code snippets.\n\n**Key design choices:**\n- Uses `claude-sonnet-4-6-1m` (1M context) — fast and cheap enough to run per-task, capable enough to implement well-scoped changes. The large context window accommodates full code context.\n- Has write/edit/bash, but bash is heavily sandboxed:\n  - Can run: `uv run pytest`, `uv run ruff`, `ls`, `rg`, `diff`\n  - Cannot run: `git`, `pip`, `curl`, `wget`, `ssh`, `rm`, `mv`, `cp`\n- Strict file constraint: can only touch files explicitly listed in the task spec.\n- No new dependencies without explicit approval.\n- Max 2-3 fix attempts before stopping — prevents infinite loops.\n- **TDD mode:** When pre-written tests are provided by `@test`, validates RED first, implements GREEN, reports RED→GREEN evidence. If tests are questionable, escalates to the caller rather than editing test files.\n\n**Annotated highlight — the bash sandbox:**\n```yaml\npermission:\n  bash:\n    \"*\": deny                    # Default deny everything\n    \"uv run *\": allow            # Allow test runner\n    \"uv run bash*\": deny         # ...but not shell escape\n    \"uv run curl*\": deny         # ...or network access\n    \"uv run git*\": deny          # ...or version control\n    \"ls *\": allow                # Read-only inspection\n    \"rg *\": allow                # Search\n    \"git *\": deny                # Explicit top-level deny\n```\n\n### `@pm` — Project Management ([pm.md](#file-pm-md))\n\nFetches and updates Linear issues via the [Linear CLI](https://github.com/schpet/linear-cli). That's it.\n\n**Key design choices:**\n- Uses the cheapest model (`claude-haiku-4.5`) — it's just fetching/posting structured data. The CLI has `--json` output so structured parsing is straightforward.\n- Has bash access, but sandboxed to `linear *` commands only. Everything else is denied. Issue deletion is also denied.\n- The `linear` CLI is globally denied in bash permissions so only `@pm` can use it (the agent overrides with `\"linear *\": allow`).\n\n## The Commands\n\n### `/workflow` — Fire-and-Forget Orchestrator ([workflow.md](#file-workflow-md))\n\nThe main command. Takes a Linear issue ID, runs all ten phases autonomously. See the sequence diagram above and the raw file for the full phase definitions.\n\n```\n/workflow SUN-123\n```\n\nThe workflow dispatches agents, enforces review loops with convergence detection, handles the TDD cycle, and creates the draft PR. It never waits for user input.\n\n### `/review` — Standalone Code & Plan Review ([review.md](#file-review-md))\n\nAn independent review orchestrator that dispatches `@check` and `@simplify` in parallel against any artifact. This is useful outside `/workflow` — for reviewing your own changes, a teammate's PR, or a plan before committing to implementation.\n\n```\n/review              # Review uncommitted changes\n/review a1b2c3d      # Review a specific commit\n/review feature-x    # Review a branch diff against HEAD\n/review 42           # Review PR #42\n/review @plan.md     # Review a plan/architecture doc\n```\n\n**Key design choices:**\n- Auto-detects input type: uncommitted changes, commit hash, branch name, PR number/URL, or plan file.\n- For code reviews: reads full file contents (not just diffs) so reviewers have complete context.\n- For plan reviews: uses the explore agent to find related existing code, giving reviewers implementation context.\n- Presents both reviewers' outputs in their native scales — `@check` uses risk severity (BLOCK/HIGH/MEDIUM/LOW), `@simplify` uses payoff/effort. No normalization across agents.\n- The gate verdict (merge/no-merge decision) comes from `@check` only. Simplification recommendations are advisory.\n\n## Trust Model\n\nThe workflow enforces separation of concerns through tool access:\n\n| Agent | Can read code | Can write code | Can run commands | Can access external services |\n|-------|:---:|:---:|:---:|:---:|\n| `@check` | Yes | No | No | No |\n| `@simplify` | Yes | No | No | No |\n| `@test` | Yes | Test files only | Sandboxed | No |\n| `@make` | Yes | Yes | Sandboxed | No |\n| `@pm` | Yes | No | No | Linear only |\n\n**Why this matters:**\n- Reviewers can't accidentally modify what they're reviewing\n- The test author can't modify production code — enforced by file pattern matching and a post-step gate\n- The implementor can't do git operations or install packages — the orchestrator handles that\n- The PM agent can't touch code — it only manages issues\n- `@test` and `@make` share the same bash sandbox: test runners and read-only inspection only\n\n## The TDD Loop\n\nThe workflow uses test-driven development by default. Here's the flow:\n\n```\nPlan → @test writes failing tests → @make implements to green\n         ↓                              ↓\n    Failure classified:            Entry validation:\n    MISSING_BEHAVIOR ✓             Verify RED matches handoff\n    ASSERTION_MISMATCH ✓           If tests pass → STOP (anomaly)\n    TEST_BROKEN → fix first        If wrong failure → escalate\n    ENV_BROKEN → BLOCKED\n```\n\n### Decision Table\n\n| Condition | Action |\n|-----------|--------|\n| Task changes public API, fixes ", "url": "https://wpnews.pro/news/autonomous-multi-agent-workflow-for-opencode-plan-review-implement-pr-from-a", "canonical_source": "https://gist.github.com/ppries/f07fd6316bbd45807dd7a1896555b05b", "published_at": "2026-02-20 10:12:15+00:00", "updated_at": "2026-05-22 02:37:14.454509+00:00", "lang": "en", "topics": ["developer-tools", "artificial-intelligence", "open-source", "products"], "entities": ["OpenCode", "Linear"], "alternates": {"html": "https://wpnews.pro/news/autonomous-multi-agent-workflow-for-opencode-plan-review-implement-pr-from-a", "markdown": "https://wpnews.pro/news/autonomous-multi-agent-workflow-for-opencode-plan-review-implement-pr-from-a.md", "text": "https://wpnews.pro/news/autonomous-multi-agent-workflow-for-opencode-plan-review-implement-pr-from-a.txt", "jsonld": "https://wpnews.pro/news/autonomous-multi-agent-workflow-for-opencode-plan-review-implement-pr-from-a.jsonld"}}