PRD-to-App: Full-Stack Application Builder

Language: Respond in the same language the user uses. Code comments should match.

Build a complete, deployed web application from PRD + prototypes + resources. The result must be fully reproducible via a single bash start.sh.

Origin: Adapted from zai-org/GLM-skills/glmv-prd-to-app (Apache 2.0). ZHIPU API dependencies removed; replaced with Playwright + look_at for prototype analysis.

Phase 0: Material Discovery & Analysis

Before anything else, understand what you're working with.

0a. Locate all inputs

./prd.md                    ← Product requirement document
./prototypes/*.jpg|*.png    ← UI prototype images (the visual truth)
./resources/**/*            ← Images, videos, icons, and other assets

If the materials are in a different location, adapt accordingly. Read the PRD fully.

0b. Deep prototype analysis

For every prototype image:

1. Read the image using the look_at tool (or Read tool for images) — examine it directly. Extract: page identity, layout structure, component inventory, content inventory, color extraction (hex values), typography, interactive states, data patterns.
2. For each image, document:
   • Page identity: which page/view this represents
   • Layout structure: header, sidebar, main content, footer, modals
   • Component inventory: every button, form, card, table, list, nav element
   • Content inventory: all visible text, numbers, labels, placeholder content
   • Color extraction: primary, secondary, accent, background, text colors (hex values)
   • Typography: font sizes, weights, hierarchy observed
   • Interactive states: hover effects, active tabs, selected items, toggles
   • Data patterns: what data populates lists/tables/cards — this drives seed data
3. Build a page map showing navigation flow between prototype pages.

0c. Resource inventory

List all files in ./resources/ and map each to where it appears in the prototypes. Every resource file must be used in the final application where relevant.

Phase 1: System Design Document

Produce a comprehensive design document at ./docs/design.md.

1a. Data Model

For each entity, specify:

• Table/collection name
• All fields with types, constraints, defaults
• Relationships (foreign keys, many-to-many)
• Indexes needed for query patterns
• Content mapping: which prototype elements map to which fields

1b. API Design

For every page interaction, define an API endpoint:

• Method + path
• Request params/body schema
• Response schema with example
• Which prototype interaction triggers this API
• Error responses

1c. Frontend Architecture

• Component hierarchy (tree structure)
• Route definitions mapping to prototype pages
• State management approach
• How each prototype page maps to components

1d. Technology Stack

Choose based on PRD complexity:

Phase 2: Seed Data Generation

Rules

1. Extract from prototypes: Every piece of visible text, image, number in the prototype images must appear in seed data. Re-read each prototype image and transcribe content.
2. Complete coverage: Every list/table/card/dropdown must match prototype content exactly.
3. Use resource files: Map resource files from ./resources/ to seed data entries.
4. No placeholders: No "Lorem ipsum", no "Test Item 1", no placeholder images.
5. Support all states: Include data for empty states, loaded states, error scenarios.

Phase 3: Backend Implementation

3a. Database schema — migrations with constraints, indexes, foreign keys

3b. API endpoints — route handlers, validation, error handling, curl-tested

3c. Seed data loading — idempotent re-seeding, dependency order

3d. Static file serving — backend serves resource files

Phase 4: Frontend Implementation

4a. Global styles and tokens — color variables, typography, spacing from prototypes

4b. Page-by-page implementation

For each prototype image:

1. Re-read the prototype image
2. Build page component matching layout exactly
3. Wire up API calls
4. Implement all interactions (navigation, forms, search, filter, sort, modals, states)

4c. Resource integration — copy from ./resources/, reference correctly

4d. Responsive — match prototype viewport, breakpoints if mobile views shown

Phase 5: Visual Verification Loop

Repeat for every page. Max 3 iterations.

5a. Render page to screenshot

Start local server, capture with Playwright:

python3 -c "
from playwright.sync_api import sync_playwright
with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page(viewport={'width': 1280, 'height': 800})
    page.goto('http://localhost:3000/page-path')
    page.wait_for_load_state('networkidle')
    page.screenshot(path='docs/screenshots/page_name.png', full_page=True)
    browser.close()
"

5b. Visual comparison

Read prototype image and screenshot side by side. Compare:

• Layout, colors, typography, content, spacing, images, components

5c. Fix discrepancies → re-render → re-compare

Phase 6: Integration Testing

6a. API health check — curl each endpoint, verify status codes

6b. E2E flow — walk through every user flow from PRD

6c. Fix issues — CORS, URL mismatches, data format problems

Phase 7: Deployment Script

Generate ./start.sh — fully self-contained, works from absolute zero.

Requirements: install deps → setup DB → migrations → seed → build frontend → start both → app at :3000

Phase 8: Documentation

• ./docs/design.md — final architecture, data model, API reference
• ./README.md — overview, stack, quick start, structure

Deliverables Checklist

• All PRD features implemented
• All prototype pages built
• Visual match verified via screenshots
• All resources used
• Seed data matches prototypes
• All API endpoints working
• All interactions functional
• bash start.sh works from clean state
• Documentation complete

Critical Principles

1. Prototypes are truth — prototype wins over PRD text for visual/layout decisions
2. No shortcuts on data — all visible content from database via APIs
3. Complete implementation — every page, feature, interaction
4. Resources must be used — matching files from ./resources/
5. Reproducibility — start.sh works from absolute zero
6. Verify, don't assume — screenshot comparison + API checks + startup test

Boundaries

• Do not use for a small isolated UI change or documentation-only task.