entelligentsia.in/open-source/forge
⚡ Quick Start · 📦 Install · 📡 Distribution · 🚀 Get Started · 📖 Philosophy · 🔁 Default Flow · 📖 Commands · 🏗️ Architecture · 🔧 Customise · 🐛 Report a Bug
Forge is software that adds a self-building SDLC to Claude Code — installed and managed by the 4ge command-line tool, not a marketplace plugin. Run it once on any project — it reads your stack, generates a complete set of project-specific agents, workflows, deterministic tools, and a structured knowledge base, then deploys them as slash commands. Every sprint, the system learns from what it builds and gets sharper.
One CLI. One init. A full engineering practice that improves with every task.
Forge is not a Claude Code plugin — it is software that adds pluggable features to Claude Code. The
4geCLI scaffolds Forge's commands, tools, hooks, and knowledge base directly into your project (4ge init claude .) and removes them just as cleanly (4ge uninstall claude). The same CLI also runs the full Forge SDLC headless on other runtimes. See Distribution. The marketplace install still works but is deprecated in favour of4ge init.
Forge is not for every project. It is designed for non-trivial software with real accountability requirements. If you are building a small script, a one-page website, or creating content, Forge adds process without benefit. See Philosophy for the full positioning.
Version 1.0 targets solo engineers. Team collaboration and project visualization are in active development.
1. Install the Forge CLI (once, works across all your projects):
npm install -g @entelligentsia/forgecli2. Add Forge to your project:
cd /path/to/your/project
4ge init claude .This scaffolds Forge into the project in seconds — zero tokens, zero network, pure file copy.
3. Generate your project-specific knowledge base:
# open Claude Code in the project, then:
/forge:init
No config files to fill in. Review lines marked [?] in engineering/ before your first sprint.
4. Run your first sprint:
/forge:new-sprint # Capture sprint requirements in a structured interview
/forge:plan-sprint # Break requirements into tasks with estimates and dependencies
/forge:run-sprint S01 # Execute — Plan → Review → Implement → Review → Approve → Commit
/forge:retro S01 # Close the sprint and feed learnings back
That's it. Forge handles the rest.
→ Full command reference · Getting started guides
Claude Code is capable. But left unstructured, it:
- Re-learns your project conventions from scratch every session
- Writes code without a second set of eyes — no plan review, no code review
- Has no memory of past decisions, bugs, or architectural tradeoffs
- Produces inconsistent results across tasks because there's no shared standard
The more complex your project, the worse this gets.
Forge runs once against your codebase and generates a complete, project-specific engineering practice — then deploys it as a multi-agent team 
Forge doesn't ask you to fill in a config file. It reads your codebase — routes, models, tests, CI pipeline, auth patterns — and generates personas, workflows, and review criteria that reflect how your project actually works. The Engineer persona knows your entity names. The Supervisor knows your security patterns. The Architect knows your deployment constraints.
Every completed task feeds the knowledge base. The Supervisor adds new patterns to the review checklist when it catches something worth catching again. The Bug Fixer tags root causes and builds preventive checks. The Retrospective agent promotes what's working and prunes what isn't. By Sprint 3, the system understands your project better than any static prompt ever could — and it keeps improving.
Forge generates everything in your language and adapts to whatever framework you're running. It makes no assumptions about your stack until it reads it. Where popular stacks have well-established best practices — Django migrations, Vue Composition API, Rails conventions — Forge's generated workflows encode those opinions explicitly. Everything else is derived from what it finds.
Forge is deliberately opinionated about what an LLM should and shouldn't do. Repeated, mechanical operations — collating sprint artifacts, seeding the task store, validating schema integrity — are generated once as deterministic tools in your project's own language and reused forever. Burning context tokens on tasks a script can do reliably is wasteful computing. Forge doesn't do it.
The knowledge base is not a monolith. It is intentionally decomposed into focused documents — one for routing, one for the entity model, one for the stack checklist, one per architecture area. When an agent needs context, it loads exactly the relevant section and nothing else. This keeps every agent fast, focused, and cheap to run — and it gets sharper as the knowledge base matures.
Forge agents don't load your entire codebase into context on every task. They work from the curated local knowledge base built during init. Agents read exactly what they need for the task at hand. This keeps context lean, responses accurate, and costs predictable as the project grows.
/forge:ask is Forge's concierge agent — answer questions about your architecture, your entities, your conventions, or what to do next. Ask "what now?" after init and it responds with context-aware next steps based on your project state.
Forge is a living system — and it gets better with yours. When something breaks or behaves unexpectedly, /forge:report-bug turns your experience into a structured GitHub issue in seconds. It reads your Forge version, project stack, and OS automatically, interviews you for the details that actually matter, drafts the report in the standard Forge bug format, and files it to the Forge repository with one confirmation. No copy-pasting error messages into a browser form.
Every bug report feeds directly into the Forge meta-definition — the same source that generates your SDLC. Patterns reported by users become better specs, better guard-rails, and sharper smoke tests for everyone running Forge. The system that learns from your project also learns from you.
During init, Forge checks the Claude Code marketplace for skills relevant to your stack — LSP intelligence for your language, framework-specific best practices, API integration skills. Already-installed skills are wired directly into generated personas: the Supervisor for a Vue project knows to invoke vue-best-practices before reviewing a component. New gaps surface in /forge:health so your tooling stays current as the project evolves.
Prerequisites: Node.js 18+ and Claude Code v1.0.33+
Recommended — the 4ge CLI:
npm install -g @entelligentsia/forgecli
cd /path/to/your/project
4ge init claude .4ge init deterministically scaffolds Forge into the project — commands, deterministic tools, hooks, schemas, and the dynamic-workflow drivers — from a version-pinned bundle, in seconds, with zero tokens and zero network. /forge:init, /forge:health, /forge:rebuild, and /forge:report-bug are then available in that project. Remove it any time with 4ge uninstall claude (your store and knowledge base are preserved unless you pass --purge).
Marketplace install (sunset — migrate to the CLI)
The Claude Code marketplace plugin is being sunset. As of v1.5.0 it is a shim: running /forge:init (or /forge:update / /forge:rebuild) walks you through migrating to the CLI-first install, and the following release drops the plugin distribution path entirely. Use 4ge init for all new projects — see Distribution. Existing plugin installs keep working and migrate by running 4ge init claude . (idempotent; preserves your config, store and KB).
# Stable
/plugin marketplace add Entelligentsia/skillforge
/plugin install forge@skillforge
# Canary
/plugin marketplace add Entelligentsia/forge
/plugin install forge@forge
Forge is software that adds pluggable features to Claude Code — not a Claude Code plugin. That distinction drives how it ships.
A marketplace plugin is a passive bundle Claude Code loads. Forge is not passive: it scaffolds project-specific software into your repository — deterministic .cjs tools written in your project's own conventions, hooks wired into .claude/settings.json, JSON schemas, a structured knowledge base, and the JS dynamic-workflow drivers that orchestrate every task. That is an install-and-generate operation, not a plugin load. The 4ge CLI owns it:
4ge init (recommended) |
Marketplace (deprecated) | |
|---|---|---|
| Install | npm i -g @entelligentsia/forgecli → 4ge init claude . |
/plugin marketplace add … → /plugin install … |
| What lands | Version-pinned bundle scaffolded into the project — auditable, in your git history | Plugin loaded into Claude Code's plugin directory |
| Tokens / network at install | Zero — pure file copy | Plugin fetch |
| Determinism | Exact, pinned payload version | Marketplace ref resolution |
| Removal | 4ge uninstall claude (preserves your store + KB) |
/plugin uninstall |
| Runtimes | Claude Code and headless on other runtimes | Claude Code only |
The CLI is also the product surface for running Forge outside Claude Code: the same @entelligentsia/forgecli package runs the full plan → review → implement → review → approve → commit pipeline headless on the pi runtime, against the provider of your choice.
Sunset notice. The skillforge marketplace distribution is being sunset. v1.5.0 is the shim release — the plugin's commands now redirect to the CLI, and
/forge:init//forge:update//forge:rebuildcarry a consent-gated migration to4ge. The following release drops the plugin distribution path (dual-path code strip). New installs should use4ge init claude. Existing installs keep working and migrate by running4ge init claude .in the same project — it is idempotent and preserves your config, store and KB.
Choose the guide that matches your situation:
| I want to… | Guide |
|---|---|
| Onboard an existing codebase into Forge | Existing project → |
| Start a new project with Forge from day 1 | New project → |
| Try Forge with a sandbox project | Onboarding with testbench → |
| Understand the core concepts | Concepts → |
| Understand why Forge works this way | Philosophy → |
| Follow the recommended flow step by step | Default flow → |
| Learn how the orchestrator, store, and collation work | Architecture → |
| Adapt Forge pipelines and workflows to my team's process | Customising workflows → |
| Migrate from v0.x to v1.0 | Migration guide → |
Forge operates on a strict containment model: Project → Features → Sprints → Tasks.
graph TD
Project(Project) --> Feature
Feature(Features) --> Sprint
Sprint(Sprints) --> Task
Task(Tasks) -. spawn .-> Bug(Bugs)
Sprint -. feed .-> Retro(Retrospectives)
Retro -. feed .-> KB(Knowledge Base)
The general lifecycle is:
/forge:init → review engineering/ → /forge:new-sprint → /forge:plan-sprint → /forge:run-sprint → /forge:retro
/forge:init scans your codebase and runs automated phases (~10–15 min):
| Phase | What happens |
|---|---|
| 1. Discover | Reads your stack, routes, models, tests, CI config |
| 2. Marketplace Skills | Checks installed skills, recommends marketplace additions for your stack |
| 3. Knowledge Base | Generates engineering/ — architecture docs, entity model, review checklist |
| 4. Personas | Generates Engineer, Supervisor, Architect identities specific to your stack |
| 5. Skills | Generates skill definitions wired to your stack |
| 6. Templates | Generates plan, review, and retrospective document formats |
| 7. Workflows | Generates 16 agent workflows wired to your actual commands and paths |
| 8. Orchestration | Assembles the task pipeline and sprint scheduler |
| 9. Commands | Creates /new-sprint, /plan-sprint, /run-sprint, /run-task, etc. in .claude/commands/ |
| 10. Tools | Generates collate, validate-store, seed-store, manage-config in your project's language |
| 11. Smoke Test | Validates everything connects; self-corrects if needed |
| 12. Tomoshibi | Generates the concierge agent for project queries |
After init, each sprint task runs through the full pipeline automatically:
flowchart LR
P["Engineer<br/>Plan"] --> RP{"Supervisor<br/>Review Plan"}
RP -->|revision| P
RP -->|approved| I["Engineer<br/>Implement"]
I --> RC{"Supervisor<br/>Review Code"}
RC -->|revision| I
RC -->|approved| V{"QA Engineer<br/>Validate"}
V -->|issues found| I
V -->|passed| AP["Architect<br/>Approve"]
AP --> CM([commit])
style RP fill:#f5a623,color:#000
style RC fill:#f5a623,color:#000
style V fill:#9b59b6,color:#fff
style AP fill:#4a90e2,color:#fff
.forge/ Config, workflows, templates, task/sprint/bug store
engineering/ Architecture docs, entity model, stack checklist, sprint history
.claude/commands/ Slash commands: /new-sprint, /plan-sprint, /run-sprint, /run-task…
engineering/tools/ collate, validate-store, seed-store, manage-config (in your language)
Lines marked [?] in engineering/ are items Forge wasn't certain about — review and correct them before your first sprint.
Full lifecycle documentation — inputs, outputs, gate checks, revision loops, and diagrams — lives in the 📖 command reference.
| Command | What it does | Reference |
|---|---|---|
/forge:new-sprint |
Architect interviews you and produces structured sprint requirements | → |
/forge:plan-sprint |
Breaks requirements into tasks with estimates and a dependency graph | → |
/forge:run-sprint SPRINT-ID |
Executes all sprint tasks in dependency waves | → |
/forge:retro SPRINT-ID |
Closes a sprint and feeds learnings back into the knowledge base | → |
| Command | What it does | Reference |
|---|---|---|
/forge:run-task TASK-ID |
Drives a single task through the full pipeline end-to-end | → |
/forge:fix-bug BUG-ID |
Triage, root-cause, and fix a bug with knowledge base writeback | → |
| Command | What it does | Reference |
|---|---|---|
/forge:init |
Bootstrap a complete SDLC instance from your codebase | → |
/forge:health |
Detect stale docs, orphaned entities, missing skills, and run --fix for maintenance |
→ |
/forge:status |
Show current sprint, task statuses, and recent activity | → |
/forge:ask |
Ask Tomoshibi about project status, config, workflows, or version | → |
/forge:rebuild [target] |
Refresh workflows, templates, tools, or knowledge-base docs | → |
/forge:update |
Propagate a Forge version upgrade into project artifacts | → |
/forge:add-pipeline [name] |
Add or manage a custom task pipeline in .forge/config.json |
→ |
/forge:add-task |
Add a task to an existing sprint mid-flight | → |
/forge:search |
Query the Forge store by natural language or exact flags | → |
/forge:repair |
Diagnose and repair corrupted store records | → |
/forge:check-agent |
Verify an agent has loaded and understood the project KB | → |
/forge:config |
Inspect or change project config | → |
/forge:remove |
Remove Forge artifacts from the current project | → |
/forge:report-bug |
File a bug against Forge — gathers context and opens a GitHub issue | → |
Every release is scanned with /security-watchdog:scan-plugin before
publication. Reports are filed as versioned artifacts in
docs/security/.
Forge adapts to any codebase Claude Code can read. Tools are generated in your primary language; workflows are universal Markdown.
Python · TypeScript / JavaScript · Go · Ruby · Rust
Frameworks detected automatically: Django · FastAPI · Flask · Express · Next.js · Nuxt · Vue · React · Rails · Gin · Echo · Actix · Axum — and anything else in the repo.