I went for a walk.

When I came back, the work had landed across three branches. Each subagent had worked in its own worktree on its own branch. The build was green on each one. The tests were green. The lint was green. The typecheck was green. The release manager subagent had drafted the changelog. Nine of the ten issues were closed. The tenth stayed open — it needed a real union restructure, not a mechanical fix.

I had not read a single line of the diff yet.

What I actually asked for

I had a backlog of small things in the Projex repo. Tagged-union cleanups. Type tightening. Documentation gaps. A bug where one of the smart-grid props was a documented prop but a no-op at runtime. A redundancy where two functions with slightly different spellings did the same thing.

I described this to my main agent. The main agent looked at the issue tracker, saw the labels (bug, enhancement, documentation), grouped them by file area, and dispatched three subagents in parallel.

One subagent got the package.json + bundling issues. One got the type-system + tagged-union issues. One got the documentation + test-coverage issues. Each one worked in a separate worktree on a separate branch. Each one committed locally and reported back. A fourth subagent, the release manager, handled release prep alongside them: the version bump and the changelog.

I watched the transcript. Mostly I stayed out of the way. I made tea.

What the subagents actually did

I saw the dispatch messages. I saw the report-back messages. I did not read the intermediate diffs. The subagents were set up to commit per-issue. Each commit was meant to be independently reviewable.

A few things I noticed in the report-backs:

• One subagent caught a redundancy I hadn't seen. Two exported functions, normalizeStats and normaliseStats, with the American and British spellings. Both did the same thing. The codebase had drifted to the British spelling in the actual logic. The American spelling was the alias. Both were exported. The subagent deprecated the American one with a JSDoc tag and updated the docs to point at the British spelling.
• One subagent found a related issue while fixing another one. While narrowing the ProjectStats union, it noticed FetchProjectDataResult.commits was using undefined while sibling fields used null. The subagent opened a new issue and included the fix in the same branch.
• One subagent flagged a peer-dependency problem I had been ignoring for two months. The CLI packages (ts-morph, chalk, @inquirer/prompts, commander) were installed by every consumer, even ones who only imported the components. The subagent moved them to optional peerDependencies so consumers importing only components stopped dragging in the CLI bundle.

None of these were in my original brief. The subagents went past the edges of what I asked for, in the direction of "things that were obviously wrong in the same file area."

Where I read the code

The first time I read any of the code was after all three subagents finished and opened their PRs. I skimmed the diffs before merging. Not a line-by-line review. A sanity check.

I was looking for decisions the AI made without asking me. Function names I wouldn't have picked. Behaviour that wasn't in the brief. Edits that touched code outside the file area I asked about. The kind of things a real code review catches, except I was reviewing the decisions, not the code.

Some of the diffs were four lines. Some were thirty. None of them were complex enough to need a real review. They were tagged-union narrowings, JSDoc additions, dependency relocations. The kind of work where you skim it once, you understand it, you move on.

If I'd skimmed each PR as it landed, I'd have read the rename with no idea the docs were about to change under it. Reading the batch, I could see the normaliseStats deprecation and the docs update pointing at it in the same sitting. The batch skim was faster than piecemeal would have been.

Where I did intervene

I didn't push back on any of the code. The three branches each shipped clean. I steered the architecture around the loop, not the code inside it.

The dispatch went out as three parallel opencode run invocations, not three subagents. I asked for that change when the opencode TUI failed on the first attempt and the right path was to skip the interactive layer. I also argued for splitting the release prep out from the fix work, because trying to do both in the same dispatch kept blocking on the release-manager hitting its timeout before the fix branches landed.

What this loop replaced

My previous loop was one PR at a time. I'd describe an issue to the agent. The agent would open a PR. I'd skim it, sanity-check the decisions, merge or push back. One issue, one PR, one round of skimming. Repeat.

For this kind of small mechanical work, that's fine. It works. But the context switching adds up. Each PR is its own session — its own dispatch, its own transcript, its own review pass. The overhead is small per PR and large per backlog.

The new loop:

1. Describe the backlog.
2. Wait.
3. Skim the batch of PRs.
4. Push the release prep.

The release prep runs alongside the fix work instead of after it. One description covers all of them.

I want to be careful about what I'm claiming here. I'm not claiming the subagents did better work than the agent would have done one PR at a time. Most of these issues were mechanical. The interesting decisions — which redundancy to deprecate, which naming to standardize — the agent would have surfaced them either way, given the brief. What I'm claiming is that the per-PR overhead moved out of my hands and the interesting decisions stayed in my hands.

