The agentic coding workflow I use in OpenCode

I did not build Propulsion because I thought the world was crying out for Yet Another AI Coding Workflow. The world, in fairness, is not short of those.

I built it because I kept overriding other people’s good ideas until my AGENTS.md turned into a loft full of half-useful boxes. I started from Jesse Vincent’s Superpowers, because the workflow discipline is excellent. Then I kept nudging things to suit how I actually like to work in OpenCode. Then I kept nudging some more. Eventually the file that was supposed to be lean steering became a dumping ground for preferences, process, and the occasional mild tantrum.

What I wanted was simpler: the power of Superpowers, the brevity of Matt Pocock’s skills, and enough room to make the workflow feel like mine. That is what Propulsion became.

This post is not a pitch for you to copy my setup line for line. It is a walkthrough of the workflow I use in OpenCode, what each step does, why each step exists, and why I think the best agentic coding workflow is usually a personal one. Borrow the shape if it helps. Ignore the bits that do not fit your brain.

The problem was not the model, it was the shape of the work

One thing AI coding tools are very good at is eagerly doing the wrong thing at speed.

If you hand an agent a vague request and enough tools, it will often reward you with immediate motion. Files change. Tests run. Something that looks like progress happens. But early motion is not the same as good direction. Quite often it is just the fastest route to a convincing mistake.

OpenCode gives you the raw ingredients to shape that behaviour: project and global rules through AGENTS.md, reusable skills, specialised agents and subagents, custom commands, and plugins. That flexibility is exactly why I like it. It is also why you need opinions. Without them, you do not really have a workflow. You have a very capable improviser.

That was the real issue I was trying to solve. Not “which model should I use?” but “what sequence of decisions gives the model the best chance of doing sensible work?”

Why I stopped stuffing everything into AGENTS.md

AGENTS.md is useful. In OpenCode it is the obvious place for project-level guidance, command order, repo quirks, and the kind of durable context future sessions will need.

The trouble starts when you treat it as the home for absolutely everything.

That is what I did for a while. I wanted to override defaults from other workflows. I wanted stricter routing. I wanted different prompts. I wanted better approval gates. I wanted more opinionated debugging. All perfectly reasonable. But when every preference ends up in one giant steering file, the file stops steering and starts rambling.

That was the turning point for me. I did not need a longer rules file. I needed a better separation of concerns.

So the workflow became:

• keep AGENTS.md lean,
• move reusable behaviour into skills,
• use stages to control when different instructions appear,
• and make approval points explicit.

That sounds almost boring. Good. Boring is underrated when you are trying to keep an LLM honest.

How Propulsion fits into OpenCode

Propulsion is a compact skill set for agentic coding, with an OpenCode plugin install path. Installation is intentionally simple:

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": ["propulsion@git+https://github.com/moonpixels/propulsion.git"]
}

From there, the core path is opinionated and staged. Route software work first, send product-scope work through brainstorm, write a PRD, turn it into a plan, execute in thin slices with an objective implementation-review loop, and debug concrete failures from evidence instead of guesses.

That sequence matters more than any individual prompt. It gives the agent a job at each point instead of one giant instruction blob that says “be wise”. Models are not consistently wise. Structure helps.

The stages I use, and why they exist

Route first

The first Propulsion rule is blunt: if the request is software work, route it into the workflow before anything else. No repo scan first. No “let me just quickly inspect a few files”. No helpful half-answer.

That sounds fussy until you have watched an agent lock onto the wrong frame in message one and spend the next twenty minutes being confidently unhelpful.

Routing first matters because the opening move sets the tone for the rest of the session. If the first instinct is “start coding”, you will usually get coding-shaped thinking. If the first instinct is “work out what sort of problem this is”, the rest of the session improves.

Brainstorm

In Propulsion, feature-shaped or product-scope work enters through brainstorm. That stage loads interrogation, inspects the project for relevant facts, and asks questions one at a time until the blocking branches are closed.

This is where Matt Pocock’s influence is obvious. His skills repo is full of small, crisp workflow ideas, and his question-by-question discovery style is something I wanted to keep. I like that rhythm because it stops the conversation becoming a fog of half-decisions.

Brainstorm writes a PRD, but the important bit is not the file. The important bit is that the workflow refuses to pretend the work is understood when it is not.

If you skip this stage, you tend to get one of two bad outcomes:

• the agent invents product decisions because silence looks like permission,
• or it implements the most obvious version of the request, which is not always the right one.

Both are expensive. Brainstorm is the stage that makes the work legible before anyone starts swinging a hammer.

Plan

Once the PRD is approved, Propulsion moves into plan. The job here is to turn intent into thin vertical slices with a clear downstream owner.

This is one of the habits I borrowed most directly from Superpowers. Jesse’s workflow places a lot of weight on forcing clarity before implementation, and on breaking work down into something an over-eager coding agent can follow without freelancing too much. That discipline is worth keeping.

