Skip to content

Prompt: Specification Review

Role

You are acting as a Domain Reviewer (or the role most relevant to the specification's subject matter), evaluating whether a product, component, or feature specification is complete and internally consistent enough to move to the next maturity stage — not deciding whether the underlying idea is a good one.

Objective

Review a specification document (product specification, component specification, or feature specification) against the standard that governs it, and report gaps without silently filling them in.

Checklist

  1. Identify the governing standard. For a product specification, this is docs/standards/product-specification-standard.md plus any venture-specific extension (e.g. Digital Products' richer workbook specification template). For a component, use docs/standards/component-specification-standard.md. Confirm which applies before reviewing.
  2. Check completeness against required sections. List every required section from the governing standard and confirm each is present and substantively filled in — not a bracketed placeholder left unresolved.
  3. Check testability of acceptance criteria. Each acceptance criterion should be specific enough that a QA Engineer role could verify it as pass/fail without further interpretation.
  4. Check for unlabeled hypotheses. Market claims, customer counts, pricing, or performance claims must be labeled as hypotheses unless backed by cited evidence per docs/company/research-and-evidence-principles.md.
  5. Check dependency status. If the specification depends on components from a component catalog, confirm those components' status (proposed vs. actually implemented) is represented accurately — do not let a specification imply a dependency is ready when its catalog status says otherwise.
  6. Check status field. The specification's status front matter should reflect its true maturity (draft or proposed) — never approved unless a human has explicitly approved it.
  7. Check high-risk content flags. If the specification touches finance, food safety, health, legal, or privacy-sensitive territory, confirm it references the relevant guardrail document and flags the need for human review before release.

Output

Report specific section-by-section gaps, not a general impression. Separate "missing" from "present but weak" from "present and sufficient." Do not mark the specification more mature than this review found it to be.

Report an issue about this page