Reading at the end, not in the middle

I did not read the code while it was being written.

In the old loop, I skimmed each PR after the agent opened it. One PR at a time.

In the new loop, the skim happened after the writing finished across all three PRs. The subagents were the feedback loop during the work. I was the feedback loop at the end.

There's a different cost structure. A wrong fix in the old loop was caught in the per-PR skim, or it shipped. A wrong fix in the new loop is caught in the batch skim, or it ships.

I shipped none of the wrong fixes in this batch. The issues were mechanical and the code area was small. If I'd asked the subagents to redesign the normalise function, I would have read every line, pushed back, rewritten pieces.

The loop works for the kind of work that has a clear right answer. The loop does not work for the kind of work that needs taste. I haven't found the line yet.

For this batch, the line was "moves stuff around, adds JSDoc, narrows types." Below the line, I delegated. Above the line, I didn't. The line is in a different place than I would have guessed.

Running it again

I'm going to run this loop again. On a different repo. On a different kind of work.

I want to see what happens when the issues aren't mechanical. I want to see where the line moves. I want to see what kinds of work I delegate that I later wish I hadn't, and what kinds I keep that the loop could have handled.

I'm not going to delegate design decisions. I'm not going to delegate "what should this library do". I'm going to delegate "make this library do what it already says it does, correctly."

The batch skim at the end is non-negotiable. That's the part I own.

OpenCode works with any OpenAI-compatible API. Straico gives me access to Claude, GPT, Gemini, DeepSeek, and a bunch more through a single API key. Cheap too. Problem is, Straico's API is missing two things OpenCode needs: streaming responses and function calling.

Without streaming, OpenCode just hangs. Never gets a response. But Straico keeps eating tokens on their end anyway. Without function calling, the AI can't use tools like reading files or running bash commands. Both are non-negotiable for an agentic coding tool.

So I built a proxy. It sits between OpenCode and Straico, translating requests and responses to fill in the gaps.

OpenCode
  → localhost:8000 (my proxy)
    → Straico API

What started as "just simulate streaming and inject tool definitions" turned into a surprisingly full-featured thing. The codebase is at github.com/ManningWorks/DOAI-Proxy.

The Architecture I Ended Up With

I didn't start with a provider pattern. I started with four files: server.js, streaming.js, tools.js, utils.js. But once I started thinking about adding other providers down the line (OpenAI direct, Anthropic direct), I refactored into something cleaner.

The provider pattern lives in providers/. BaseProvider is an abstract class that handles the interface contract and retry logic. StraicoProvider extends it with Straico-specific request/response transformation. ProviderFactory instantiates the right one based on the PROVIDER_TYPE env var.

Right now only Straico exists, but the factory already has stubs for OpenAI and Anthropic. The ADDING_PROVIDERS.md doc in the repo lays out how to add a new one.

The other modules:

• server.js - Express server, routing, auth, request lifecycle
• streaming.js - SSE simulation with two modes
• tools.js - Tool injection and response parsing
• utils.js - Logging, formatting, log rotation
• utils/model-limits.js - Fetches context limits from Straico's API
• summarizer.js - Conversation summarization for long sessions
• scripts/sync-opencode-config.js - Syncs model list to OpenCode config

Streaming Without Streaming

Straico returns the full response at once. No SSE. No chunks. The proxy has to fake it.

Two modes: none and smart.

none is what I'd recommend as default. It sends the entire response in one SSE chunk, then the [DONE] marker. Fast, no formatting issues, still technically SSE.

smart is more interesting. It splits the response into chunks with delays to simulate real streaming. The naive approach is responseText.match(new RegExp('.{1,15}', 'g')) and that kind of works. But it breaks markdown. Split mid-bold, mid-code-block, mid-backtick and the rendering glitches.

So smartChunkText() in streaming.js looks for safe boundaries. It prefers splitting on newlines, then whitespace. It also checks for markdown delimiters (**, __, \``, `` ``) and extends the chunk to avoid splitting them. There's a max size limit (targetSize * 10) to prevent infinite extension.

// streaming.js - simplified version of the boundary logic
for (let i = end; i > start; i--) {
  if (text[i] === '\n') {
    return i + 1;
  }
}
for (const delim of ['**', '__', '```', '`']) {
  const delimStart = text.indexOf(delim, start);
  if (delimStart !== -1 && delimStart < end) {
    const delimEnd = delimStart + delim.length;
    if (delimEnd > end) {
      return Math.min(delimEnd, text.length, start + maxSize);
    }
  }
}

