ForgeDock

From GitHub issues to reviewed, tested, merged changes, autonomously.

ForgeDock runs AI coding agents through validation, implementation, review, CI and merge, one issue per lane, many lanes in parallel. Every step is recorded on GitHub, so runs survive crashes, later agents build on earlier ones, and you can audit everything.

📖 Documentation · Try it · Evidence · What works today

What it does

You file issues. ForgeDock turns each one into a merged pull request:

issue → validate → plan (frozen contract) → implement → review → PR → CI → merge

• One lane per issue, many in parallel. forgedock orchestrate schedules a batch from the issues' Depends on #N lines, runs up to K lanes at once, and recovers the mechanical failures itself (CI red, merge conflicts, engine errors). It asks you only about product, spend, credentials and releases.
• Durable. Each lane records its state on the issue and in a crash-safe run log. Kill it, restart it, or lose the session: it resumes from what GitHub says, and two lanes never own the same issue.
• Checked, not trusted. Each change is held to a contract frozen before implementation. It must pass a separate review (which blocks on unimplemented requirements and regressions) and CI. On paths you mark as risky, the full contract-conformance gate also blocks. Before anything reaches your default branch, a staging review with a panel of domain reviewers (security, concurrency, auth, CLI, regression risk…) must post a gate marker.
• GitHub is the memory. Findings, decisions and trajectories are written as structured comments that later lanes read. Nothing lives only in a chat window.

ForgeDock orchestrates delivery. It does not replace the model: it runs on your Claude Code account and resells no compute.

Try it in 30 seconds

Needs: Claude Code (subscription or ANTHROPIC_API_KEY) · GitHub CLI (authenticated) · Node.js ≥ 18.

npx forgedock demo     # creates a throwaway repo and runs the pipeline end to end

To use it on your own repo:

npm install -g forgedock      # the CLI and the durable engine
forgedock                     # checks your environment, installs the commands, writes a forge.yaml for you to review
forgedock run-issue 42        # one issue, start to merge
forgedock orchestrate 41 42 43 --parallel 3    # a batch, scheduled from its Depends-on lines

Inside Claude Code the same flows are /work-on 42 and /orchestrate. All install options (plugin marketplace, OpenCode, headless/CI) are in Install.

The evidence

ForgeDock is built with ForgeDock. Every number below is from this repository's public history and you can recount it.

Last 30 days (2026-09-24 → 2026-10-23)
Issues filed / closed	800 / 784
Pull requests merged	613
Issues that are the pipeline's own review findings	396 (about half)
Issue opened → merged and closed, median	2 h 19 min (p25 55 min, p75 10 h; 475 issues)
Since 2026-06-04: PRs merged / releases	1,961 / 85

gh api -X GET search/issues -f q="repo:RapierCraftStudios/ForgeDock is:pr is:merged merged:2026-09-24..2026-10-23" --jq .total_count

Runs you can open and read end to end:

• #1230: the staging review found dead code in a feature shipped three hours earlier, then review caught a bug in the fix itself. 30 minutes from issue to merge.
• #1172: review found an ANTHROPIC_API_KEY exfiltration path in the headless runner; fixed in 18 minutes with regression tests. A later review found a bypass of that fix (#1243).
• #952: the pipeline closed its own proposal as invalid, with receipts: the work had shipped weeks earlier. No code written.
• #4442: a large feature split into six dependent sub-issues (#4448–#4453) that the batch runner built in dependency order.

What the gates caught

The staging review runs before every release. The releases of 2026-10-22 and 2026-10-23 alone stopped these defects before they shipped. Each was found by a reviewer, filed, fixed by a lane and re-verified:

Caught	What would have shipped
#4465 (HIGH)	Merge-conflict resolution silently dropped a lane's edits to any file named like 404-page.tsx, then skipped tests and re-review
#4468 (HIGH)	The acceptance probe could run a command quoted inside a bot-authored issue on the operator's host
#4470	The open-findings release gate passed when every GitHub read failed
#4501 (HIGH)	Issues reopened after a merge (e.g. by a failed production probe) were skipped forever
#4516	A dependency-parser fix turned prose like "see #99" into blocking edges

What still goes wrong

Lanes fail. What matters is how they fail. A lane that cannot finish ends with a typed outcome (ci.red, base.conflict, budget.exceeded, needs-human…). Mechanical ones are retried automatically, and the rest wait for a person with the evidence attached. Bugs are tracked in public, for example a lane whose checkpoint push was rejected (#4505) and a dependency-line regex that backtracked on long whitespace (#4517), both since fixed. Outcome codes are documented in OUTCOME-CODES.

How it works

A lane takes one issue through a fixed sequence. The engine, not the model, decides the next step:

1. Validate: is the issue real and still open work? Already fixed or invalid issues are closed with evidence and no code.
2. Plan: the builder proposes requirements, and the engine freezes them as a contract.
3. Implement: one builder session in an isolated worktree, which checks itself with the repo's own commands.
4. Review: a separate reviewer checks the diff against the contract and looks for regressions. Fix rounds run in a fresh, narrow session.
5. PR, CI, merge: the lane waits for the required checks, syncs with the base branch if it moved, and merges. Deferred items become tracked follow-up issues instead of silent gaps.

A batch (forgedock orchestrate) is a scheduler over lanes. It reads Depends on #N edges, keeps K lanes busy, shares slots across repos on the host, holds admissions when an account hits its usage limit, and survives restarts: lanes are detached processes and a daemon re-adopts them.

A release promotes staging to your default branch only after the staging review posts a FORGE:GATE_PASS marker that CI checks.

Deeper: How it works · GitHub is your agents' memory · FORGE annotation protocol · Architecture

What works today

	Status
Runtime	Claude Code (CLI or subscription). OpenCode is supported with documented parity limits.
Forge	GitHub only (issues, PRs, labels, Actions).
Branching	Lanes merge into a staging branch (or milestone/*); a reviewed release promotes staging to the default branch.
Runtime test gate	Runs your configured integration tests before a release; it reports SKIP until you configure verification.integration_tests.
Light lane (one-session mode for small issues)	Ships in shadow mode: it records what it would do. The gaps found before enabling it (#4502) are closed; light.mode: on is opt-in.
Human decisions	Product direction, spend, credentials, customer-facing actions and releases are always escalated, never decided by an agent.
Cost	Runs on your Claude account. forgedock stats --efficiency reports $/merge, turns/merge and retries by cause.

Docs

• Getting started · Install · Configuration · Command reference
• Troubleshooting & recovery · Outcome codes · Stats
• Start a new project · Comparison with other approaches · Release eval scorecards

For companies

The core is AGPL-3.0 and stays that way. A commercial license is available for proprietary use, and an org-wide fleet layer is in development with design partners. See ForgeDock for companies or write to support@rapiercraftstudios.com.

Contributing: PRs welcome, with conventional commits (fix(scope):, feat(scope):). License: AGPL-3.0.

_{ForgeDock is unrelated to ForgeRock's identity platform. Using it? A star is the whole marketing budget.}