Product
Open core
Each requirement gets a stable address, carries its own acceptance check, and is linked to the code that implements it. Your coding agent reads exactly the elements it needs through MCP, and the model shows what actually ran. Free under Apache-2.0.
Features
What the open core includes
The model
One file per requirement
Machine fields (id, type, parent, status, relationships, acceptance criteria) and a few sentences for a human. Files nest by parent, so the folder tree is the tree of the system.
In your git repository
The model lives next to the code. It describes the system as it is now; history lives in git and in the journal.
Statuses
Draft, reviewed and confirmed, plus blocked and deprecated.
Acceptance criteria inside the requirement
A criterion is a command with an expected result, or a check by a judge with the evidence named. A criterion can be marked as needing a visual check.
Methodology as data
Aspects, element types and relationships are declared in a YAML file. The bundled waterfall methodology is translated into five languages. One can also be generated for a domain.
Aspects of the bundled methodology
Sources, modules, user scenarios, user interface, data entities, non-functional requirements, implementation and metrics.
Links to code
Code carries @implements markers in comments, in any language. Out of the box they are read from Python, TypeScript, JavaScript, Rust, Astro, HTML, CSS, Markdown and YAML files, and the list is yours to extend. spec-editor validate checks the model and the links between model and code.
KPIs for self-improvement
A KPI is an element with a formula, a target and an owner. KPIs say what the system should get better at: they are what its self-improvement is measured by. A new project starts with a few templates, and the values are computed from the events of the system.
Hosts: configuration for DevOps
Development, test and production hosts are described apart from the requirements, as their own elements. Agents read this configuration to build, deploy and promote; the devops role that does it comes with Pro.
Plugin architecture
A small core, everything else a plugin
The core works only with the requirements model and never imports plugin code. Plugins attach through extension points; spec-editor Pro is one of them.
Storage
Storage is an interface. Files in your repository are the default implementation, and a database can take their place. The graph index has an embedded backend and a Neo4j one.
Visualizations
A plugin ships its own part of the interface: sections and views, graph profiles and node renderers for the editor.
Imports and exports
Source channels are pluggable: trackers, chats, logs. A plugin adds its own commands and MCP tools, including new import and export formats.
Event bus
Everything that happens is an event in one journal. A plugin declares its own event kinds, builds projections over the stream and runs services that react to it.
Your choice of implementation
Where several plugins fill the same extension point, the project configuration names the one to use.
Sources
Everything that arrives is a source
A document, a bug, an incident or an idea.
Channels
Jira, GitHub Issues, Slack, Discord and Telegram.
OpenSLO
Import of OpenSLO files.
Command line and MCP
Command line
The spec-editor command has 26 commands in the open core.
MCP server
About 70 tools. External agents such as Claude Code and Cursor get exactly the elements they need instead of a whole document.
Access control
A read-only mode, an allowlist of tools per agent role, and a budget of tool calls per run. The server listens on your machine only. Full access control for a team of agents comes with spec-editor Pro.
Several projects
Several independent projects in one installation. Every call is scoped to one project.
Set up for you
Automatic set-up for Claude Code, Claude Desktop, Codex CLI, Gemini CLI, Cursor, VS Code, Windsurf, Zed, OpenCode and JetBrains IDEs. Agents started by spec-editor get the server configured automatically.
Export
SRS
A specification in the style of IEEE 830, as Markdown.
Styled HTML
The same model as a styled page.
TRLC
Export to TRLC.
More formats with a custom methodology
OpenAPI, Jira CSV and a compliance matrix exist, but need element types that the bundled methodology does not have.
Web interface
Tree and two axes
The element tree on the left. On the right, the selected element along time (as designed, what happened) and medium (text, image, dynamic).
Element card
The requirement with its acceptance criteria.
Trace map
How requirements relate to each other and to code.
Graph editor
Interactive editing with flowchart, ER, sequence, class, state and other diagram types.
Delivery views
Delivery board, agent timeline and interaction diagram.
Light and dark themes
The interface language is English.
Run-time
Hierarchical logging
The log follows the tree of requirements: every record belongs to an element. Set the level on any node and everything beneath it inherits it, so you turn up the detail for one part of the system and leave the rest quiet.
Operation events
Code marked with an element writes operation events, so the log speaks in the terms of the model, not of files and modules.
Levels per element and host
From error to trace, set with spec-editor set-trace; the detailed levels take a time limit and switch themselves off.
Run-time views
Run log, run-time trace map and event graph. The trace map shows which requirements actually ran.
Embedded graph index
No external database is needed.
Editors and model providers
Editors
Extensions for VS Code, JetBrains IDEs and Zed.
Claude Code CLI
Runs on your own subscription, with no API key.
LiteLLM
API keys through LiteLLM.
Ollama
Local models through Ollama.
Pro
What spec-editor Pro adds
Pro is a paid plugin for the open core. In short:
- A delivery team of roles, with review stages decided by evidence
- Visual testing on a test stand, deployment and rollback
- Monitoring: incidents from the logs, with an on-duty role
- Cost control and self-improvement measured by your KPIs
- Breakpoints: visual comments right in your running product
- Reengineering: requirements restored from your existing codebase
Licence and installation
Apache-2.0, from GitHub
The open core is licensed under Apache-2.0. Install it from the GitHub repository, with the install script or a git checkout. The install script takes the current code from the repository only with its --dev option.