Kiro specs go stale. A requirement says "the system may support SSO" and nobody notices. Acceptance criteria read like wishes instead of tests. Tasks get checked off while the code they describe never appears. Spec Doctor audits the spec itself, before it costs a build.
Paste or upload requirements.md, design.md, and tasks.md. Spec Doctor runs a deterministic audit entirely in the browser and returns a health score from 0 to 100 with findings that name the file, the line, and the exact quote, each with a fix suggestion. It flags vague language, acceptance criteria without GIVEN/WHEN/THEN structure or EARS format, untestable wording, requirements no task covers, tasks with no requirement reference, duplicate requirements, oversized tasks, and design sections missing error handling, a data model, or API contracts. The score is reproducible by hand: the report shows every deduction.
Drift detection traces the spec into an uploaded repository (folder or ZIP, read in-browser). It reports three kinds of traceability signals: spec items with no implementation, code referencing IDs the spec never mentions, and code files with no ID references at all. These are signals: each one needs human judgment, and drift never changes the health score.
An optional LLM review adds a semantic second opinion. You supply an OpenAI-compatible endpoint, key, and model. The key stays in memory only: the app uses no localStorage, no sessionStorage, and no cookies. LLM suggestions appear in a separate labeled block and never affect the score. The full audit exports as JSON or Markdown with a timestamped filename.
Spec Doctor audits its own spec: the spec in .kiro/specs/spec-doctor/ scores 82 out of 100 with 9 findings, 6 of which are self-referential (the spec lists the vague terms the checker flags). The repository includes two fixtures: a bad spec that scores 28 with 37 findings, and a good spec that scores 100 with none. The suite has 281 tests.
Built With
- cli
- jszip
- kiro
- typescript
- vite
- vitest
