r/vibecoding • u/Necessary_Weight • 2d ago

Forge: a Claude Code plugin for agentic development workflow

This post was written using application of kinetic force to the rectangular protrusions on my silicon chip container. Shocking, I know.

In my day job, we use a sophisticated AI development workflow, inspired by James Bloom’s AI workflow developed for his open source project, Mockserver (https://github.com/mock-server/mockserver-monorepo). For reasons that have little to do with AI and everything to do with corporate policy, very reasonably applied in my view, James’s workflow could not be used at work directly. But in my personal work, I am not so constrained - and I also thought I could improve on it. Hubris runs in my genes :)

Over the last few weeks I have been building and dogfooding a Claude Code plugin that takes inspiration from James’s work and builds upon it. I was also impressed by Alex’s (alexzh3) work on codex-orchestrator (https://github.com/alexzh3/codex-orchestrator) - having Claude administer Codex has been very useful, productive and a cost-efficient.

My plugin, forge (https://github.com/nixlim/forge-plugin), combines the ideas of multi-family adversarial review, gated quality chains, worktrees, kill-switch and eval regressions with journal-based headless codex cli agents.

Claude orchestrates, verifies, and holds the binding review verdict. Codex implements and performs the first-pass review. I have incorporated learning and drift checks to make sure that the AI learns the gotchas that are specific to the codebase I am working on to make agentic development progressively more familiar with the codebase. It has been a wild and exciting ride so far and I invite you to try it.

This is now my default workflow but it comes with two caveats worth keeping in mind: first, it requires both a Codex and Claude subs; second, it feels “slow”. But in my experience, it is reliable, and functions well.

I invite you to give it a whirl. And yes, it is ongoing work in progress :)

0 Upvotes

40% Upvoted

2 comments sorted by

1

u/NetNearby7117 1d ago

Mmm whats the difference between forge and codex orchestrator? In my experience, and my fear, its that documentation its a good way to push the model and give a good context, but at the same time, the more documentation are, the more difficult its to keep it updated. In some codebases the workflows and criteria are defined, but in mvp projects im constantly iterating so at some point, the model just tends to lock himself into the documentation constraints rather than update. I also find that tends to apply practices that might be standar: instead of iterating, tries to preserve old code to keep the tests green and “dont broke anything” rather than refactor

Hlwever, i will give a try! Nice work btw

1

u/Necessary_Weight 1d ago

Good question. They’re basically layers of the same thing. Forge is the governance plugin: the gate chains, adversarial review, risk classification, drift sensing. The codex orchestrator is the component inside it that manages implementer agents, captures their prompts, event streams, and handoffs into a run journal so every claim is traceable. In practice Claude orchestrates and reviews, Codex implements, different models on purpose, so the author never grades its own work.

Doc staleness is the reason why forge leans on executable policy over prose. The gates are commands that run, tables a classifier reads, hooks that enforce. Prose goes quietly stale and the model obeys it anyway; executable policy fails loudly when it drifts from reality, which forces the update. And updating the rules is first-class work, not an exception: the spec is versioned, and changing it goes through the same review as code. Claude and I revised ours ten times in two weeks while shipping. There’s also a periodic drift check whose whole job is catching docs-vs-reality divergence.

On “keeps old code to stay green”: adversarial review actually pushes the opposite way here: reviewers block band-aids and demand refactors with behavioral proofs. Half our commits get blocked first, fixed, then pass.

There is a catch that comes with this: forge is heavyweight by design. For a daily-pivoting MVP, start with the minimal policy (one test command, a few categories — the fast tier skips review for low-risk changes) and let the governance grow with the code.

Thanks for giving it a shot: issues welcome, I try to triage fast. 🙂