An Agent Agnostic Loop Harness

The loop

You type a command and the agent loads the skill for that stage. A run takes an issue with sub-issues, works each one in its own worktree, reviews every pull request it opens, and hands them back to you to merge.

Before a run

1. /rubber-duck

   Think a design through before any code exists.

2. /specify

   Turn an idea into a spec when issues need a decision first.

3. /decompose

   Cut an idea or spec into issues and their sub-issues.

4. /triage

   Rank the board into a dispatch plan.

One run per issue

/thunderstorm runs this for each sub-issue, in a worktree of its own

1. /implement

   Work one issue on its own branch and open a pull request.

2. /rev, then /adv-rev

   A review pass in a session of its own: standard, then adversarial.

3. /revise

   Address what the pass returned and push the fixes.

Review, then revise, three times over. A small issue gets one pass.

A person merges

The loop stops at the pull request. Merging and approving are denied to it; you decide what lands.

What tstorm enforces

A skill is an instruction, and an agent can ignore one without anyone noticing. tstorm, the binary the loop ships with, checks the parts that have to be true, and a check that fails leaves a result you can read afterward.

Commits you can read in a year

The workflow follows written guidelines for commits, pull requests and prose, and they are plain files a person can read and edit. One of them is checked at every commit: a message needs a type and a subject under 60 characters, and any body wraps at 72 columns.

Merging stays yours

Nothing the loop does lands code without you. It opens pull requests and stops there: merging, approving and a bare push are denied to the agent, and a check tells you if your repository has left one of them open.

Workers do not collide

Work that runs in parallel gets separate working copies, so one worker's edits never reach another's files. Each worker gets a git worktree of its own, made by the run outside your repository, and a check fails any skill that asks the agent to make one instead.

Three harnesses, one workflow

Each agent reads skills from its own directory and names commands its own way. The loop is written once and rendered for each, so all three get the same stages and the same review sequence.

Claude Code

claude plugin marketplace add stormlightlabs/thunderstorm
claude plugin install thunderstorm@stormlightlabs

Installs as a plugin. Each stage is a slash command, and review passes run as subagents.

Codex

codex plugin marketplace add stormlightlabs/thunderstorm
codex plugin add thunderstorm@stormlightlabs

Installs as a marketplace plugin. Each stage is a $thunderstorm: skill, and review passes run as built-in agents.

Pi

pi install git:github.com/stormlightlabs/thunderstorm

Installs as a Pi package. Each stage is a prompt, and each worker runs in a tmux or Zellij tab of its own.

Try it on one issue

Install the loop into the agent you already use and hand it an issue. What comes back is a pull request that has already been reviewed, and merging it is your call.

Start here Install it Source