Default is 15 characters per chunk with 80ms delay. That feels about right for most models. Configurable via STREAM_CHUNK_SIZE and STREAM_DELAY_MS env vars.

I set STREAM_MODE=none as the recommended default. smart works but it's more of a showcase thing. The boundary detection catches most cases but I wouldn't trust it with complex nested markdown.

Function Calling via Prompt Injection

Straico doesn't support function calling natively. The workaround: inject tool definitions into the system prompt and parse the AI's response to detect tool calls.

injectToolsIntoSystem() in tools.js appends a formatted list of available tools to the system message:

You have access to the following tools:
- bash: Run bash commands
- read: Read file contents

When you need to use a tool, format your response like this:
TOOL_CALL: <tool_name>
ARGUMENTS: <json_arguments>

There's a sentinel comment (<!-- proxy-tools-injected -->) to prevent double-injection if the same messages get processed twice.

The tricky part is parsing. Different models output tool calls in different formats. I ended up with four parsers that run in sequence:

1. Minimax XML - <minimax:tool_call> with <invoke> tags
2. Claude XML - <invoke name="..."> with <parameter_list> tags
3. OpenAI Native - JSON with "tool_calls": [...] embedded in the response
4. Text Format - The TOOL_CALL: / ARGUMENTS: format from the injection prompt

Each parser tries to extract tool calls from the response text. The first one that succeeds wins. This was a gradual thing. I started with just the text format parser. Then Minimax models returned XML. Then Claude models returned different XML. Then some models returned JSON that looked like OpenAI's format. Four parsers later and it handles most cases.

The text format parser was the hardest to get right. Matching TOOL_CALL: tool_name ARGUMENTS: {json} seems simple until the JSON contains nested objects, strings with braces, or the model forgets the space between the tool name and ARGUMENTS. The implementation tracks brace depth to find where the JSON actually ends:

for (let i = argsStartIndex; i < responseText.length; i++) {
  const char = responseText[i];
  if (char === '{') braceCount++;
  else if (char === '}') {
    braceCount--;
    if (braceCount === 0) {
      argsEndIndex = i + 1;
      foundClosingBrace = true;
      break;
    }
  }
}

The proxy also validates tool calls against the list of available tools. If the model invents a tool that doesn't exist, it gets filtered out. If all tool calls are invalid, the response is treated as regular text.

Tool Call Streaming

OpenCode expects tool calls to arrive as SSE chunks, same as regular text. streamToolCalls() in streaming.js sends an init chunk with the tool name and ID, then an args chunk with the arguments, then a final chunk with finish_reason: 'tool_calls'. Each chunk has a small delay (20ms, 10ms, 20ms) to feel like actual streaming.

Conversation Summarization

This one sneaked up on me. Straico has model context limits. Some models have 8k tokens, some have 128k. OpenCode sends the entire conversation history with every request. In a long coding session, that history grows fast.

summarizer.js checks if the estimated token count is approaching the model's limit. When it hits a configurable threshold (default 70% of the model's word_limit), it takes all but the most recent messages, sends them to Straico for summarization, and replaces them with a single summary message.

The summarization itself uses Straico's smart_llm_selector with pricing_method: balance, so it picks a cheap model for the summary. Configurable via SUMMARIZATION_MODEL.

I'm still not 100% sure this is the right approach. The summary is lossy. Sometimes the model needs context from earlier messages that the summary glossed over. But without it, long sessions just fail with context limit errors. Tradeoff.

Model Limits and Validation

utils/model-limits.js fetches all available models from Straico's /models endpoint at startup. It caches their context limits (word_limit) and max output tokens (max_output). The proxy uses this to validate incoming requests. If estimated_input_tokens + max_tokens > word_limit, it rejects the request with a 400 error before even hitting Straico.

The model list is also exposed at /v1/models so OpenCode can discover what's available. There's an admin endpoint at /v1/admin/refresh-models to force a refresh if Straico adds new models.

The sync script (scripts/sync-opencode-config.js) goes one step further. It fetches the model list from Straico, then updates ~/.config/opencode/opencode.json with all chat-type models. The Docker entrypoint runs this script before starting the server, so the model list is always current.

Authentication

