ThomasBirkmaier/ReqSeq

ReqSeq is a local, Git-based requirements tool: one Markdown file per element, traceability, coverage and evidence.
You keep your requirements as plain files in your own folders and repositories. ReqSeq reads them, checks them against a metamodel, follows their relations and shows what is covered and verified, from a desktop app, a command line, a local API and an MCP server.
That makes it a tool for spec-driven development with coding agents: the specification lives in the repository next to the code, agents read and change it through the command line or the MCP server, and the pipeline checks it and records which requirement each test run verified. ReqSeq itself is built that way.
## What it does
Plain files. Each need, use case, system requirement, decision, variant and package is one Markdown file with its properties in the frontmatter, in folders you keep in Git. ReqSeq reads Git but never writes to it, and it never deletes an element: it supersedes it.
Your metamodel. Types, properties, relation kinds and statuses belong to the workspace; a new workspace starts with the standard model. Statuses are set by people; ReqSeq never computes them.
Traceability. A relation keeps the version of its target, so a changed target shows the relation as outdated. Trace chains, related and affected elements, a traceability matrix and a graph.
Evidence and coverage. Verification and validation records, and JUnit XML results of tests that name the requirement they test; coverage, verification degree and the requirements without a passed test.
Checks in pipelines. reqseq workspace check checks the whole workspace, or only the changed files, and exits with 1 on errors.
Variants, baselines and exchange. Variants that exclude or replace requirements of the core, baselines to compare against, ReqIF import and export, and data export.
Four ways in, one result. The desktop app, the reqseq command line, a local HTTP API on loopback and an MCP server for AI agents run the same commands.
## Spec-driven development with coding agents
A spec that an agent writes code from is only half of the job. ReqSeq keeps it after that: each requirement has a version, its relations follow it down to the tests, and every pull request shows what the change breaks and what is still unverified.
1. Give the agent the workspace. Either the reqseq command line in the repository, or the MCP server, one tool per command with the same result as the CLI:
json
{ "mcpServers": { "reqseq": { "command": "reqseq", "args": ["mcp", "--workspace", "spec"] } } }
2. Let it change the spec with commands. element create, element update, relation add and element supersede keep IDs, versions and relations consistent; element search and trace chain let it read before it writes. A requirement is never deleted, only superseded, and a status is only ever set, never computed, so approving stays a decision someone makes.
3. Name the requirement in the test. [SR-c67baa] shows the wind speed in any test tool that writes JUnit XML, or a name pattern such as src67baaak1 where brackets do not fit.
4. Check it in CI. On every pull request, as steps of a GitHub Actions job (checkout with fetch-depth: 0, workspace in spec/):