Step 2Phase 1 — Product definition~30 min

PRD / spec

Turn the concept brief into a spec the agent can build against, where every success criterion is checkable by a command, a crawler, or Lighthouse. Vague criteria are a defect.

At a glance

Purpose: make "done" objective. The PRD is the spec; success is machine-verifiable.

Run: ai_rules/prompts/2_prd_generator_prompt.md

Output: ai_rules/app_approach/PRD.md

Feeds: the copy generator, the design generator, the memory bank, and the build loop. Section 10 becomes the constitution.

Why it exists

A brief says what you want. A PRD says how you will know you got it. This step interviews you about the route map, the server / client boundary, data fetching, SEO, forms, and Stripe, then emits a spec whose acceptance criteria a CI job or an agent can verify without opinion. It is the contract the rest of the workflow is held to.

How to run it

Paste the prompt and the brief

Copy ai_rules/prompts/2_prd_generator_prompt.md into an LLM, then paste your concept-brief.md when asked.

Answer the spec interview

5–10 targeted questions: exact routes (static vs dynamic), the smallest client island per surface, per-route data source, per-route SEO + JSON-LD type, form fields + fail-soft behavior, Stripe plans + unconfigured behavior, the performance budget, and what is explicitly out of scope.

Save the PRD

Text

ai_rules/app_approach/PRD.md

Copy the constitution

Copy Section 10 (non-negotiables) verbatim into .memory/01-brief.md in Step 5. These are the hard rules the build can never relax.

Checkable success criteria

Section 9 is the heart of the spec. Every criterion is verifiable by a command, a crawler, or Lighthouse, never by opinion:

PRD.md §9 — Success criteria

1.  pnpm install && pnpm build exits 0 with no .env file present.
2.  npx tsc --noEmit exits 0.
3.  pnpm lint exits 0.
4.  Every route returns its intended HTTP status (crawlable).
5.  Every page has a non-empty title, meta description, self-canonical.
6.  JSON-LD validates against its declared type on each route.
7.  Lighthouse (mobile) Performance > 90, Accessibility > 95.
8.  INP < 200ms and CLS < 0.1 on the conversion page.
9.  Primary CTA POSTs 200 with Supabase configured AND absent (fail-soft).
10. Stripe button hides/disables (not crashes) when env is absent.

Spec-Kit phasing & the constitution

The PRD mirrors GitHub Spec-Kit's specify → plan → tasks phasing. This document is the specify artifact: it names what the plan and tasks will elaborate, but does not prescribe component internals. That comes later in Architecture and the build loop.

Section 10 is the constitution: zero-env build stays green, integrations fail soft, server-first, Tailwind v4 CSS-first, all metadata via getSEOTags(). These get copied into the memory bank, and the build loop refuses to violate them.

Best practices baked in

Every criterion is checkable by a command, a crawler, or Lighthouse. Reject anything you can only judge by opinion.
An explicit out-of-scope list stops the agent gold-plating.
No new dependencies the stack does not already imply.
Do not spec component internals here. That is the plan phase's job.
TBD is allowed only in Open Questions, never in a requirement.

Feeds the next steps

Copy (Step 3) and design (Step 4) both read this PRD independently. The memory bank (Step 5) runs its gap analysis against Section 3. The build loop (Step 8) builds each task against a Section 9 criterion.

← 1. Idea & concept brief 3. Copy →