SpecForge turns what your organisation knows into rules your AI can't skip.
You write down your things, how they link, and the rules they must obey. SpecForge compiles that into one typed, checked graph. People and AI agents read it and change it through standard protocols (CLI, MCP, LSP), and a change that breaks a rule is refused, whoever made it.
It works for software specs, product plans, quality procedures, or any field with rules worth checking. SpecForge doesn't know your field until you install an extension that teaches it.
The problem
AI can now do real work: write code, draft a launch plan, prepare a batch record. What it works from is the weak part.
The knowledge that should guide it sits in places nothing enforces:
- Documents and specs in prose (PRDs, Markdown specs, policies, brand guides). An agent can misread a rule or skip it, silently. Nothing checks that the document is complete or that its parts agree.
- Wikis and decks drift away from reality, and nothing breaks when they do.
- Traceability (which requirement has a test, which procedure has an approval, which campaign has a source for its claim) is a spreadsheet someone updates by hand, until they stop.
- Every session starts from zero. The agent re-reads dozens of files to rediscover what you meant, and still guesses.
The more work you give to AI, the worse this gets. It produces faster than anyone can review.
This isn't a problem with the model. It's a problem with where your rules live.
The idea: hard skills, not soft skills
There are two ways to teach an AI how your organisation works.
A soft skill is advice placed in the AI's context: a prompt, a Markdown spec, a policy PDF, a skill file. It helps, but it's prose. The AI may follow it, or not.
A hard skill is a rule a program enforces. The AI can't skip it, because the check fails and says why.
SpecForge is an engine for hard skills. Think of it as a type checker for what your organisation means.
The five parts
These extensions ship inside the binary, as a starter set:
Turn one on with specforge add @specforge/product. The full list is in the
extension inventory. To teach SpecForge your own field, see
Extending SpecForge and the extension SDK.
What you can build with it
- Software spec frameworks. The builtin software extensions already give agents a checked spec to build
against, with tests that name the promise they prove. Methods like GSD, BMAD, OpenSpec and SpecKit are a
vocabulary plus rules, so each can become an extension, with its state in checked entities instead of
Markdown files. A GSD family (
@gsd/*) is being designed; the others are not started. - Product and marketing. Personas, channels, journeys, features and releases in one checked map that an agent can report from ("which channels does this persona use?", "what is unscheduled?"). Campaigns, audiences and claims can be added with your own extension.
- Regulated industries. Pharma (GxP), medical devices, safety cases: procedures, deviations and approvals with the rules an auditor expects, in version control and checked in CI. The AI drafts, the rules check, a qualified person signs. You write this extension yourself today; none ships yet.
- Your own domain. Any business with entities and rules worth checking. SpecForge can be the product you use, or the harness the business runs on: extensions as its domain, the graph as its memory, AI models as its workers.
The use cases say what works today and what is roadmap for each, and examples has projects you can run.
See it in 60 seconds
No agent needed. Install, create a product plan, then try to break it:
curl -fsSL https://raw.githubusercontent.com/leaderiop/SpecForge/main/install.sh | sh
mkdir launch-plan && cd launch-plan
specforge init --extensions @specforge/product # a persona, a channel, a journey, a milestone
specforge link onboarding channels email # point the journey at a channel that doesn't exist
error[E080]: the edit would leave the project with 1 error it does not have; nothing was written
error[E003]: unresolved reference 'email' in entity 'onboarding'
The edit is refused and nothing is written. Declare the channel first, and the same edit goes through:
specforge new channel email "Email newsletter" --in spec/hello.spec --description "The monthly newsletter" --status active
specforge link onboarding channels email
specforge product persona-channels developer # cli, email
An agent makes the same edits over MCP, and gets the same refusals. Hand-written files get the same check:
mkdir ../sf-demo && cd ../sf-demo
specforge init --extensions @specforge/software # spec/hello.spec, which checks clean
sed -i.bak 's/\[user_logged_in\]/[user_loged_in]/' spec/hello.spec # drop one letter
specforge check
[E003] Error: unresolved reference 'user_loged_in' in entity 'authenticate_user'
20 │ produces [user_loged_in]
│ Help: did you mean 'user_logged_in'?
[W007] Warning: event 'user_logged_in' is not produced by any behavior
1 error, 1 warning, 0 infos
A reviewer reads. A check resolves. Errors always fail the check; warnings fail it too with
specforge check --strict, which is what you run in CI.
Use it with your agent
1. Install. SpecForge is a single binary with no dependencies.
curl -fsSL https://raw.githubusercontent.com/leaderiop/SpecForge/main/install.sh | sh
# Homebrew (once the tap is published)
brew install leaderiop/tap/specforge
# Prebuilt binary via cargo-binstall
cargo binstall --git https://github.com/leaderiop/SpecForge specforge-cli
# From source (stable Rust toolchain)
git clone https://github.com/leaderiop/SpecForge && cd SpecForge
cargo install --path crates/surfaces/cli
Prebuilt archives for macOS, Linux and Windows are on the Releases page. Formal proofs (@specforge/formal) also need the z3 solver on your PATH; everything else works without it.
2. Create a project with the extensions your work needs:
specforge init --extensions @specforge/software,@specforge/product
This writes a specforge.json and a first file in spec/. In a Cargo or vitest project, it also turns on the
matching test runner.
3. Connect your agent. SpecForge speaks MCP, so any MCP client can read, query and edit the graph. Use an absolute path:
claude mcp add specforge -- specforge mcp /path/to/your/project
In Cursor, one click adds it for the open project (${workspaceFolder}):
{
"mcpServers": {
"specforge": { "command": "specforge", "args": ["mcp", "/path/to/your/project"] }
}
}
4. Ask your agent. For example:
Write a spec in
spec/for the feature I described: the behavior, the rules it must never break, the events it emits, and what proves each one. Validate it with the SpecForge tools and fix every error before you show it to me.
5. Read the result yourself.
specforge check # is the graph consistent?
specforge review # what is still unproven?
6. Link your proof. For software, each test names the entity and obligation it proves. Follow the
Rust or vitest guide, then run
specforge collect. It asks once before running your test command, and records what each test proves.
Do I have to learn a new language?
You'll want to read it, because the graph is what you approve. You rarely need to write it: your agent
writes and fixes the files, or edits them through specforge new, set and link, and the check tells it when
it's wrong.
It's built to be easy to read. Each block is one thing, with a kind, a name, a title, and fields, like a filled-in form:
channel email "Email newsletter" {
description "The monthly newsletter"
status active
}
To write specs by hand, start with the authoring tutorial, the worked example and product getting started.
Surfaces
Not built yet, so not claimed: connections to outside systems (a CRM, an issue tracker, a quality system), and proof beyond test results. Extensions are pure WASM today: no files, no network.
How is this different from…
What SpecForge is not
- Not an AI. It makes no model calls. It's a deterministic compiler, written in Rust. The AI is yours.
- Not a generator. It checks knowledge. Your agent produces the work.
- Not a test framework. Your tests stay in
cargo testor vitest. SpecForge runs them only after you approve the command, and records what they prove. - Not only for software. Software is one of its biggest uses, not its definition.
Learn more
- Vision: why SpecForge exists, its principles, the north star and the use cases.
- Authoring tutorial: writing
.specfiles from zero, with a cookbook, best practices and troubleshooting. - Extending SpecForge: teach it your field, with the extension SDK.
- Test tracing for Rust and for vitest: link tests to the entities they prove.
- Formal verification: specs an SMT solver checks, with counterexamples at exact locations.
- Quick reference: every command, entity kind and diagnostic code on one page.
- Architecture, the crate map and Contributing: how SpecForge is built, what each crate owns, and how to work on it.
- Documentation hub: everything else.
License
Licensed under either of Apache License, Version 2.0 or MIT license at your option.