Skip to content

AI coding workflow

SWE Forge

One focused ticket. One reviewable PR.

An opt-in, harness-agnostic path from one focused ticket to one reviewable PR. Ordinary prompts remain ordinary.

View on GitHubOpen source · MIT

A workflow above the coding harness

SWE Forge is an opt-in, harness-agnostic workflow for coding agents. It takes one focused coding ticket to one evidence-backed, reviewable PR through one writable delivery checkout. PR delivery is the default, and it never merges automatically.

A focused path from ticket to reviewable PR, with proportional validation and a fresh review when warranted. Ordinary prompts remain ordinary.

Start here

Install it where you work.

This installs the Pi projection at user level. The first alpha is planned, not yet published, so use the development checkout for now. Install one harness per invocation: Pi is first-class; OpenCode is compatible; OMP, Claude Code, Codex, and Cursor are experimental. Installation does not modify project configuration, harness settings, permissions, models, credentials, or ordinary prompts.

git clone https://github.com/joacod/swe-forge.git ~/tools/swe-forge
cd ~/tools/swe-forge
scripts/swe-forge install pi
scripts/swe-forge verify pi

Use it

Give it one focused ticket

Installation only makes the workflow available; it does not change ordinary prompts. Invoke it explicitly with one focused ticket. SWE Forge chooses the execution path and uses PR delivery by default; add guided when you want a human pause. Use /swe-forge in Pi, OpenCode, OMP, Claude Code, or Cursor, and $swe-forge in Codex:

/swe-forge add a loading state to the dashboard
/swe-forge guided fix the failing parser test
$swe-forge review the authentication change

Human review remains the boundary

PR mode can create one pull request after local gates; guided mode can stop at a reviewed local diff when delivery is not authorized. Neither mode merges automatically. Human PR review remains the final boundary.

What stays simple

  • Opt in per ticket; ordinary prompts remain ordinary.
  • Choose the smallest execution path with real value; topology stays internal.
  • Use proportional validation and fresh review when the ticket warrants it.
  • Keep one writable delivery checkout and never merge automatically.