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.
Specs your AI agent can't ignore. A deterministic compiler that turns your rules into checks: no AI inside, same input, same verdict. Rust · MCP-native · works with Claude Code, Cursor and any MCP agent.
Apache-2.0
最終チェック
2026-10-28
スター
34
ツール
—
稼働率
—
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.
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:
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
}
Agent-driven screens for people who don't use an editor
HTTP
Planned
Other applications reading and changing the graph
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…
You already use
It's good at
What SpecForge adds
Specs, PRDs and policies in Markdown
Describing intent for people and agents
The same intent as .spec files whose structure is checked. Broken references, missing pieces and unproven promises fail the check
CLAUDE.md, AGENTS.md
Working rules for the agent: conventions, commands, style
Nothing to replace. Keep those rules there; what must be true lives in SpecForge
Tests
Proving the code does something
Saying which promise each test proves, and which promises have no test at all
Issue trackers, roadmap tools
Tracking work in progress
A checked model of what must exist and how it links, that an agent can query
Requirements and quality tools (DOORS, Polarion, eQMS)
Traceability for regulated teams
Plain text in your repository, checked in CI, readable by agents, extensible by you
Generators
Producing code or documents from a model
Nothing. SpecForge never writes your code or your documents. Your agent does, from knowledge SpecForge has checked
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.
Specs your AI agent can't ignore. A deterministic compiler that turns your rules into checks: no AI inside, same input, same verdict. Rust · MCP-native · works with Claude Code, Cursor and any MCP age
Specs your AI agent can't ignore. A deterministic compiler that turns your rules into checks: no AI inside, same input, same verdict. Rust · MCP-native · works with Claude Code, Cursor and any MCP agent.
最終チェックは 2026-10-28 です。 Specs your AI agent can't ignore. A deterministic compiler that turns your rules into checks: no AI inside, same input, same verdict. Rust · MCP-native · works with Claude Code, Cursor and any MCP agent.
