# Forge vs GitHub Spec Kit

**Short answer.** GitHub Spec Kit and Maistik Forge implement the same
spec-driven methodology through slash commands and templates. Spec Kit stops
there, and it is free. Forge adds a Go runtime whose four controls read
deterministic evidence and return a non-zero exit when a run goes wrong,
regardless of what the agent claimed.

## What each one actually is

**GitHub Spec Kit** is an open-source toolkit from GitHub. Its `specify` CLI
scaffolds a `.specify/` directory into your repository — templates, a
constitution under `memory/`, and per-feature folders under `specs/` — and
installs slash commands for the coding agent you use. From then on the work is
the agent's: it reads the templates, writes the spec, plans, and implements.
Spec Kit supports a wide range of agents and is MIT licensed.

**Maistik Forge** is a single static Go binary. It renders the same class of
injected instruction text into [24 agent adapters](/guide/agents), and then
does something Spec Kit does not attempt: it runs as a process that can *fail*.
[Four enforced controls](/harness/overview) check evidence on disk and in Git
and exit non-zero when the run has left its bounds.

## Feature comparison

| | GitHub Spec Kit | Maistik Forge |
| --- | --- | --- |
| **Licence and cost** | MIT, free | Proprietary, [paid annual licence](/pricing) |
| **Distribution** | Python CLI | Single static Go binary, no runtime |
| **Workflow** | Constitution → specify → clarify → plan → tasks → implement | [Nine-phase spine](/guide/workflow), `explore → … → archive` |
| **Adaptive ceremony** | One path per feature | [Governance tiers](/features/governance) decide how much spine runs |
| **Agent coverage** | Many supported agents | [24 adapters plus a generic one](/guide/agents) |
| **Spend ceiling** | — | [Spend budget](/harness/budget), non-zero exit on breach |
| **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) |
| **Code review lifecycle** | — | [Risk-tiered review with a content-bound receipt](/features/review) |
| **Multi-repo changes** | — | [Workspace](/features/workspace) |
| **Migration between them** | — | `forge import specify` |

## Why does the enforcement difference matter?

Because instructions are advice, and an agent under pressure narrates around
advice. It reports a passing test suite it did not run. It retries a failing
verify twenty times. It burns a budget nobody was watching.

Spec Kit's templates are feedforward: they steer the run before it happens.
That is the right shape for judgment work — writing a spec, choosing a design.
Forge renders that same feedforward layer, and calls it a **Guide**.

What Forge adds is the feedback half. A **Sensor** reads persisted counters or
live Git evidence *after* the fact and returns an exit code. `forge verify`
either passes or it does not. The [circuit-breaker](/harness/circuit-breaker)
opens after too many consecutive failures and escalates to a human instead of
looping. Neither is narratable, because neither is a sentence in a prompt.

The full argument, including where Forge deliberately refuses to enforce, is in
[the enforcement doctrine](/harness/overview).

## How do I move a Spec Kit project to Forge?

One command, and it does not touch your Spec Kit tree:

```sh
forge import specify --from ../legacy-app --dry-run
```

`--dry-run` prints the complete plan and writes zero bytes. The real import
snapshots `.forge/` first, skips any existing target file unless you pass
`--force`, and never modifies the source. The mapping is documented in full on
the [migration importer](/features/migration) page:

| Spec Kit | Forge |
| --- | --- |
| `memory/**` | `memory/**` |
| `specs/<feature>/` | `changes/<feature>/` |
| `branding/` | `design/` |
| `infra/` | `specs/infra/` |

Regenerable `site/` and `scripts/` are dropped by default. On one real Spec Kit
project that took **239 files down to 23** of actual spec content.

## When is Spec Kit the better choice?

Genuinely often:

- **You are evaluating spec-driven development.** Spec Kit is free and the
  concepts carry over intact. Learn the method on somebody else's budget.
- **You need to read and patch the tool itself.** Spec Kit is MIT. Forge is
  proprietary — you can read the source, but running it needs a licence.
- **Your risk profile is low.** No hot paths, no meaningful spend, nothing that
  needs to be defensible later. The gates protect against costs you do not have.
- **You want GitHub's ecosystem defaults.** It is GitHub's project, and that is
  worth something on a GitHub-centric team.

Forge starts winning when a run can spend real money, touch auth or payments, or
has to hold up to somebody who was not in the room.

## Questions people actually ask

### Is Maistik Forge a fork of Spec Kit?

No. Forge is an independent Go implementation that shares the spec-driven
lineage, not the codebase. It reads Spec Kit projects through `forge import
specify` and maps them into its own `.forge/` layout, but no Spec Kit code runs
inside Forge and the two have different architectures.

### Can I run Spec Kit and Forge in the same repository?

Yes, though it is a transitional state rather than a destination. Both write to
different directories — `.specify/` and `.forge/` — so neither overwrites the
other. Two sets of slash commands in one agent is confusing for a human, so
import and remove the old tree once you have decided.

### Does Forge lock me in?

Everything Forge knows lives under `.forge/` as plain files you can read, diff
and commit — specs, changes, config, timeline and spend records. There is no
database and no hosted service. If you stop paying, the artifacts stay yours and
stay readable; what you lose is the binary that enforces them.

### Why pay for something Spec Kit gives away?

You are not paying for the methodology, which is free everywhere. You are paying
for the enforcement layer: four controls that return a non-zero exit, an
attributed timeline, a bounded review lifecycle, and support from the people who
wrote it. If a failed run costs you nothing, that layer is not worth buying.

### Does Forge send my code anywhere?

Your code, never. Forge has no model of its own and never enters the inference
loop — the AI work happens inside the agent you configure, under that provider's
terms. Forge itself sends anonymous usage and error telemetry (command name,
version, OS/arch, a random install ID), which you can turn off with
`FORGE_NO_TELEMETRY=1`. See [Telemetry](/installation#telemetry) for exactly
what is collected.

## Next steps

- [What is Forge?](/guide/introduction) — the honest scope, including what it refuses to do.
- [The enforcement doctrine](/harness/overview) — Guides, Sensors, and why the split exists.
- [Migration importer](/features/migration) — the full Spec Kit mapping.
- [Forge vs OpenSpec](/compare/openspec) — the other close comparison.
- [Pricing](/pricing) — what a licence costs and what it covers.