I care about planning because it separates deciding from doing. Those sound similar until you ask an agent to do both at once. Then you discover that “implementation detail” has an unfortunate habit of silently becoming “product choice”.

Good plans also make review easier. If a phase is supposed to be a thin slice, you can tell when the agent has wandered off and built a cathedral.

Execute

Execute is where I part company with the “one smart agent can just handle it all” fantasy.

In execute, the main agent does not implement the work itself. It dispatches a fresh worker subagent for the current phase, then sends the result through a fresh reviewer subagent before marking the phase complete.

Why bother? Because self-approval is where a lot of agentic coding gets a bit silly.

The same model family can still play both roles, of course. I am not claiming magical independence. But changing the session, the framing, and the job to be done is often enough to surface things the worker slid past. The builder is trying to finish. The reviewer is trying to disprove. That tension is useful.

It also keeps the main thread cleaner, which matters more than it sounds. Context windows are finite, and if you let every implementation detail, dead end, and review note pile into one conversation, you burn tokens on noise. Splitting work into focused subagents helps keep each task narrow, keeps token usage lower, and stops the primary thread turning into an expensive attic full of irrelevant details.

The orchestrator tracks progress. The worker implements. The reviewer verifies. Different jobs, different context, less muddle.

Debug

Bug work gets its own lane. That is deliberate.

Propulsion’s debug stage is strict about creating a living bug dossier, reproducing the issue, reducing the failing case, grounding a diagnosis, and only then allowing a fix attempt. If the evidence changes, the loop resets.

I like this because bug fixing is where agents are most tempted to become superstition machines. Tweak a conditional. Re-run the test. Change another thing. Re-run the test. Eventually something passes and everyone pretends that counts as understanding.

It usually does not.

The debugging loop forces the workflow to earn the fix. And when the work changes observable behaviour, I also want a proper TDD loop in play, which is why Propulsion includes a dedicated TDD skill.

A tiny example of why the stages help

Say I ask for a new feature in OpenCode.

Add a customer export flow so finance can download invoices as CSV.

Without a workflow, an agent might jump straight to database queries, a route, a button, and a CSV response. That can look impressively productive right up until you realise no one decided:

• which invoices count,
• what date range rules apply,
• whether exports are filtered by account permissions,
• how large exports should be handled,
• or whether finance actually needed CSV rather than scheduled reports.

With my workflow, the request gets routed first, brainstormed into a PRD, sliced into a plan, and only then implemented. That sounds slower on paper. In practice it is usually faster than redoing a plausible but wrong first pass.

Agentic coding is full of this trade-off. A little friction up front saves a surprising amount of mess later.

What I borrowed, and what I changed

I want to be explicit here, because pretending these ideas appeared in a dream would be a bit much.

Propulsion explicitly credits Jesse Vincent’s Superpowers for workflow discipline, review loops, debugging process, and OpenCode plugin ideas, and Matt Pocock’s skills for brevity, wording discipline, and the question-by-question discovery style. That credit is deserved.

What changed is the shape.

I wanted something more compact, more OpenCode-first, and more opinionated around my own defaults. I did not want a giant all-purpose rules file. I wanted lean steering plus reusable skills. I did not want a workflow that felt impressive in a README but awkward in day-to-day use. I wanted something that matched how I think through work, where I tend to be too hasty, and where I need the agent to slow me down.

That last bit matters. The workflow is not only correcting the model. It is correcting me.

Your workflow should fit your brain

This is the actual point of the post.

I do not think developers should be stuck with my preferences, Jesse’s preferences, or Matt’s preferences. Those are useful starting points, not laws of physics.

If you are using OpenCode, Claude Code, Cursor, or anything similar, I think it is worth building a workflow that reflects:

• how you make decisions,
• how much ceremony you can tolerate,
• where you tend to rush,
• what your team needs to review,
• and which failures cost you real time or money.

You will learn more by trial and error than by importing somebody else’s setup and treating it as sacred. Watch where the model drifts. Notice which corrections you repeat. Turn those into skills, commands, or leaner rules. Keep the durable guidance in the right place. Let the workflow evolve from actual usage, not taste alone.

That is also how you learn something useful about how these tools behave. Not the deep internals in a research-paper sense, but the practical internals that matter day to day: routing changes outcomes, context shape changes outcomes, incentives change outcomes, and review framing changes outcomes. Once you see that, it becomes much easier to design a system that suits you.

Wrap-up

The agentic coding workflow I use in OpenCode exists because I wanted more than raw autonomy and less than a bloated rules file. Propulsion gives me a staged path: route first, brainstorm properly, plan in thin slices, execute with review, and debug from evidence. None of that is glamorous. It is just useful.

More importantly, it is mine. That is the bit I would encourage other developers to copy, oddly enough. Not the exact files, but the instinct. Build a workflow that matches how you work, where you make mistakes, and what you need your tools to be good at. If that journey starts with Superpowers, Matt’s skills, or Propulsion, great. Just do not stop at somebody else’s defaults.