Skip to main content
Writes a technical spec for a feature. It reads the codebase for the current state, then produces a document in Google’s design-doc format, including the alternatives you considered and rejected.

Arguments

What you get

Sections

Google’s design doc format: context and scope, goals and non-goals, the design, alternatives considered. Ours adds acceptance criteria, edge cases, rollout and open questions.

What grounds it

  • Your repo. Finds files of the same shape, your data model and migration conventions, your route handlers, your test style. Acceptance criteria come out in the format your team already uses. You pick which repos it searches.
  • Customer evidence. No evidence for the feature and it stops, rather than writing a confident spec on an empty PRD reference.
  • Line numbers over open questions. If the code answers it, it is answered with a file and line.

Gaps it calls out

  • A content type customers expect and are not getting becomes an explicit non-goal, not a buried edge case.
  • Any step between “connected” and “data appears” is written into the system flow.