From requirements to reviewed code.
A spec-driven engineering workbench for local Git repositories.
Download desktop · DSH plugin · Run from source · 简体中文
The built-in CSV demo in the English workbench. Switch between English and Simplified Chinese from the header.
SpecFlow connects specifications, model execution, real tests, and human acceptance in one local workbench. Every change carries a record of what was requested, what ran, what passed, and what you accepted.
Use the standalone desktop app or work inside DeepSeek Harness through its native side-panel plugin.
Overview · Get started · Workflow · Backends · Development · Documentation
Each attempt records its requirements, project rules, document revisions, model, and execution identity. When an upstream input changes, dependent results become stale.
Review passes examine coverage and failure cases against the same frozen materials. SpecFlow runs your project's verification commands and records their output, exit codes, and the code version tested. Changes to code or commands invalidate old evidence.
Review documents, diffs, findings, and test results at each checkpoint. Before you accept a change, SpecFlow checks that the required evidence still matches the current work.
Choose English or 中文 in the workbench header. On first launch the interface follows your system or browser language; your selection is saved. The desktop menu, dialogs, status messages, and document exports follow the selected interface language.
New work items use the selected language for their default workflow, generated documents, briefs, and clarification questions. To change the output language for a new run of an existing work item, open the workflow editor and choose Generated content language. Existing attempts, user content, code, logs, and quoted evidence retain their original text. The DeepSeek Harness plugin provides the same language selector within its panel.
| Platform | Installer |
|---|---|
| Windows x64 | SpecFlow-<version>-win-x64.exe |
| macOS · Apple Silicon | SpecFlow-<version>-mac-arm64.dmg |
| macOS · Intel | SpecFlow-<version>-mac-x64.dmg |
The app includes Electron, Node.js 24, npm, and the Maka Runtime Host. Install Git separately, along with the tools your project's tests and build commands require.
macOS validation · 2026-10-31: A local Apple Silicon build passed native checks on macOS 27.2: 290 passing tests (one Windows-only check skipped), the official Maka Host, DMG/ZIP packaging, and the packaged CSV engineering workflow. The validation record identifies the tested revision, additional desktop checks, and limits; this run covers ARM64.
Installer checksums, signing, and updates
Release assets include SHA256SUMS.txt. Current installers do not use Windows Authenticode or macOS Developer ID signing; macOS builds are not notarized.
Starting with the 0.2.1 build scripts, macOS packages use complete ad-hoc signatures when Developer ID signing and notarization are unavailable. They still require manual approval on first launch; see the first-launch instructions. The previously published 0.2.0 macOS packages have invalid signatures and need a new release containing this fix.
Windows supports in-place updates through the app's Help menu. For current macOS builds, download a new DMG and replace the app. See the desktop installation and update guide.
- Explore the demo. The built-in CSV example changes code and runs real Node.js tests in an isolated repository, using deterministic results without calling a model API.
- Connect a repository. Add a local Git project with a clean, committed baseline.
- Configure the project. Add a model connection and choose models for the analyst, architect, developer, and reviewer roles. Set project rules and verification commands.
- Describe a change. Create a work item and optionally attach Markdown or TXT requirements.
- Work through the checkpoints. Clarify the specification, review and accept the design and tasks, then run implementation and verification.
- Accept the result. Inspect the candidate diff, findings, and evidence before integrating into the work-item branch.
Run the same engineering core in a Specflow tab beside your DSH conversation, using the models configured in your host.
npm · dsh-plugin-specflow 0.1.2 · GitHub release · Plugin guide
Requires DSH 0.2.1-rc.2 or newer, host Node.js 24+, and local Git. From 0.1.2 the plugin declares the open range engines.dsh: ">=0.2.1-rc.2" and is verified on 0.2.1-rc.4: DSH keeps the plugin APIs backward compatible, so newer hosts load the same build, while older ones are still skipped. The desktop app, Maka, and OpenCode are not required.
In DSH, open Plugins → Install Third-Party Plugin and enter dsh-plugin-specflow@0.1.2. Enable it and open the Specflow workbench in the right sidebar. The panel links the current conversation's repository automatically; you can also select a repository manually. Assign role models and verification commands, then create a work item.
For a catalog that accepts a public npm package URL, use https://www.npmjs.com/package/dsh-plugin-specflow. The GitHub release also provides a prebuilt .tgz and SHA256SUMS.txt; DSH accepts the tarball URL or its local absolute path.
To update an installed plugin, save edits and stop active Specflow operations, uninstall it in the same DSH profile, install the new package, and restart DSH. Engineering data is retained. If you configured a custom dataDir, keep that value after reinstalling.
CLI installation and custom plugin market
For the CLI/Web profile:
dsh plugin --profile web add dsh-plugin-specflow@0.1.2
dsh webYou can also use the project's custom plugin-market index, which pins the prebuilt Git distribution to its release commit.
The panel handles workflow actions and human acceptance. The chat tool specflow_query provides read-only project status. Installation, data locations, development, and recovery are covered in the plugin guide.
Each registered repository is a project. Each work item has its own branch and workspace; implementation runs in a separate candidate worktree.
| Phase | What you work with |
|---|---|
| Specify & clarify | Requirements, supporting documents, acceptance criteria, and answers written back into the specification |
| Design & break down | A reviewed design and tasks with dependencies and acceptance conditions |
| Implement & verify | Candidate code, task progress, and results from your verification commands |
| Review & align | Findings and a report connecting requirements, tasks, code, and evidence |
| Accept | A final freshness and evidence check, followed by your decision to integrate |
The default workflow has 13 steps, including dedicated reviews between the main phases. Editing a requirement or document creates a new revision that must pass the relevant checks again.
Full Markdown documents remain the execution contract. Short reading briefs stay linked to the same source revisions; the desktop workbench also provides offline HTML export. Accepted documents retain their history and are exported with the work item.
When requirements change
Changing a CSV requirement from accepting malformed rows to rejecting them makes dependent work stale, even if earlier tests passed. Acceptance checks that the documents, reviews, and test results apply to the updated inputs and candidate code.
Accepted code is integrated into the local work-item branch. Publishing that branch or opening a pull request remains part of your Git workflow.
SpecFlow manages the workflow, input versions, evidence, and acceptance rules. Your selected backend runs the model sessions.
| Backend | Setup | Models |
|---|---|---|
| Maka · desktop default | Runtime Host included with the app | Add connections in SpecFlow; Maka manages provider credentials |
| OpenCode · desktop option | Separately installed local service | Configure providers in trusted OpenCode user settings |
| DSH · plugin | Compatible Harness host | Use models configured in DSH |
Changing a project's backend applies to new attempts. Existing attempts keep their original backend, model, and session identity. OpenCode and DSH can recover the status of an interrupted run; continuing the work requires an explicit new attempt.
Connect a local OpenCode service
opencode serve --hostname 127.0.0.1 --port 4096Choose OpenCode in project settings, save the connection and optional authentication, refresh the model list, and assign role models.
SpecFlow accepts loopback endpoints only. Repository-level opencode.json, opencode.jsonc, and .opencode configuration are currently blocked; use trusted user-level configuration.
See backend setup and switching and the OpenCode adapter notes.
Bundled Maka release policy
The runtime is built from the signed official Apache Maka 0.2.0 source release (0.2.0-incubating). The release manifest pins the source version, SHA-512 checksum, and signer fingerprint.
Only Runtime Host and its production dependencies ship with the desktop app. Source, compiler, tests, CLI/Eval, and build caches stay outside the package.
Setup, runtime loading, and packaging enforce the same policy: development, nightly, snapshot, RC, and placeholder builds are rejected. If the approved release cannot be obtained or adapted, the build fails. A formal npm package will replace this source-build path once publishing is resolved.
Use Node.js 24+, npm, Git, and GPG. Setup needs network access to verify and build the pinned Maka release. On Windows, GPG bundled with Git can be used; on macOS, install GnuPG separately.
git clone https://github.com/HuYellow/specflow.git
cd specflow
npm ci
npm run maka:setup
npm run desktop:devFor browser development, run npm run dev after setup and open localhost:4318. To serve a production build, run npm run build, then npm start, and open localhost:4317.
Verification and desktop packaging
Core checks:
npm run typecheck
npm test
npm run build
npm run maka:probeThe probe exercises the prepared Maka Host. Tests that require it explicitly skip when the approved runtime has not been prepared.
Build installers on the matching operating system and CPU architecture:
npm run desktop:package:win # Windows x64
npm run desktop:package:mac:arm64 # Apple Silicon Mac
npm run desktop:package:mac:x64 # Intel MacInstallers are written to release/. Release automation and signing are documented in the desktop delivery guide.
For plugin development, install its separate dependencies and use dsh:typecheck, dsh:test, and dsh:pack as described in the plugin guide.
Project records, workspaces, and run logs are stored locally. Model requests go through the provider configured in the selected backend. Desktop, browser, and DSH installations use separate data directories and do not automatically migrate existing data.
Workspace file restrictions are application controls, not an operating-system sandbox. Verification commands run with your user permissions. The quality of model reviews and test evidence depends on the models and checks you configure.
Default data directories
| Entry point | Engineering data directory |
|---|---|
| Desktop · Windows | %APPDATA%/SpecFlow/engineering |
| Desktop · macOS | ~/Library/Application Support/SpecFlow/engineering |
| Browser workbench | .specflow-data/local |
| DSH plugin | $DSH_HOME/specflow, or ~/.dsh/specflow with the default DSH home |
Use SPECFLOW_DATA_DIR to override the browser data directory; the plugin has its own dataDir setting. Desktop uninstall preserves engineering data.
Most detailed implementation notes are currently in Chinese.
| Topic | Guides |
|---|---|
| Installation & distribution | Desktop · DSH plugin · Plugin publication |
| Runtime integration | Execution backends · Maka management |
| Inputs & clarification | Requirements · Project guidance |
| Documents & review | Reading briefs · Review policy |
| Execution control & automatic repair | Policies, recovery and bounded repair · UI validation · Evaluation tools |
Automatic advancement and bounded repair are opt-in from the workflow view. Required clarification, tool permissions, independent review and human acceptance still apply. Execution details preserve deadlines, original backend identities and unknown usage rather than treating missing measurements as zero.
Apache License 2.0 · Bundled components retain their respective licenses and notices.