Alfredo Perez

Build Log 0 — Kickoff: Rebuilding SDD in Public

Published on
#sdd#spec-driven-development#speckit#speckit-companion#build-in-public#devlog
Two streams of hand-drawn marker arrows merging into a single forward path of checkpoint nodes on a graph-paper background, marker-blueprint style

I built my own spec-driven dev tool. I use it every day. It works. And I'm about to stop shipping it as its own thing.

The turn, in one line: the workflow was never the hard part. Adoption is. So instead of doubling down on a solo, Claude-only plugin, I'm folding SDD's ideas into the tool I was competing with: spec-kit, via my existing VS Code extension. One product, broader reach.

This is Build Log 0. The deep dive on the why is coming as its own essay. This post is the kickoff and the map. If you want to follow along, start here.

Why I'm changing course

SDD is good. I rely on it. But a spec-driven workflow only matters if people actually run it, and starting from zero adoption is the wrong fight when a better one is available.

spec-kit already solved adoption. Large user base, a 150+ extension catalog, a real extension model. Competing with that as a one-person, Claude-only plugin was the wrong move.

So the smart play isn't to fork the ecosystem. It's to bring SDD's ideas into spec-kit, where the users already are. The full reasoning gets its own post. This one is "I changed my mind, here's the build."

What I'm actually building

The product is the SpecKit Companion: my existing VS Code extension (the GUI), a new spec-kit extension underneath it, and a selectable template preset for the lean shape SDD uses today. All three live in one repo.

The wedge is small but real. The new extension writes the state file the Companion GUI already reads. So the moment a spec-kit user installs it, the Companion lights up: rich activity, status, resume, on top of any spec-kit project. That's a GUI no CLI-only rival has.

What rides along is everything SDD already does well. Rich activity tracking, status and resume, your-own templates, living specs with drift detection, auto mode, and Claude depth (sub-agent teams) where the agent supports it. Agent-agnostic by default, deeper on Claude Code.

And SDD itself? The methodology lives on. It's the name of this series. The standalone plugin keeps working through the transition. No hard switch.

The public backlog

The whole migration is eight ordered, PR-sized steps. A public, self-cleaning queue: each item deletes itself when its PR merges, so the backlog file is always "what's left." The order is the order I'll ship in.

  1. Foundation + spike. Wire one after_specify hook to write .spec-context.json. Prove the shape works.
  2. Full lifecycle capture, with fallback. Every step in the pipeline, with derive-from-files as the safety net.
  3. Status + resume. The Companion GUI lights up correctly on any spec-kit project. That's v1.
  4. Pipeline + the sdd-lean preset. Namespaced commands and a preset that reshapes the core templates.
  5. Complexity fast-path. Auto-detect small changes; right-size the ceremony.
  6. Living specs + drift detection. Domain specs next to code, with drift warnings.
  7. Auto mode. Ride spec-kit's workflow engine for the full pipeline, gates and all.
  8. Agent teams. Claude-only parallel sub-agents in the implement step. Sequential fallback everywhere else.

The first three are v1. After step 3, anyone already running spec-kit can install the Companion and get tracking, status, and resume on their existing flow without changing a template. Everything after that is the depth.

How to follow along

The build log runs one short post per merged PR. Same five beats every time: the itch → what I added → does it work (the test) → why this way → what's next. No padding.

Two lanes in the series. Essays cover the why and what (essay 0 is the origin). Build log posts cover the how, live, as the work ships. The logs feed the essays. When patterns emerge across a few logs, an essay distills them.

The meta hook: I'm using spec-driven tooling to build spec-driven tooling. You'll see the specs, the ADRs, the red-team passes, the PRs that work, and the ones that don't.

What's Next

Build Log 1 is the foundation spike. One after_specify hook, one .spec-context.json file, the Companion GUI lighting up on a real spec-kit project. The riskiest assumption proven (or broken) in one small PR.

Watch the repo and the backlog. Subscribe for the next build log.