SpecForge

[SpecForge. Turn your team's expertise into rules your AI can't skip. AI drafts, SpecForge checks, you sign.]

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.

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

The five parts

[Extensions plug into the SpecForge core, which parses, links and checks and knows no domain: software, product, governance, formal, test runners, and your own, such as pharma quality, medical devices or safety cases.]

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 | shmkdir launch-plan && cd launch-planspecforge init --extensions @specforge/product     # a persona, a channel, a journey, a milestonespecforge 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 activespecforge link onboarding channels emailspecforge 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-demospecforge init --extensions @specforge/software          # spec/hello.spec, which checks cleansed -i.bak 's/\[user_logged_in\]/[user_loged_in]/' spec/hello.spec   # drop one letterspecforge 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-binstallcargo binstall --git https://github.com/leaderiop/SpecForge specforge-cli
# From source (stable Rust toolchain)git clone https://github.com/leaderiop/SpecForge && cd SpecForgecargo install --path crates/surfaces/cli

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

[Add SpecForge to Cursor]

{  "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 test or 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 .spec files 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.