← Back to Work

SpecForge

A Developer Tool for Spec-Driven Development, Built and Released by the Studio

specforge — tasks · commit graph
SpecForge's three-pane window: a workspace tree of OpenSpec changes on the left, a change's task list rendered as a document in the centre, and a repository's git commit graph on the right
The three-pane view: a change’s task list rendered as a document, with the workspace tree to the left and a git commit graph to the right.

SpecForge is a developer tool for spec-driven development, built and released by the studio: a desktop app, a terminal UI and a browser UI over one Rust core, MIT-licensed, and built with the method it shows. That is the product. What matters to a client is the practice behind it, and SpecForge is where that practice can be inspected without the studio in the room.

The gap is verification

Unverified output has become the cost of the tools. The industry has not stepped back from AI; it has stepped back from believing it. Stack Overflow’s 2025 developer survey found 84 per cent of developers using or planning to use AI tools, about a third trusting what those tools produce, and “almost right, but not quite” the top frustration. KPMG’s Global AI Pulse for the second quarter of 2026 found nearly half of the organisations it surveyed had scaled back, delayed or paused AI-agent deployments because expected costs had begun to outweigh the value delivered. Open-source maintainers have felt it directly: curl closed its bug bounty in January 2026 after the share of valid reports fell below five per cent and the cost of triaging machine-written ones landed on the maintainers.

None of this is an argument against the tools. It is the bill for using them unchecked. Trust, not generation, has become the real bottleneck: output now arrives faster than anyone can verify it, and unverified output is the cost. AI raises the floor without raising the ceiling. What raises the ceiling is a senior engineer who writes the intent down first and signs off at the end.

The answer: spec, then verify

The studio’s answer, in use on its own codebases since October 2025, is a written spec on one side of the work and a verification gate on the other. Before any code is written, a change exists as a handful of plain files in the repository: a proposal that says what will change and why, a delta to the specification, a task list and, where there are real decisions to record, a design note. AI implements against those files; a human verifies the result against them. The files are the source of truth, not the model’s memory.

For a client, that changes what a delivery looks like — and none of it depends on AI being in the loop. Intent is written down and reviewed before it is built, so there is something to disagree with while disagreeing is still cheap. Every non-trivial change leaves its proposal, its spec and its task list beside the commits that implemented it, so the reasoning survives the session — and the engineer. And because the artefacts are plain files in the repository, they stay legible to the people paying for the work and to whoever picks it up next, person or agent.

The heavy frameworks add ceremony faster than they add safety. The studio runs the lightweight OpenSpec format instead — an open, third-party convention it adopted, sized to the change rather than to the framework — and its article on why AI agents need specifications sets out why. SpecForge is the studio’s viewer for that format.

The trail, dated

The dates, in order.

  1. October 2025 — OpenSpec adopted

    The studio’s own website repository adopts the OpenSpec format on 21 October — six and a half weeks after the format’s first release, two weeks before spec-driven development reaches the Thoughtworks Radar — and archives five changes the same day. Five days later a second studio repository — the public Artifex command-line tool — starts life as an OpenSpec workspace, and its first OpenSpec workflow helpers land the same day.

  2. February 2026 — the tooling, then the position

    An OpenSpec extension for Visual Studio Code is published to the marketplace on 14 February: it watches OpenSpec changes in a panel and badges the count still in flight. Why AI Agents Need Specifications follows on 15 February: the frameworks mostly deliver overhead, and the lightweight format is the one the studio kept.

  3. May 2026 — SpecForge’s first commit

    A viewer for the same format, started on 24 May. Its first tagged release follows two days later, and thirty-odd tagged releases follow in a little over three months.

The practice has many authors. What the studio can show is having run it on production work since the autumn of 2025, and an archive that has kept growing since.

Built with the method it shows

SpecForge’s own repository is an OpenSpec workspace — the same kind of tree the screenshot above shows it reading. Over a hundred changes have been archived there since May 2026, each with its proposal, its delta to the spec and its task list still in the tree.

Every feature starts on paper.

A proposal, a delta to the spec and a task list — and, where there are real decisions to make, a design note that weighs the alternatives — each archived with the change when it ships, so the reasoning stays beside the code.

Changed core lines face a mutation gate.

Every push mutation-tests the lines it changed in the two headless crates. If a mutant on a changed line survives the tests, the build is red.

Reviewed before it ships.

An agent review reads the complete diff against the proposal, design and tasks; critical and important findings are fixed before the change is archived, and the commit log keeps the record.

Release notes come from the archive.

They are drafted from the changes archived since the previous tag and approved by the engineer before the tag is cut; the tag then builds and publishes the release, so what shipped and why it shipped are one record.

A reversal, on the record.

In August 2026 a change deleted the monthly season and battle-pass system the studio had built in June — “invented scoring — a game layered on top of the record rather than a reading of it” — and the removal was proposed, designed and archived like any other change. Deletions get the same paper as features.

What SpecForge does

One Rust core, three ways in: a desktop app for macOS, Windows and Linux, a terminal UI and a browser UI. It reads the OpenSpec format.

One count, every workspaceA badge in the menu bar or system tray counts the changes in flight across every registered project. A change being worked in several git worktrees counts once.
Three panes, one changeWorkspace tree, rendered artefact and the repository’s commit graph side by side — task state and git history in the same window.
The commit graph, as git sees itA faithful git log --all: lanes, branches, merges and refs, with the files and diff behind any commit a click away.
Live from the filesystemFilesystem watchers keep the badge, tree, documents and graph current as files and commits change.
Read-only towards the workIt observes and renders: it never edits a spec, toggles a task or touches git, and its own state lives outside every workspace.
MIT, source publicThe licence, the pipeline and the spec tree are all in the repository. The standard is inspectable, not just described.

The proof point

The spec before the code and the verification before it ships — the practice the studio brings to client work, visible in a repository anyone can open and read.