v2.6.0 — Spec-Driven Development

Spec-driven development comes to shipkit. The project knowledge layer now looks forward — specs and decision records become durable, verified .shipkit/ artifacts the elders read. This release folds in the 2.5.0 SDD core and the 2.6.0 completion work.

The three questions

On non-trivial work, two always-on rules put the spec-driven discipline in effect — what are we building (requirements in EARS) / how should it work (design as decision records) / how will we know it's done (acceptance criteria as tests, TDD/BDD-first).

Highlights

• /shipkit:spec <feature> — guided interview through the three questions; writes .shipkit/specs/<feature>/{spec,design,tasks}.md with an approval gate on requirements and native Plan Mode before tasks.
• /shipkit:decide — captures a project-wide decision as a five-part record (Context · Alternatives · Case-for · Case-against · Decision + a concrete falsifiability clause) in .shipkit/decisions/.
• Falsifiability clauses make decisions queryable for staleness — ask grandfather "are any past decisions now falsified?" and it checks each clause's condition against current reality.
• Elders read .shipkit/ — grandfather/eve treat specs and decision records as first-class sources (verified records beat git log/recall for "why"); eve sees open specs across the portfolio.
• Spec-drift freshness hook — nudges once per accepted spec whose code has moved past it.
• Narrated capability playbooks — the User Guide now walks you through a new (greenfield) repo, a legacy/inherited repo, and using the elders, step by step.

Also

• Registry Active Specs column so eve answers "which projects have an open spec?" from the registry alone.
• /unsetup explicitly never deletes .shipkit/ — your specs and decisions are project work product.
• Docs: a "How Shipkit Works" section clarifying what fires automatically vs. what you invoke.

Full changelog: CHANGELOG.md · Design: docs/design/spec-driven-development.md