SpecForge

See it in 60 seconds · How it works · What you can build · Docs

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.

| | Soft skill prompt, Markdown spec, policy, skill file | Hard skill SpecForge extension | |---|---|---| | Lives in | The AI's context window, as prose | A compiler, as code | | Can the AI ignore it? | Yes, silently | No: the check fails | | Same verdict twice? | Not always | Always. There's no AI inside | | Knows what's missing? | No | Yes: broken links, unenforced rules, unproven promises | | Shared how? | Copied between files | Versioned and installed, like a library |

SpecForge is an engine for hard skills. Think of it as a type checker for what your organisation means.

The five parts

The core grammar knows five structural words: spec, ref, use, define, defaults. Every other word in a spec (behavior, persona, invariant, campaign, procedure) and every rule ("an invariant must be enforced by a behavior", "a journey's persona must exist") exists only because an extension declares it.

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

Other ways to install

# 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}):

Other MCP clients

{

"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

| MCP server (specforge mcp) | Shipped