# Forge vs OpenSpec **Short answer.** OpenSpec and Maistik Forge model work the same way: a change proposal becomes a spec, gets implemented, then archives into a durable spec tree. OpenSpec is free, open source, and stops at the workflow. Forge adds a Go runtime whose controls fail a run on evidence rather than trusting the agent's account of it. ## What each one actually is **OpenSpec** is an open-source, Node-distributed spec-driven workflow. It keeps an `openspec/` directory holding configuration, a `specs/` tree of durable specifications, and a `changes/` tree of in-flight proposals that move into `changes/archive/` once shipped. Agents drive it through slash commands. The structure is clean, the concepts are sound, and it costs nothing. **Maistik Forge** models changes the same way — which is why migration between them is nearly a rename — and then adds the part OpenSpec does not attempt: a [binary that returns a non-zero exit](/harness/overview) when a run leaves its bounds. ## Feature comparison | | OpenSpec | Maistik Forge | | --- | --- | --- | | **Licence and cost** | Open source, free | Proprietary, [paid annual licence](/pricing) | | **Distribution** | Node package | Single static Go binary, no runtime | | **Change model** | `changes/` → `changes/archive/`, durable `specs/` | Same shape under `.forge/` | | **Workflow depth** | One path per change | [Governance tiers](/features/governance) scale ceremony to risk | | **Agent coverage** | Agent-agnostic via slash commands | [24 adapters plus a generic one](/guide/agents) | | **Spend ceiling** | — | [Spend budget](/harness/budget) | | **Retry ceiling** | — | [Verify circuit-breaker](/harness/circuit-breaker) | | **Dangerous-command block** | — | [Guardrails gate](/harness/guardrails) | | **Secret / PII scan** | — | [`forge secscan`](/harness/secscan) | | **Audit record** | Git history | [Append-only attributed timeline](/harness/timeline) | | **Spec quality score** | — | [`forge analyze`, 100-point](/features/quality) | | **Drift detection** | — | [Drift and reconcile](/concepts/drift-and-reconcile) | | **Offline spec browser** | — | [Spec-viewer dashboard](/features/dashboard) | | **Migration between them** | — | `forge import openspec` | ## How close are the two models? Close enough that the importer is almost a rename. `forge import openspec` maps `config.yaml`, `specs/**` and `changes/**` — archive included — straight into `.forge/`, and the [migration page](/features/migration) documents it as "a near 1:1 rename". That is not a coincidence. Both tools took the same position: a change is a first-class artifact with a lifecycle, and the durable spec is what the change leaves behind. If you already think in OpenSpec's terms, Forge will not ask you to rethink anything — the vocabulary transfers. Where the two diverge is depth. Forge's [spine](/guide/workflow) runs `explore → propose → specify → clarify → plan → tasks → implement → verify → archive`, and [governance](/features/governance) decides how much of it a given change traverses. A typo fast-forwards to `implement → verify`. A change touching auth or crossing 400 lines runs the full spine with four review lenses. The ordering never changes; only how much of it you pay for. ## What does the runtime add that a workflow cannot? A workflow is text. It steers the run, and a model can narrate its way past text — reporting a suite it never ran, retrying a broken verify indefinitely, spending a budget nobody bounded. Forge splits its features in two and is explicit about which is which. **Guides** are feedforward and narratable: the methodology, governance, memory. **Sensors** are feedback and are not: they read persisted counters or live Git evidence and return an exit code. The four Sensors: 1. **[Guardrails gate](/harness/guardrails)** — bounds dangerous actions, the irreversible command and the leaked secret. The only control that stands in front of an action rather than grading it afterwards. 2. **[Verify circuit-breaker](/harness/circuit-breaker)** — bounds iteration. Too many consecutive verification failures and it opens, exits non-zero, and forces escalation to a human. 3. **[Spend budget](/harness/budget)** — bounds cost in tokens, dollars or tool calls. 4. **[Secret and PII scan](/harness/secscan)** — walks a change's files before a credential reaches a commit. Every one of them emits into the [session timeline](/harness/timeline), so the record of what happened is written by the gates rather than self-reported. ## How do I move an OpenSpec project to Forge? ```sh forge import openspec --from ../legacy-app --dry-run ``` The source is never modified. `.forge/` is snapshotted before any write and is reversible with `forge restore`. Existing target files are skipped and reported unless you pass `--force`, and `--dry-run` prints the whole plan while writing zero bytes. Because the mapping is near one-to-one, there is little to reconcile afterwards — run [`forge analyze`](/features/quality) once the import lands to see how the imported specs score. ## When is OpenSpec the better choice? - **Cost is the deciding factor.** OpenSpec is free. If the enforcement layer would not prevent a real loss for you, it is not worth a licence. - **You want to modify the tool.** It is open source. Forge is proprietary. - **Node is already your toolchain.** One less distribution mechanism to think about, even though a static Go binary has no runtime to manage. - **You are learning the change-proposal model.** Learn it free. The vocabulary carries over intact, and the importer is waiting when you outgrow it. ## Questions people actually ask ### Is the migration really lossless? The structural mapping is one-to-one for `config.yaml`, `specs/**` and `changes/**` including the archive, so nothing is dropped on the way in. Always run `--dry-run` first: it prints exactly what would be written, skipped and dropped without touching disk, so you confirm rather than trust. ### Can I go back to OpenSpec afterwards? Your OpenSpec tree is untouched by the import, so reverting early is just a matter of deleting `.forge/`. Later on, everything Forge holds is plain files under `.forge/` — specs, changes, timeline, config — so the content stays readable and portable even though there is no automated export command. ### Does Forge need Node or Python installed? No. Forge is a single static Go binary with no runtime dependency — no Node, no Python, no package manager. That is also true of the features you might expect to need a toolchain, like the [web control panel](/features/web-ui), which is embedded in the binary. ### Which one has better agent support? Both are agent-agnostic in principle. Forge ships 24 dedicated adapters plus a generic one, so each agent receives instructions in the format it actually expects rather than a lowest-common-denominator file. The full list is on the [supported agents](/guide/agents) page. ### Does Forge phone home? Your code never does. Forge sends anonymous usage/error telemetry (command name, version, OS/arch, a random install ID — never your code) to help fix bugs; set `FORGE_NO_TELEMETRY=1` to opt out. Forge has no model of its own. Your specs, timeline and spend records live on disk under `.forge/`, where you can read, diff and commit them. ## Next steps - [Migration importer](/features/migration) — the full OpenSpec mapping. - [The SDD workflow](/guide/workflow) — the nine-phase spine in detail. - [Change governance](/features/governance) — how tiers scale ceremony to risk. - [Forge vs GitHub Spec Kit](/compare/spec-kit) — the other close comparison. - [Pricing](/pricing) — what a licence costs and what it covers.