Four modes, controlled by AUTH_MODE:

• required - Needs PROXY_API_KEY, rejects requests without it. Default in production.
• optional - Uses the key if set, warns if not. Default in development.
• disabled - No auth. For isolated environments.
• external - Trusts an external auth header. For when the proxy sits behind an API gateway or service mesh.

The key comparison uses crypto.timingSafeEqual to prevent timing attacks. Took me a moment to realise I needed buffer length checks too, since timingSafeEqual throws if the buffers are different lengths.

Retry and Graceful Shutdown

BaseProvider.makeRequestWithRetry() wraps every API call with exponential backoff. Retries on 429, 5xx, and network errors (ECONNREFUSED, ECONNRESET, ETIMEDOUT). Default is 3 attempts with a 1-second base delay.

Graceful shutdown was one of those things I didn't think about until I ran into issues. When Docker sends SIGTERM, the proxy stops accepting new requests and waits for active ones to drain. There's a timeout (default 30 seconds) after which it force-exits. Without this, long-running streaming responses would get cut off mid-chunk when the container restarted.

Docker Setup

The Dockerfile uses node:18-alpine and an entrypoint script. The entrypoint runs the OpenCode config sync, then starts the server.

Docker Compose mounts two volumes. The .env file for config. And ~/.config/opencode so the sync script can write to the OpenCode config file.

volumes:
  - ./.env:/app/.env:ro
  - ~/.config/opencode:/root/.config/opencode

One thing I got wrong initially was the Dockerfile CMD. I had CMD ["node", "server.js"] which meant the config sync never ran. Switched to ENTRYPOINT ["/app/docker-entrypoint.sh"] and that fixed it. Small thing, but it meant every container restart would have stale model lists.

The Straico-Specific Quirks

Straico's API is mostly OpenAI-compatible but with some differences that caught me out.

Tool result messages use role: "tool" in OpenAI format. Straico doesn't support that role. The proxy converts them to role: "user" with a [Tool Result]: prefix. Same with assistant messages that contain tool calls. Those get converted to the text format the injection prompt expects.

Empty assistant messages get filtered out entirely. Some models return an assistant message with empty content before making a tool call. Straico chokes on those.

There's a TOOL_RESULT_MAX_LENGTH env var that truncates large tool outputs. Some tool results (file reads, command output) can be massive. Without truncation, they blow out the context window and the next request fails.

The proxy also normalises messages. OpenAI sends content as arrays of objects (text parts, image parts, system reminders). The proxy flattens those into plain strings and strips out <system-reminder> tags. Straico doesn't know what to do with the array format.

What I'd Do Differently

The provider pattern is solid but I'd start with it from the beginning rather than refactoring into it. The four-file structure worked fine until I wanted to add features that crossed module boundaries. The abstraction would have saved me some reshuffling.

The smart streaming mode is neat but I'd think harder about whether it's worth the complexity. The boundary detection handles most markdown but not all edge cases. none mode is faster and more reliable. I use none day to day.

The summarization feature is the part I'm least confident about. It works, but the lossy compression means sometimes context gets dropped at exactly the wrong moment. I might revisit this with a sliding window approach instead of a hard summarize-and-replace.

Where It Stands

The proxy handles:

• All 90+ Straico models through a single endpoint
• Streaming simulation (both modes)
• Function calling with four parser strategies
• Conversation summarization for long sessions
• Model context validation
• Authentication with four modes
• Retry with exponential backoff
• Graceful shutdown with request draining
• Docker deployment with automatic model sync

It runs on my machine and OpenCode talks to it at http://localhost:8000/v1. Works well enough that I don't think about it most of the time. Which is exactly what a proxy should do.

The code is on GitHub if you want to look or use it. Or add a provider. The architecture supports it.

