Hermes × OpenCode: A Discord-Powered Build Dispatcher

I’ve been running coding agents for a while now. Hermes handles orchestration, planning, debugging, and research. OpenCode handles the actual code-writing — it’s faster, cheaper, and built for that one job. The friction wasn’t the tools. It was the handoff.

Every task required me to:

1. Open a terminal
2. cd to the right project
3. Remember the OpenCode flags
4. Type out the full task description
5. Wait for results
6. Context-switch back to whatever I was doing

Multiply that by 5-10 tasks a day across 3+ projects and it adds up. I wanted to post a task in Discord and have it executed — by the right tool, in the right directory, with results reported back to the thread.

This is how I wired it up.

The Architecture

Discord Forum: Builder Hub (#1511928369091055756)
│
├─ Thread "myapp"
│   User: "Build REST API for user management"
│   Hermes: 🚀 → opencode run → report
│
├─ Thread "backend"  
│   User: "Fix payment race condition"
│   Hermes: 🚀 → opencode run → report
│
└─ Thread "myapp"  ← same project, parallel!
    User: "Add health check endpoint"
    Hermes: 🌿 git worktree → opencode run → report

Hermes never writes code in this channel. It acts as a pure dispatcher — receiving requests, spawning OpenCode, and reporting outcomes. OpenCode does all the actual work.

The Config (Three Things)

Everything lives in ~/.hermes/config.yaml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

discord:
  free_response_channels: "...,1511928369091055756"     # ① Auto-respond
  channel_prompts:
    '1511928369091055756': |
      You are a Build Dispatcher — delegate ALL coding to OpenCode CLI.
      Thread names map to workdirs:
        myapp → ~/projects/myapp
        backend → ~/projects/backend
        sambal → ~/projects/sambal
      Parallel tasks on same project → git worktree isolation.
      Load forum-build-dispatcher skill for full workflow.       # ② Persona
  channel_skill_bindings:
    - id: '1511928369091055756'
      skills:
        - forum-build-dispatcher
        - opencode                                                   # ③ Skills

Three pieces:

1. free_response_channels — Hermes responds to every message without needing @mention. For a builder channel, you shouldn’t have to invoke a CLI to ask for code.

2. channel_prompts — Tells Hermes “you are a dispatcher, not a coder.” Critically, it includes the thread-name-to-workdir mapping so projects auto-resolve.

3. channel_skill_bindings — Auto-loads the forum-build-dispatcher skill (the workflow) and the opencode skill (the exact CLI commands and pitfalls).

The Dispatcher Skill

The forum-build-dispatcher skill is a markdown file at ~/.hermes/skills/autonomous-ai-agents/forum-build-dispatcher/SKILL.md. It defines the exact workflow Hermes follows for every message in the builder forum:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

## Workflow

### Step 1: Analyze the Request
- Extract task + auto-resolve workdir from thread name
- If workdir missing, ask the user

### Step 2: Acknowledge
"🚀 Delegating to OpenCode in <workdir>..."

### Step 3: Spawn OpenCode
opencode run '<task>' --thinking

### Step 4: Report Results
✅ Done in <workdir>
- Files changed
- Test results
- Status

The skill is what makes this more than a simple prompt injection. It has:

• Exact command patterns — build, fix, review, refactor each get the right flags
• Timeout guidance — 600s normal, 900s large tasks
• Pitfalls — no pty=true with opencode run, always set workdir, don’t chain commands
• Verification — check git diff, confirm tests passed
• Hard rule: never use write_file or patch — delegate only

Parallel Work on the Same Project

What happens when two threads target the same project simultaneously? Without isolation, both OpenCode instances would fight over the same files — git conflicts, lost work, chaos.

The dispatcher handles this with git worktrees:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# Hermes detects: another thread is on ~/projects/myapp
# Creates isolated worktree:
git -C ~/projects/myapp worktree add /tmp/hermes-myapp hermes/myapp-8f3a2

# Runs OpenCode in the isolated tree:
opencode run "Fix payment race condition" --thinking
# ...with terminal(workdir="/tmp/hermes-myapp", timeout=600)

# Reports branch for merging:
✅ Done in myapp (branch: hermes/myapp-8f3a2)
Merge: git merge hermes/myapp-8f3a2

Solo threads use the main workdir directly — no overhead. The worktree path only triggers when a second thread on the same project fires.

What It Actually Looks Like

Here’s a real interaction flow:

Two-minute turnaround. I didn’t touch a terminal, didn’t cd, didn’t remember flags.

Token Economics

The obvious question: does this cost more than using OpenCode directly?

With DeepSeek v4-pro at $0.14/1M input tokens, 10K extra tokens costs $0.0014 — about 1/7th of a cent. The system prompt caches across messages in the same thread, so subsequent tasks in a thread cost even less.

Compared to having Hermes write code directly (30-100K tokens per task), the dispatcher pattern is 3-10x cheaper in Hermes tokens. The coding work stays in OpenCode where it belongs.

Why Not Just Use OpenCode Directly?

You absolutely can. opencode run "build X" --thinking in the terminal is faster and cheaper for one-off tasks. The dispatcher isn’t about replacing that workflow — it’s about scaling it.

The dispatcher earns its pennies when:

• You’re juggling 3+ projects and don’t want to manage workdirs manually
• You want a central log of all build tasks (every thread = permanent record)
• You’re running parallel tasks that need isolation
• You want structured, consistent reporting per task
• You’re already in Discord and don’t want to context-switch

It’s a convenience layer, not a replacement.

What’s Missing

A few things I’d like to add next:

• Thread tags → workdir mapping: Discord forum tags aren’t currently surfaced by Hermes’ adapter (plugins/platforms/discord/adapter.py doesn’t extract applied_tags). Thread names work fine as a proxy, but proper tag support would be cleaner.

• Persistent worktree cleanup: Currently manual after user approval. A cron job to prune orphaned worktrees would be straightforward.

• Per-project skill customization: Some projects might want TDD enforced, others might want specific linting rules. Letting threads inherit project-specific OpenCode instructions from a config file in the repo.

The Files

Everything described here:

• Config: ~/.hermes/config.yaml — the three Discord sections above
• Skill: ~/.hermes/skills/autonomous-ai-agents/forum-build-dispatcher/SKILL.md — full dispatcher workflow
• OpenCode: ~/.opencode/bin/opencode (symlinked to ~/.local/bin/opencode), v1.15.13

That’s it. No new services, no databases, no webhooks. Just config, a skill file, and the tools already running.