forge
Align Claude Code to your org and its operational model.
forge is a generator. It interviews your organization — which tools you run, which process shape you're held to, and how your org actually works (how agents communicate, under what identity they act, what gates and autonomy govern them) — and emits a standalone, org-owned Claude Code plugin that makes agent-driven development behave like a member of your org.
forge v2 is a generator, not a scaffolder. The full design lives in docs/GENERATOR.md — the authoritative north star. Some of v2 is still being built; v0.1.x ships the v1 flow.
Two levels, kept separate:
- forge — the generator (shared, eventually open source, the same tool everywhere). Everyone improves it upstream: adapters, methodology bundles, operating-model facets, runtime templates.
acme-forge — the generated package (org-owned, private, distributed internally). Your tools, your operating model, your compliance regime, baked in. Teams stamp projects from it.
forge@Acme ≠ forge@Globex by design — same generator, different answers to the interview. Nobody forks forge; to upgrade, an org re-runs the generator over its config and re-emits.
A Claude Code plugin. /forge:emit interviews your org and writes the package; inside that package, /forge:new <codename> stamps a per-project wiki using the org's pinned tools and operating model.
What forge emits when you /forge:emit
A standalone, org-owned Claude Code plugin (acme-forge) — the artifact your org installs and distributes. It contains:
- Its own
.claude-plugin/plugin.json + marketplace.json (org-namespaced; for internal distribution).
- The pinned adapters for the org's real tools (tracker / SCM / chat / CI) — not re-chosen per project.
- The operating model — how your org's agents behave (comms, identity, gates, autonomy), rendered from the interview into a constitutional wiki chapter + machine-checkable rules.
- The org brain seed — one durable wiki (operating model + accumulating tribal knowledge) with a project layer (
projects/<codename>/).
- The single-orchestrator workflow runtime —
.claude/workflows/*.js the master orchestrator invokes; role archetypes (implementer / reviewer / architect / wiki-maintainer) run as distinct subagents, not human-run sessions.
- The relocated
/forge:new (opens a project subspace), /forge:doctor, /forge:configure.
Then, inside the package, /forge:new <codename> opens a per-project subspace in the org brain using the org's pinned tools and operating model.
Method
forge is opinionated about how agents work together (the method) and unopinionated about which tools they use (the adapters) and how each org works (the operating model). The full v2 design is in docs/GENERATOR.md; the universal method below survives from v1, re-expressed for the workflow runtime.
The method (universal)
- Karpathy schema — three layers (raw sources / wiki / schema), now federated across an org-wide layer and per-project subspaces; code-as-truth holds at both.
- Six role archetypes — orchestrator, architect, implementer, reviewer, wiki-maintainer, migration-analyst. The boundaries survive; the delivery vehicle changes from separate sessions to distinct subagents inside workflows.
- Three skill verbs —
prime (calibrate), dispatch (now: invoke a workflow), wiki (propose / ingest / lint / query, gaining capture / promote for tribal knowledge).
- No-self-review — preserved by context isolation between distinct subagents (the reviewer sees the diff, never the implementer's reasoning), not by separate terminals.
- One orchestrator + dynamic workflows — a single long-lived orchestrator spawns workflows; the durable substrate (org brain + tracker + SCM) survives crashes.
The adapters (per-org)
| Layer | Shipped | Planned |
|---|
| Tracker | gitlab · github · jira-single · jira-multi · jira-mcp · linear | asana |
| SCM | github · gitlab | bitbucket |
| Chat | slack | teams · discord |
| CI | github-actions · gitlab-ci | circleci · jenkins |
| Cloud | — (informational only; forge doesn't provision) | azure · aws · gcp notes |
Each adapter declares: required CLIs, optional MCP servers, and skill snippets that get substituted into the stamped prime / dispatch skills.
Lifecycle: generate, distribute, re-generate