This tripped me up for way longer than it should have. (I'm running OpenCode v1.4 — permission behavior may differ in other versions.)

My Config

The release-manager agent handles version bumps, changelogs, and git tagging for my Projex project. Its config in .opencode/agents/release-manager.md had bash permissions like this:

bash:
  "grep *": allow
  "rg *": allow
  "cat *": allow
  "git log -- *": allow
  "git diff -- *": allow
  "git status": allow
  "*": ask

Looks reasonable. Specific commands are allowed, everything else asks. Except every single command was prompting. grep, git log, cat — all asking for permission.

The Problem

I re-read the config about five times. The rules were right there — "grep *": allow — clear as day. I tried shuffling the order around. Tried different wildcard syntax. Nothing worked.

Eventually I went back to the OpenCode permissions docs and actually looked at the examples. Every single one puts the catch-all "*": "ask" at the top. Mine was at the bottom.

Turns out OpenCode permission rules work on a "last matching rule wins" principle.

The "*" wildcard matches everything. Including grep. Including git log. So when OpenCode evaluates git log --oneline -20 against my config, both "git log -- *" and "*" match. Since "*" is listed last, it wins. Result: ask.

Every. Single. Time.

The fix was embarrassingly simple. Move the catch-all to the top:

bash:
  "*": ask
  "grep *": allow
  "rg *": allow
  "cat *": allow
  "git log -- *": allow
  "git diff -- *": allow
  "git status": allow

Now "*" matches first, but then "grep *" matches after and wins because it's the last matching rule. Specific overrides general. The way it should work.

I'd put the catch-all at the bottom out of habit — like a default case in a switch statement. I just... didn't read carefully enough.

The Second Problem

After fixing the ordering, grep worked fine. But git log --oneline -20 still prompted.

I tested a few more variations to narrow it down. git log -- somefile (with the path separator) matched. git log --oneline didn't. The difference clicked pretty fast after that.

The pattern "git log -- *" only matches commands that literally have -- in them. Like git log -- somefile. It doesn't match git log --oneline -20 because --oneline is a flag, not the -- path separator.

I'd been too specific. Changed to:

  "git log *": allow
  "git log": allow
  "git diff *": allow
  "git diff": allow
  "git status *": allow
  "git status": allow

Both forms — with and without arguments. The * wildcard matches zero or more of any character. So "git log *" covers git log --oneline -20. But the space before * is literal. The pattern requires "git log" followed by a space, then anything. A bare git log with no trailing space won't match it. That's why "git log" (no wildcard) is also needed.

The Third Problem

Even after both fixes, it still prompted. I'd been eyeing the tools field suspiciously since the start. The config had both the deprecated tools block and the newer permission block.

tools:
  read: true
  write: true
  edit: true
  bash: true
permission:
  bash:
    "*": ask
    "grep *": allow

The docs say tools.bash: true is equivalent to {"*": "allow"}. Having both tools and permission for the same thing seemed like it could cause conflicts — one saying "allow everything" and the other saying "ask for everything except these." I don't know exactly how OpenCode resolves this internally, but removing the tools block entirely fixed the remaining issues.

The Working Config

The final config for the release-manager agent looks like this:

---
description: Create releases following Projex's version bump, changelog, and git tagging workflow
mode: subagent
temperature: 0.1
permission:
  edit:
    "*": ask
    "packages/core/package.json": allow
    "CHANGELOG.md": allow
    "README.md": allow
    "packages/core/README.md": allow
    "packages/docs/**/*": allow
  bash:
    "*": ask
    "pnpm --filter * build": allow
    "pnpm --filter * lint": allow
    "pnpm --filter * typecheck": allow
    "pnpm --filter * test": allow
    "head *": allow
    "ls *": allow
    "ls -la *": allow
    "find *": allow
    "grep *": allow
    "rg *": allow
    "cat *": allow
    "tail *": allow
    "wc *": allow
    "wc -l *": allow
    "sort *": allow
    "uniq *": allow
    "git log *": allow
    "git log": allow
    "git diff *": allow
    "git diff": allow
    "git status *": allow
    "git status": allow
    "git tag *": allow
  webfetch: deny
  color: success
---

Three separate issues stacked on top of each other. Rule ordering, overly narrow patterns, and deprecated config conflicting with new config.

TL;DR

Three things I learned about OpenCode subagent permissions:

1. Catch-all goes first. "*": ask needs to be at the top of the permission block. Last matching rule wins.
2. Patterns need to match actual command syntax. "git log -- *" doesn't match git log --oneline. I had to use "git log *" instead.
3. Don't mix tools and permission. Removing the deprecated tools field fixed the remaining issues for me.

I fixed the same issues in my documentation-manager agent too. Both agents now run without prompting on every command. Which is how it should have been from the start.

The Escape Key Did Nothing

First problem: I hit Esc to interrupt an agent mid-task. Nothing happened. Just sat there. I hit Esc again. Nothing. The agent kept running.

I'm not sure what I expected tmux to do with Escape, but apparently it intercepts the key for its own bindings and there's a delay before the key reaches the application inside. I wondered if opencode had a bug or just didn't work well with opencode.

Then I searched "tmux escape key not working" and found set -g escape-time 10 which reduces that delay. Shorter would be faster but 10ms worked. After that, Escape actually reached opencode.

But that alone wasn't enough for clipboard to work.

Copying Text Was Broken

Selecting text in tmux with the mouse didn't copy to my system clipboard. I'd select, paste somewhere else, and get nothing. This is on WSL2 with Ubuntu on Windows — so I have WSLg, which is the Windows layer that lets Linux GUI apps run on Windows 11. But something was intercepting it.

I tried:

• Checking if WSLg was actually running — it was
• Googled "tmux clipboard copy not working wsl2 in opencode" — that's how I found most of the solution

What actually fixed it was adding these to my ~/.tmux.conf:

set -g escape-time 10
set -g mouse on
set -g set-clipboard on
set -g allow-passthrough on

set -g mouse on enables mouse mode so I can select with the mouse at all. set -g set-clipboard on is the key one. It's been around since tmux 2.9 and it handles clipboard integration properly. set -g allow-passthrough on lets applications inside tmux access the system clipboard without tmux intercepting it first. That last one seems particularly relevant for WSL setups, though it might help on other platforms too.

I'm running tmux 3.4 — From what I've reda these settings should work on tmux 2.9+, which covers most reasonable install paths in 2026.

To reload after changing tmux.conf, run tmux source-file ~/.tmux.conf.

Still Getting Used to It

I'm still getting used to the keybindings and functionality inside tmux. I'm still building the muscle memory. The clipboard issue was the biggest blocker, now that works, so the rest is just practice.

The other opencode posts (permissions trap, nested commands) don't mention tmux because I wasn't using it. Now I am, and now I know why people talk about these specific settings. It's quite nice having so much flexibility inside a single terminal window.

I'm genuinely not sure how anyone uses tmux without these settings. Maybe they were just magic configuration I never had.

I had two commands doing basically the same thing. One was my 4-agent blog review system—495 lines of voice validation, completeness checking, structure editing, and technical validation (I wrote about the full 4-agent system). The other was a wrapper that auto-selects the next post needing review, then calls the first command. 239 lines of tracking and selection logic.

What I Tried (and Why It Failed)

The wrapper command was supposed to be simple: /review-next-blog-post. This wrapper then called the custom slash command /review-blog-post-multi-agent @content/posts/specific-post on the "next" post to be reviewed in my list of posts, based on criteria I defined.

I tried different variations. Maybe the slash command syntax was wrong? Maybe I needed quotes or a different calling pattern? Still nothing. I spent way too long wondering why OpenCode was just... ignoring my nested command call.

Turns out OpenCode slash commands can't call other slash commands. Each command is like a separate executable. You can't have command-a trigger command-b from within command-a's definition.

The Realization

This actually makes sense—predictable behavior, no infinite loops, no command calling itself. But I didn't know that going in, and the lack of error feedback made the confusion worse.

I thought about a few options:

• Could I work around this somehow with some intermediate command?
• Maybe use the CLI tool to trigger commands?
• Wait—what if I just made one command do both?

The last option felt right. Instead of trying to make commands nested, I needed a single command that could operate in two different modes.

The Solution: One Command, Two Modes OpenCode's $1 argument system handles this perfectly:

**Auto-Selection Mode (no arguments):**
`/review-blog-post-multi-agent`

**Direct Review Mode (specific post):**
`/review-blog-post-multi-agent @content/posts/blog-post-slug.md` or `path/to/blog-post.md`

**Mode Selection Logic:**
- If `$1` is provided AND not empty → Direct Review Mode
- If `$1` is empty or missing → Auto-Selection Mode

If $1 is provided, use the file directly. If it's missing, run auto-selection. The command now does both modes in one place—finds the next post OR reviews the one you specify.

The Result

The consolidation was a net improvement: from 2 commands totaling 734 lines to 1 command with 632 lines. That's -102 lines while adding more functionality.

Here's what changed:

• Tracking logic: Moved from the wrapper command into project_docs/blog-review-tracking.json as reusable content
• Auto-selection logic: Now part of the main command instead of a separate wrapper
• Architecture: No nested dependencies—just one command that can operate in two modes
• Usage: I can run /review-blog-post-multi-agent for auto-selection OR /review-blog-post-multi-agent @content/posts/specific-post.md for direct review