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

CODEBLOCK0

Examples

Frontend (React)

CODEBLOCK1

Backend (Django)

CODEBLOCK2

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. 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

Stack	Frameworks
Frontend	React, Vue, Angular, Svelte, Next.js (App/Pages Router), Nuxt, SvelteKit, Remix, Astro
Backend

NestJS, Express, Fastify, Django, Django REST Framework, FastAPI, Flask | | Fullstack | Next.js (API routes + pages), Nuxt (server/ + pages/), Django (views + templates) |

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:

CODEBLOCK4

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:

Field	Description
Route path	e.g. /user/list, INLINECODE7
Page title

From route config, breadcrumbs, or page component |
| Module / menu level | Where it sits in navigation |
| Component file path | Source file(s) implementing this page |

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

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

Field	Description
Endpoint path	e.g. /api/users, INLINECODE9
HTTP method

GET, POST, PUT, DELETE, PATCH |
| Controller/view | Source file handling this route |
| Module/app | Which NestJS module or Django app owns it |
| Auth required | Whether authentication/permissions are needed |

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:

Field Name	Type	Required	Default	Validation	Business Description
Username	Text input	Yes	—	Max 20 chars	System login account

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. 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":

CODEBLOCK5

Cover all interaction types:

• - Page load / initialization (default queries, preloaded data)
• Search / filter / reset
• CRUD operations (create, read, update, delete)
• Table: pagination, sorting, row selection, bulk actions
• Form submission & validation
• Status transitions (e.g. approval flows: pending → approved → rejected)
• Import / export
• Field interdependencies (selecting value A changes options in field B)
• Permission controls (buttons/fields visible only to certain roles)
• Polling / auto-refresh / real-time updates

E. API Dependencies

Case 1: API is integrated (real HTTP calls in code)

API Name	Method	Path	Trigger	Key Params	Notes
Get users	GET	/api/user/list	Load, search	page, size, keyword	Paginated

Case 2: API not integrated (mock/hardcoded data)

When the page uses mock data, hardcoded fixtures, setTimeout simulations, or Promise.resolve() stubs — the API isn't real yet. Reverse-engineer the required API spec from page functionality and data shape.

For each needed API, document:

• - Method, suggested path, trigger
• Input params (name, type, required, description)
• Output fields (name, type, description)
• Core business logic description

Detection signals:

• - setTimeout / Promise.resolve() returning data → mock
• Data defined in component or *.mock.* files → mock
• Real HTTP calls (axios, fetch, service layer) with real paths → integrated
• INLINECODE25 directory → mock

F. Page Relationships

• - Inbound: Which pages link here? What parameters do they pass?
• Outbound: Where can users navigate from here? What parameters?
• Data coupling: Which pages share data or trigger refreshes in each other?

---

Phase 3 — Generate Documentation

Output Structure

Create prd/ in project root (or user-specified directory):

CODEBLOCK6

README.md Template

CODEBLOCK7

Per-Page Document Template

CODEBLOCK8

---

Key Principles

1. Business Language First

Don't write "calls useState to manage loading state." Write "search button shows a spinner to prevent duplicate submissions."

Don't write "useEffect fetches on mount." Write "page automatically loads the first page of results on open."

Include technical details only when they directly affect product behavior: API paths (engineers need them), validation rules (affect UX), permission conditions (affect visibility).

2. Don't Miss Hidden Logic

Code contains logic PMs may not realize exists:

• - Field interdependencies (type A shows field X; type B shows field Y)
• Conditional button visibility
• Data formatting (currency with 2 decimals, date formats, status label mappings)
• Default sort order and page size
• Debounce/throttle effects on user input
• Polling / auto-refresh intervals

3. Exhaustively List Enums

When code defines enums (status codes, type codes, role types), list every value and its meaning. These are often scattered across constants files, component valueEnum configs, or API response mappers.

4. Mark Uncertainty — Don't Guess

If a field or logic's business meaning can't be determined from code (e.g. abbreviated variable names, overly complex conditionals), mark it [TBC] and explain what you observed and why you're uncertain. Never fabricate business meaning.

5. Keep Page Files Self-Contained

Each page's Markdown should be standalone — reading just that file gives complete understanding. Use relative links when referencing other pages or appendix entries.

---

Page Type Strategies

Frontend Pages

Page Type	Focus Areas
List / Table	Search conditions, columns, row actions, pagination, bulk ops
Form / Create-Edit

Every field, validation, interdependencies, post-submit behavior | | Detail / View | Displayed info, tab/section organization, available actions | | Modal / Drawer | Describe as part of triggering page — not a separate file. But fully document content | | Dashboard | Data cards, charts, metrics meaning, filter dimensions, refresh frequency |

Backend Endpoints (NestJS / Django / Express)

Endpoint Type	Focus Areas
CRUD resource	All fields (from DTO/serializer), validation rules, permissions, pagination, filtering, sorting
Auth endpoints

Login/register flow, token format, refresh logic, password reset, OAuth providers | | File upload | Accepted types, size limits, storage destination, processing pipeline | | Webhook / event | Trigger conditions, payload shape, retry policy, idempotency | | Background job | Trigger, schedule, input/output, failure handling, monitoring | | Admin views (Django) | Registered models, listdisplay, searchfields, filters, inline models, custom actions |

---

Execution Pacing

Large projects (>15 pages): Work in batches of 3-5 pages per module. Complete system overview + page inventory first. Output each batch for user review before proceeding.

Small projects (≤15 pages): Complete all analysis in one pass.

---

Common Pitfalls

Pitfall	Fix
Using component names as page names	INLINECODE30 → "User Management List"
Skipping modals and drawers

They contain critical business logic — document fully |
| Missing i18n field names | Check translation files, not just component JSX |
| Ignoring dynamic route params | /order/:id = page requires an order ID to load |
| Forgetting permission controls | Document which roles see which buttons/pages |
| Assuming all APIs are real | Check for mock data patterns before documenting endpoints |
| Skipping Django admin customization | admin.py often contains critical business rules (list filters, custom actions, inlines) |
| Missing NestJS guards/pipes | @UseGuards, @UsePipes contain auth and validation logic that affects behavior |
| Ignoring database constraints | Model field constraints (unique, max_length, choices) are validation rules for the PRD |
| Overlooking middleware | Auth middleware, rate limiters, and CORS config define system-wide behavior |

---

Tooling

Scripts

Script	Purpose	Usage
INLINECODE35	Scan codebase → extract routes, APIs, models, enums, structure	INLINECODE36
INLINECODE37

Generate PRD directory skeleton from analysis JSON | python3 prd_scaffolder.py analysis.json |

Recommended workflow:
CODEBLOCK9

Both scripts are stdlib-only — no pip install needed.

References

File	Contents
INLINECODE39	Validation checklist for completeness, accuracy, readability
INLINECODE40

Framework-specific patterns for routes, state, APIs, forms, permissions |

---

Attribution

This skill was inspired by code-to-prd by @lihanglogan, who proposed the original concept and methodology in PR #368. The core three-phase workflow (global scan → page-by-page analysis → structured document generation) originated from that work. This version was rebuilt from scratch in English with added tooling (analysis scripts, scaffolder, framework reference, quality checklist).