forge

A harness-agnostic code-change workflow. Your request gets planned, the plan gets attacked, the code gets written with tests, and a panel of reviewers shoots at it before you ever see it. One markdown core, thin per-harness adapters — Claude Code, codex, opencode.

Install

/plugin marketplace add alp82/forge
/plugin install forge@alperortac
/forge:setup-forge

The setup runs once, plugin-prefixed; it installs the bare command names, so from then on it's /setup-forge everywhere. Plugin updates propagate on their own — no re-run needed. Upgrading from alp-river? Three steps in the 2.0.0 changelog entry.

Also on codex (codex plugin marketplace add alp82/forge — runs gated, the same stop-gate as Claude Code; see the codex adapter) and opencode (paste the install brief into a session — runs guarded: git-write guard and idle nudge, no stop-gate, since opencode can't block a session from ending; see the opencode adapter).

Use

One verb. Describe the change you want in your own words.

/forge add rate limiting to the public API
/forge #482                    # or point it at a ticket
/crossfire                     # review what's already there

See it run

One request, end to end — the markers on the timeline are the stage boundaries.

The plan gets attacked

Before a line is written

A second agent's only job is to break the plan — and with a worker CLI on PATH, a different model attacks it too. Cheapest possible place to be wrong.

 /forge add rate limiting to the public API

planner    → .forge/rate-limit-public-api/plan.md
challenge  ✗ BLOCKER
   per-process buckets break under 3 gateway replicas — every client
   quietly gets 3× the limit. Redis sliding window or sticky routing;
   the plan proves neither.
   worker concurs — also flags the missing Retry-After on 429.
planner    plan v2: Redis sliding-window counters, Retry-After on 429
 Gate — Approve   open concerns become known risks
Green gets audited

Tests that actually prove something

The red tests come before the code, and a reviewer hunts for the one that would still pass with the feature deleted. False green is worse than red.

test-author  4 tests written · all red ✗
test-review  ✗ misaligned
   test_limit_resets still passes with the limiter deleted —
   it asserts on the mock clock, never on the 429.
test-author  rewriting the flagged test
test-review  ready — 4 red tests prove the behavior. Code starts now.
implement     tests 4/4 green · receipt.md
Crossfire

Reviewers that don't confer

Independent lenses hit the diff at once, each carrying one thing only, blind to the others. Also runs standalone as /crossfire on any diff, branch, or file set.

The whole machine

Seven stages, six hooks, no hidden layer. Pick any stage: what it does, what it reads and emits, the brief that drives it — and ten seconds of it running.

Reads
Emits
Brief
Words

With a worker CLI on PATH (codex, gemini, opencode), the challenge and the crossfire wave each get a different-model second opinion — read-only, failure visible, never blocking.

It can't skip the review

Prompts get forgotten under compaction; hooks don't. On a gated harness (Claude Code, codex) forge ships the full enforcement layer — six hooks on Claude Code — and if code changed and the review never ran, the session refuses to end. Where the harness can't block a session from ending (opencode, guarded), the same hooks still guard writes and nudge the unreviewed diff. The guarantee degrades by tier — loudly, never in silence.

It's just markdown

No agent definitions, no config language, no signal vocabulary. Every stage is a markdown file you can read in one sitting and edit with your own opinions — start at skills/forge/SKILL.md. The plugin is a delivery mechanism, nothing more.

Works with your tracker

Point /forge at a ticket and it reads the ticket as the request, then posts the verdict back and closes it. No tracker? Nothing is missing — the contract lies dormant.