I built spec-driven development as a skill pack for Pi. Here is what actually mattered.
I built a spec-driven development kit for Pi and have been running my own projects on it. Posting here because this is the crowd that would actually use it, and I want the feedback on where it fights Pi's flow.
The problem it solves: Pi is capable and has zero memory between sessions. Ask it to "add authentication" and you get 500 confident lines that compile and solve a slightly different problem than the one you had. pi-sdd-kit makes you specify before it codes, as skills you invoke: /skill:sdd-prd, /skill:sdd-spec, /skill:sdd-tasks, /skill:sdd-exec, /skill:sdd-review, with a human approval gate between each.
Two parts do most of the work.
First: steering docs as durable memory. product.md, tech-stack.md (with the reason for each choice, not just the name), conventions.md, and principles.md live in .ai/steering/ and load every session, separate from per-feature specs. The reason line is what pays off: "we use Postgres because payment records need ACID" stops the agent reaching for SQLite three sessions later.
Second: .status is the only gate. One line per feature: requirements:approved, then design:approved, then tasks:approved. The agent reads it before it does anything. A finished-looking design.md on disk is not approval. Only the token is. That stops an eager agent from racing a draft straight into code.
Requirements go in EARS (WHEN / IF / WHILE / SHALL), which leaves almost nothing to interpret.
Install:
pi install npm:@felipefontoura/pi-sdd-kit
# then in Pi:
/reload
/skill:sdd-init
Repo, with the full command reference and templates: https://github.com/felipefontoura/pi-sdd-kit
Longer writeup and the crypto-fintech case study it came out of (13 apps, ~70 days, solo): https://felipefontoura.com/articles/spec-driven-development-case-study