Write a PRD that gets the AI to do its best work
5 min · 7 steps
Six sections, ~500-1500 words. The wizard reads the whole thing — structure helps it pick the right archetype + entities + features.
PRDs are Avery's heaviest input mode. Where a free-text description forces you to compress, a PRD lets you specify entities + relationships + non-functional requirements + auth model + integrations explicitly. The planner reads the whole document — it has 32K of SLM context to work with.
Use a PRD when the app is non-trivial (5+ entities, multiple user roles, scheduled jobs) OR when you already wrote a spec for human reviewers. Use a free-text description for anything simpler.
The sections below are what the wizard actually USES. Other sections (revision history, business case, marketing pitch) don't help the planner — keep them in the doc if you want, just know they're noise from the AI's perspective.
Steps
- 1. Product summary (1-2 paragraphs).
What the app does, who uses it, why it exists. The planner reads this to pick an archetype. Concrete > abstract: "A pipeline tool for B2B sales reps to track deals from first contact through closed-won" beats "A CRM". Mention the user roles you'll have (admin / sales rep / read-only viewer) — they translate to NextAuth roles + role-gated routes.
- 2. Entities + relationships (the most important section).
List every entity the app needs as a top-level Markdown heading or bulleted list. For each entity: • What it represents. • Required fields with types ("name: string, email: string (unique), createdAt: timestamp"). • Relationships to other entities ("each Deal belongs to one Contact", "each Project has many Tasks"). • Enums explicitly ("status: active | done | archived"). The planner emits a Prisma model per entity, so structured = better. Vague ("track customers") = the planner guesses ("name + email" is its default Customer schema). Detailed = exactly what you wanted.
- 3. Pages / screens / user flows.
What pages does the app need? "Login → dashboard → deal list → deal detail → settings" lets the planner know which routes to scaffold + which dashboards to build. Mention hierarchy ("deals belong under /sales/deals") if it matters; otherwise the planner picks reasonable URL slugs from the entity names.
List any non-CRUD pages explicitly: "Calendar view of deals by close-date", "Kanban board of deals by stage", "Reports page with month-over-month revenue chart". Each becomes either a custom page in the dashboard generator or a separate generator (kanban from workflow-generator, reports from dashboard-generator).
- 4. Auth + permissions.
Spell out roles + what each can do: "admin: full CRUD on every entity + settings" "sales-rep: CRUD on Deals + Contacts they own" "viewer: read-only on Reports" The planner pulls in `auth-generator` + `approval-generator` + role-gated middleware. Not specifying roles → the auth-generator defaults to a single signed-in role (everyone can do everything once authenticated).
- 5. Integrations + external services.
Mention every external service by name. "Send email confirmations via Resend", "Process payments via Stripe", "Sync to HubSpot when a Deal closes". The planner picks up `email-generator` + `payment-generator` + `hook-generator` accordingly. The same provider-name normalisation that the agent wizard uses (Outlook → microsoft, Gmail → google) applies here too.
- 6. Non-functional requirements (optional, useful).
What the planner can act on: "All actions on Deals must be auditable" (→ audit-log-generator), "Every Contact change should notify the owner" (→ notification-generator), "Daily report email at 8am UTC" (→ pipeline-generator with cron), "Plain-text export of any list view" (→ adds CSV download routes).
What the planner can't act on (skip these in v1): performance targets, accessibility audit results, internationalisation, GDPR-specific clauses. Avery generates a sensible baseline but the planner doesn't tune for those — file them away for hand-tuning post-scaffold.
- Save as .md (or .docx / .txt / .pdf), attach in the wizard.
All four formats work. Markdown is best for diffs + version control; .docx works if you already have a Word doc; .pdf is read but loses some structure. Click the PRD tab in the scaffold dialog, drag in the file, optionally add a one-liner, generate.
Live recipes need the desktop
This article is a static preview. The in-app Help sidecar inside Avery NXR can fire each step against your live project — install the desktop to use it interactively.