forgedock

This repository builds itself with ForgeDock. In its first 30 days (June 4 → July 4, 2026): 693 issues filed, 605 closed, 603 PRs merged — median 56 minutes from open to merged-and-closed. 57% of those issues were filed by the pipeline itself; 49% are findings its own review agents raised, filed, and then fixed. Every run leaves a public audit trail — click through the receipts, or count them yourself:

gh issue list -R RapierCraftStudios/ForgeDock --state closed --limit 1000 --json number --jq 'length'

A single run, up close — a real one, issue #1230:

$ /work-on #1230        "orchestrate: Layer 5 co-change signal is dead code"

  ✓ investigate    CONFIRMED/HIGH — feature shipped 3h earlier (PR #1204) reads a
                   never-populated variable; the co-change query can never fire
  ✓ build          fix branch, 1 file
  ✓ review         caught a defect in the fix itself: stray backticks in the grep
                   meant every git-log pathspec silently matched zero commits —
                   "the fix would not have actually worked." Corrected.
  ✓ merged         30m 37s → staging

  filed by the pipeline's own staging review. fixed before a human read it.

Try it in 30 seconds — on a throwaway repo, nothing to lose

Requires for this demo: Claude Code (subscription or ANTHROPIC_API_KEY) · GitHub CLI (authenticated) · Node.js ≥ 18.

npx forgedock demo     # spins up a risk-free demo repo and shows you the pipeline end to end

Ready to use it for real? npx forgedock walks you through one continuous setup: it checks your environment, installs the slash commands, reads your repo, and hands you a single annotated forge.yaml to review — you press Enter once.

⭐ If ForgeDock saves you time, star the repo — it's the whole marketing budget.

---

Your AI coding agent forgets everything after every session. It re-explores the codebase from scratch, re-makes mistakes that were already fixed, and has no idea why the code it's touching looks the way it does. ForgeDock fixes that by making GitHub itself the memory — every pipeline stage writes structured findings that every later agent reads.

Without ForgeDock vs. With ForgeDock

Without ForgeDock	With ForgeDock
Agent starts every session blind — no context from prior work	Agent reads structured investigation, root cause, and history straight from GitHub
The same bugs get reintroduced across PRs	Review agents surface known pitfalls from past PRs before you commit
A crash or compaction loses the run	State lives on GitHub and in an event-sourced run log — the pipeline resumes where it stopped
You write the issue, plan the fix, open the PR, and review it	/work-on #42 → investigated, built, reviewed, merged
Review depends on whoever has capacity	9 domain-specialist agents (security, billing, DB, concurrency…) review every PR
One task at a time, serialized by your attention	/orchestrate runs a whole milestone — many issues in parallel, each its own full pipeline

---

The idea in one paragraph

AI agents have no lookback. They don't know a function was shaped by a bug fix in #347, that an approach was tried and reverted in PR #891, or that three other files need the same change. Context window isn't the bottleneck — memory is. But GitHub already stores everything an agent needs: commits, PRs, issues, blame, cross-references. It's a citation graph; agents just don't use it as one. ForgeDock makes every stage write machine-readable annotations to issues and PRs, and every downstream agent read them. The gh CLI becomes the query interface to institutional memory. The result: agents that follow structured data, not vibes.

┌──────────────────────────────────────────────────────────────────┐
│                     GITHUB (Knowledge Graph)                     │
│                                                                  │
│  Issues:  FORGE:INVESTIGATOR → FORGE:CONTEXT → FORGE:ARCHITECT   │
│           → FORGE:TRAJECTORY (the run's full audit trail)        │
│  PRs:     FORGE:BUILDER → structured review FINDING blocks       │
│  Links:   git blame → commit → PR → issue → related issues       │
│                                                                  │
│  Every agent reads this. Every agent writes to it.               │
│  Nothing is lost between conversations.                          │
└──────────────────────────────────────────────────────────────────┘

---

Watch the machine work

Not a staged demo — these are real, public runs on this repository. Open any of them and read the full trail:

• #1230 — the pipeline's staging review caught dead code in a feature the pipeline had shipped three hours earlier; review then caught a bug in the fix itself. Intent to merged: 30 minutes.
• #1172 — review found an ANTHROPIC_API_KEY exfiltration path in the headless runner (an in-process file read bypassed the env scrub), with exact line evidence. Fixed and merged in 18 minutes, with regression tests. A later re-review found a second-order bypass of the first fix (#1243) — the pipeline red-teams its own fixes.
• #952 — the investigator closed the pipeline's own proposal as INVALID with receipts: the deliverable had already shipped weeks earlier. Zero code written, 34 minutes, full explanation.
• #1256 — decomposition that respects the existing graph: it created only the two net-new sub-issues no open issue already claimed, then sequenced three existing issues into the dependency order.
• #1322 — a heavyweight feature (the durable execution engine itself): 9 TDD tasks, whole-branch review caught two Criticals pre-merge, merged in under 2 hours.

And the part that makes it compound — the context phase citing past bugs by number before a line is written (from #1196):

"commands/orchestrate.md has a dense review-finding history from PR #1081/#1107/#1126… associative-array declaration mistakes (#1113), array-element removal via pattern substitution corrupting partial matches (#1108)… the new Layer 5 subsection should not introduce a competing edge-direction convention that could reintroduce a cycle class."

Numbers on this page are point-in-time (2026-07-04), from this repository's first 30 days of dogfooding. A reproducible cost-per-issue benchmark is a hard gate on our own launch plan — #1264: no estimated efficiency claims.

---

Orchestrate an entire milestone

/work-on ships one issue. /orchestrate ships a milestone. It decomposes the milestone into dependency-ordered waves and runs a full /work-on pipeline on each issue in parallel — investigating, building, reviewing, and merging many at once, while GitHub labels track every agent's state live. On this repo's record day, that meant 29 issues taken to merged inside a single hour.

Scheduling is conflict-aware before it is parallel. Five detection layers decide what may run concurrently: same-file overlap, directory proximity, shared-module fan-in, a conservative fallback when file extraction is low-confidence, and historical co-change coupling mined from git log — files that changed together in the past are assumed to conflict now. Database-touching issues are always serialized. The resulting graph is cycle-checked (Kahn's algorithm) and executed in topologically sorted waves; overlapping work is expressed as ordinary Depends on #N edges anyone can read.

/orchestrate milestone/checkout-v2     # decompose → conflict-aware waves → merged PRs

---

How it works

Each stage reads the structured output of the stages before it and writes its own findings back:

Issue → Investigate → Context → Architect → Build → Quality Gate → Review → Merge
              └──────────── each stage reads & writes GitHub ────────────┘

Stage	Reads	Writes
Investigate	Issue body, git blame, related issues/PRs	FORGE:INVESTIGATOR — verdict, root cause, affected files, severity
Context	Historical findings from related PRs, known pitfalls	FORGE:CONTEXT — institutional memory for this module
Architect	Investigation + context	FORGE:ARCHITECT — ordered plan, code paths, risks
Build	Everything above	FORGE:BUILDER — branch, commits, files changed
Quality Gate	Builder output, domain-specific checks	gate results, recorded in the run's trajectory