spec-editor Pro is in early access. Request access

Requirements for agent-built software

Code got cheap. Knowing what to build did not.

spec-editor is a system for building and maintaining software with AI agents. The requirements live as a model in the repository next to the code: every requirement has an address, points at the code that implements it and carries the check that proves it. A team of agents writes the code, tests it, deploys it and watches it run.

Get startedView on GitHubHow it works
curl -sSL https://raw.githubusercontent.com/spec-editor/spec-editor/main/install.sh | bash -s -- --dev

Open core, Apache-2.0. Installs from the GitHub repository.

aspects/user_interface/SCR-004/REQ-EXAMPLE-12.md

REQ-EXAMPLE-12 Password reset form

reviewed

acceptance: 3 criteria

  • AC-1Deterministic

    Run the command: npm test -- password-reset. Expected: exit code 0, and the test "expired link is rejected" is listed as passed.

  • AC-2Judged

    A judge reads the rendered confirmation text and checks that it never reveals whether the e-mail address has an account. Evidence named: the rendered page text.

  • AC-3Seen

    Marked for a visual check: in the screenshot of the form, the error message sits next to the field it refers to and is readable.

Illustrative example, not a requirement of spec-editor.

Example

A requirement that can check itself

The proof travels with the requirement. This one is invented, to show the shape.

Deterministic criteria are a command and its expected result. Judged criteria are read by a judge against a stated expectation, with the evidence named; Seen criteria are marked for a visual check of a screenshot.

The gap

Five questions an agent needs answered

Question 1

Does a requirement have a stable address?

Each requirement is one Markdown file with an id, a type, a parent and a status. Files nest by parent, so the folder tree is the tree of the system.

Question 2

Is the system described as it is now?

The model describes the system as it is now. History stays in git and in the journal, not in the requirement.

Question 3

Is a requirement linked to code, both ways?

Code carries @implements markers. spec-editor validate checks the model and the links between model and code.

Question 4

Can acceptance be executed?

Acceptance criteria live inside the requirement, as a command with an expected result or a check by a judge with the evidence named.

Question 5

Is it known what the system actually did?

Code marked with an element writes operation events. The run-time trace map shows which requirements actually ran.

Path

The path of one requirement

The open core gives you the model, validation, links to code, export and the interface. The steps marked Pro add the delivery team.

  1. 01

    A source arrives

    A document, a bug, an incident or an idea. Channels in the open core: Jira, GitHub Issues, Slack, Discord and Telegram.

  2. 02

    Analysts turn it into requirements Pro

    Analysts work on a source independently, a second pass reconciles their results, and the result is checked against the source.

  3. 03

    The requirement enters the model

    One Markdown file with a status and its acceptance criteria. The model is checked by spec-editor validate.

  4. 04

    Review stages decide by evidence Pro

    Risk classes A to D. A human is asked only where evidence is missing.

  5. 05

    Code is written and linked

    Code carries @implements markers back to the requirement. With Pro, a coder and a tester do this work.

  6. 06

    Acceptance runs on a test stand Pro

    Every plan is deployed to a test stand and its criteria are run there before promotion. Rollback exists.

  7. 07

    Run-time events come back

    Code marked with an element writes operation events, and the run-time trace map shows which requirements actually ran.

Alternatives

Where other tools stop

Six families of tools stand between an idea and working software. Each is good at something, and each stops somewhere. Products are named only as examples of a family.

spec-editor is more than memory for agents. It is a system for writing and maintaining software, from the requirement to the running product.

  1. Requirements

    The system described as it is now, with the acceptance written into each requirement.

  2. CodePro

    A coder writes it against the requirement and links it back with @implements.

  3. Visual testingPro

    A tester runs the acceptance on a test stand and checks every screen by screenshot.

  4. Debugging

    The log follows the tree of requirements. Turn up the detail for one element and see what it did.

  5. DeploymentPro

    Devops builds, deploys to a blue/green stand, promotes and rolls back.

  6. MonitoringPro

    Repeating errors in the logs become incidents, and an on-duty role sends them back as sources.

The model, the links to code and the logging are in the open core. The delivery team comes with spec-editor Pro.

Six families of tools: what each does well, where it stops, and what spec-editor does instead
ItemWhat it does wellWhere it stopsWhat spec-editor does instead
Requirements management systemsDOORS Next, JamaIds, statuses and traces to tests. Long use in regulated work; vendors now expose requirements to agents.The model usually lives in a system apart from the code, and it describes what should be, not what ran.Keeps the model in the repository as files, and links requirements to code and to run-time events.
Trackers and wikisJira, Confluence, NotionThe common home of requirements; agents can be assigned a ticket.A ticket describes a change. When it closes, the system as it is now is not written down.Describes the system as it is now; a Jira or GitHub Issues item arrives as a source.
Instruction filesAGENTS.md, CLAUDE.mdPlain text the agent reads first. Simple and portable.Prose without structure, with no status, no test and no address for one requirement.Serves an agent only the elements it needs, over MCP, instead of one growing file.
Spec kitsSpec Kit, Kiro, OpenSpecPuts the spec before the code: requirements, design, tasks.The spec is a plan for one feature, and acceptance is often a checklist that the same agent ticks.Keeps one model for the whole system, with acceptance written into each requirement.
Agent memoryMem0, Hindsight, ZepThe agent recalls what was said across sessions.Memory of a conversation is not a description of a system: no status, no test, no link to code.Stores the system itself as addressable elements that you can read, review and diff in git. Then it builds, tests, deploys and watches that system.
Autonomous coding agentsDevin, Codex, JulesCarry one task from a description to a pull request.A task goes in and code comes out. What was learned about the system is not kept for the next task.A team of roles with review stages and cost control, and a model of the system that stays after the task is done.

Read the articles How spec-editor compares with agent memory

Editions

Open core and Pro

Apache-2.0

Open core

The model, validation, links to code, export, the command line, the MCP server and the web interface. Free, installed from GitHub.

Early access

spec-editor Pro

A plugin that adds the delivery team: analysts, managers, a coder, a tester and devops. Purchase is not open yet; you can request early access.

How we work

Built with itself

spec-editor is developed with its own pipeline: its features went through source, analysis, plan, code, check and release. It runs on your own subscriptions or tokens; we do not sell tokens, and your code is not sent to us.

See the numbers on the stats pageread the articles