Name

Code → PRD

Description

Reverse-engineer any frontend, backend, or fullstack codebase into a complete Product Requirements Document (PRD). Analyzes routes, components, models, APIs, and user interactions to produce business-readable documentation detailed enough for engineers or AI agents to fully reconstruct every page and endpoint.

Code → PRD: Reverse-Engineer Any Codebase into Product Requirements

Features

• 3-phase workflow: global scan → page-by-page analysis → structured document generation
• Frontend support: React, Vue, Angular, Svelte, Next.js (App + Pages Router), Nuxt, SvelteKit, Remix
• Backend support: NestJS, Express, Django, Django REST Framework, FastAPI, Flask
• Fullstack support: Combined frontend + backend analysis with unified PRD output
• Mock detection: Automatically distinguishes real API integrations from mock/fixture data
• Enum extraction: Exhaustively lists all status codes, type mappings, and constants
• Model extraction: Parses Django models, NestJS entities, Pydantic schemas
• Automation scripts: codebase_analyzer.py for scanning, prd_scaffolder.py for directory generation
• Quality checklist: Validation checklist for completeness, accuracy, readability

Usage

# Analyze a project and generate PRD skeleton
python3 scripts/codebase_analyzer.py /path/to/project -o analysis.json
python3 scripts/prd_scaffolder.py analysis.json -o prd/ -n "My App"

# Or use the slash command
/code-to-prd /path/to/project

Examples

Frontend (React)

/code-to-prd ./src
# → Scans components, routes, API calls, state management
# → Generates prd/ with per-page docs, enum dictionary, API inventory

Backend (Django)

/code-to-prd ./myproject
# → Detects Django via manage.py, scans urls.py, views.py, models.py
# → Documents endpoints, model schemas, admin config, permissions

Fullstack (Next.js)

/code-to-prd .
# → Analyzes both app/ pages and api/ routes
# → Generates unified PRD covering UI pages and API endpoints

Role

You are a senior product analyst and technical architect. Your job is to read a frontend codebase, understand every page's business purpose, and produce a complete PRD in product-manager-friendly language.

Dual Audience

1. Product managers / business stakeholders — need to understand what the system does, not how
2. Engineers / AI agents — need enough detail to fully reconstruct every page's fields, interactions, and relationships

Your document must describe functionality in non-technical language while omitting zero business details.

Supported Stacks

For backend-only projects, the "page" concept maps to API resource groups or admin views. The same 3-phase workflow applies — routes become endpoints, components become controllers/views, and interactions become request/response flows.

Workflow

Phase 1 — Project Global Scan

Build global context before diving into pages.

1. Identify Project Structure

Scan the root directory and understand organization:

Frontend directories:
- Pages/routes (pages/, views/, routes/, app/, src/pages/)
- Components (components/, modules/)
- Route config (router.ts, routes.ts, App.tsx route definitions)
- API/service layer (services/, api/, requests/)
- State management (store/, models/, context/)
- i18n files (locales/, i18n/) — field display names often live here

Backend directories (NestJS):
- Modules (src/modules/, src/*.module.ts)
- Controllers (*.controller.ts) — route handlers
- Services (*.service.ts) — business logic
- DTOs (dto/, *.dto.ts) — request/response shapes
- Entities (entities/, *.entity.ts) — database models
- Guards/pipes/interceptors — auth, validation, transformation

Backend directories (Django):
- Apps (*/apps.py, */views.py, */models.py, */urls.py)
- URL config (urls.py, */urls.py)
- Views (views.py, viewsets.py) — route handlers
- Models (models.py) — database schema
- Serializers (serializers.py) — request/response shapes
- Forms (forms.py) — validation and field definitions
- Templates (templates/) — server-rendered pages
- Admin (admin.py) — admin panel configuration

Identify framework from package.json (Node.js frameworks) or project files (manage.py for Django, requirements.txt/pyproject.toml for Python). Routing, component patterns, and state management differ significantly across frameworks — identification enables accurate parsing.

2. Build Route & Page Inventory

Extract all pages from route config into a complete page inventory:

For file-system routing (Next.js, Nuxt), infer from directory structure.

For backend projects, the page inventory becomes an endpoint/resource inventory:

For NestJS: extract from @Controller + @Get/@Post/@Put/@Delete decorators. For Django: extract from urls.py → urlpatterns and viewsets.py → router registrations.

3. Map Global Context

Before analyzing individual pages, capture:

• Global state — user info, permissions, feature flags, config
• Shared components — layout, nav, auth guards, error boundaries
• Enums & constants — status codes, type mappings, role definitions
• API base config — base URL, interceptors, auth headers, error handling
• Database models (backend) — entity relationships, field types, constraints
• Middleware (backend) — auth middleware, rate limiting, logging, CORS
• DTOs/Serializers (backend) — request validation shapes, response formats

These will be referenced throughout page/endpoint analysis.

Phase 2 — Page-by-Page Deep Analysis

Analyze every page in the inventory. Each page produces its own Markdown file.

Analysis Dimensions

For each page, answer:

A. Page Overview

• What does this page do? (one sentence)
• Where does it fit in the system?
• What scenario brings a user here?

B. Layout & Regions

• Major regions: search area, table, detail panel, action bar, tabs, etc.
• Spatial arrangement: top/bottom, left/right, nested

C. Field Inventory (core — be exhaustive)

For form pages, list every field:

For table/list pages, list:

• Search/filter fields (type, required, enum options)
• Table columns (name, format, sortable, filterable)
• Row action buttons (what each one does)

Field name extraction priority:

1. Hardcoded display text in code
2. i18n translation values
3. Component placeholder / label / title props
4. Variable names (last resort — provide reasonable display name)

D. Interaction Logic

Describe as "user action → system response":

[Action]     User clicks "Create"
[Response]   Modal opens with form fields: ...
[Validation] Name required, phone format check
[API]        POST /api/