For sure. Here's a quickstart guide for you.
First things first get opencode installed https://opencode.ai/ and connected to your provider (works with almost everything except Claude Max).
Then the workflow is like this for each repo (both greenfield and existing):
1. Create an opencode.json in the repo root. opencode.json is the harness config. It tells the system what provider/model endpoint to use, which instruction files to load, what the default agent is, what specialist agents exist, and which slash commands route to which agent/workflow. For now, it can be very simple and barebones.
2. If you have any existing CLAUDE.MD or AGENTS.MD files you like to use, you can point them in opencode.json as "instructions" key. So here's a sample config (or look at https://opencode.ai/docs/config/)
{
"$schema": "https://opencode.ai/config.json",
"instructions": ["AGENTS.md"],
"default_agent": "build",
"agent": {
"coordinator": {
"description": "Lead coordinator",
"prompt": "This will be the prompt for your coordinator agent",
"agents": [
"componentA_build",
"componentA_meta"
]
},
..."
3 [the most crucial step]. Create a plan of how the repo is structured to feed back into the harness so it can generate its own tailored config.
Of course, this is where your own critical thinking comes in. You're going to be prompting the default agent to start extending this opencode.json to fit your project. I found that most models are relatively poor at sussing out the "why" of an existing codebase - they are much much more focused on the how and what.
So much like how companies ship their org chart, with gen AI code you ship your architecture. If you don't have a good mental model of how the game should work (not that it HAS to be working that way now, but how it should be), then you won't go anywhere. If you can provide the "why", that is the connective tissue that really makes the difference.
For instance, lets say you are working on a railroad simulation game with a modular architecture - there's one central "GameController" which references submodules like "CityController", "TrainController" and so on. You'd then want to create agents that specialize in things like cities, trains, railroad, building, etc with a high level "coordinator" agent that has access to every subagent (as defined in the "agents" key). And then you get to the fun part of making higher-order agents - so an agent that specializes in game balance that has CityAgent, TrainAgent, GameAgent etc as sub agents, "RouteAgent" that has RailroadAgent, TrainAgent etc that specializes in efficient routing calculations and so on.
I found that in this step it helps just to braindump into a scratch pad and just write out as much as you can at a high level how it all operates and the architecture and the agents you want. Having a defined OUTPUT is the most important part of the agentic process and prompting. Key things I have in this braindump:
a. Architecture overview, both "actual" and "idealized" versions (what do we want the end game to look like e.g. a full-fledged train sim with stock market and city building - even if currently its just an isometric map with some buttons on it).
b. Core components of the system
c. Key file locations, any workflows like processing images, audio etc for game
d. Any design decisions and whatnot you made that aren't captured in code or documented (e.g. "I'm basing the economy off of XY Game")
One thing that's VERY helpful at this phase is having the default agents ("Build" and "Plan" with OpenCode) go through and document all the code and as much as it can into a docs folder if you don't have that already.
4. Take that braindump and feed it back in OpenCode and tell it to modify its opencode.json to have agents to handle all the components and architecture. Tell it to parallelize and delegate as much as possible.
5. It'll output a new opencode.json. Restart opencode and go wild.
As you work with the harness, you'll get the nuances of how the agents are interacting and what needs some tweaking but the key here is to always keep the feedback loop going. Tell the agents to always update docs after committing code and to always read the docs before doing anything etc etc. This is key to making sure the agents don't go off-rails.
Eventually you'll see the meta-patterns you like and create scripts to e.g. autogenerate this kind of harness for any repo you encounter. I don't have one "source of truth" opencode.json but rather a base template and then a python script that does all of the above automagically for my workflows.
The key insight here, I think, is like learning Lisp. The harness IS code, agents ARE Code - they can be modified as needed dynamically and adapted. They are first-class citizens and can be composited like functions or chained together like graphs. The map is the territory. Once I realized that I could prompt the harness to modify itself and do all the things to itself that it does to the codebase, things really took off for me.
Anecdata disclaimer: This workflow might not fit everyone's mental coding model. Adapt as needed. I use literally dozens of these kind of harness configs every day at work, including meta-harnesses with code review of harnesses and EvalOps. Been doing so for about six months now. I'll also note we are very serious about performance and feature degradation but with this approach we've had less rollbacks and regression than in the previous five years.