code-to-prd

---
name: code-to-prd
description: Use when reverse-engineering a frontend, backend, or fullstack codebase into a business-readable Product Requirements Document detailed enough to reconstruct every page and endpoint.
category: Product
version: 1.0.0
tools: []
---

# Code → PRD

Reverse-engineer any frontend, backend, or fullstack codebase into a complete Product Requirements Document. Analyze 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.

## Dual Audience

Write for two readers at once: product managers and business stakeholders who need to understand *what* the system does, not *how*; and engineers or AI agents who need enough detail to fully reconstruct every page's fields, interactions, and relationships. Describe functionality in non-technical language while omitting zero business detail.

## Supported Stacks

Frontend: React, Vue, Angular, Svelte, Next.js (App and 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, "page" maps to API resource group or admin view — the same three-phase workflow applies, with routes becoming endpoints, components becoming controllers/views, and interactions becoming request/response flows.

## Phase 1 — Global Scan

Build context before diving into individual pages.

**Identify project structure.** Frontend: pages/routes, components, route config, API/service layer, state management, and i18n files (field display names often live here). Backend (NestJS): modules, controllers (route handlers), services (business logic), DTOs (request/response shapes), entities (database models), guards/pipes/interceptors. Backend (Django): apps, URL config, views/viewsets, models, serializers, forms, templates, admin config. Identify the framework from the project's manifest file (package.json, manage.py, requirements.txt/pyproject.toml) — routing and component patterns differ enough across frameworks that misidentifying one leads to inaccurate parsing.

**Build a route/page inventory**: route path, page title, module/menu placement, and the component file(s) implementing it. For file-system routing (Next.js, Nuxt), infer pages from directory structure. For backend projects, build an endpoint inventory instead: path, HTTP method, controller/view, owning module/app, and whether auth is required — extracted from NestJS `@Controller`/`@Get`/`@Post` decorators or Django's `urls.py`/`viewsets.py`.

**Map global context**: global state (user info, permissions, feature flags, config), shared components (layout, nav, auth guards, error boundaries), enums and constants (status codes, type mappings, role definitions), API base config (base URL, interceptors, auth headers, error handling), and — for backends — database models, middleware, and DTO/serializer shapes. Reference these throughout the page-level analysis.

## Phase 2 — Page-by-Page Deep Analysis

Analyze every page in the inventory; produce one document per page, answering:

**A. Overview** — what the page does in one sentence, where it sits in the system, what scenario brings a user here.

**B. Layout & Regions** — major regions (search area, table, detail panel, action bar, tabs) and their spatial arrangement.

**C. Field Inventory** — be exhaustive. For form pages, list every field: name, type, required, default, validation, and a business-language description. For table/list pages: search/filter fields (type, required, enum options), table columns (name, format, sortable, filterable), and row action buttons. Extract field names in priority order: hardcoded display text in code, then i18n translation values, then component placeholder/label/title props, then variable names as a last resort (with a reasonable inferred display name).

**D. Interaction Logic** — describe every interaction as action → response → validation → API call → success/failure outcome. Cover: page load/initialization, search/filter/reset, full CRUD, table pagination/sorting/selection/bulk actions, form submission and validation, status transitions (e.g. pending → approved → rejected), import/export, field interdependencies (selecting A changes B's options), permission-gated visibility, and polling/auto-refresh.

**E. API Dependencies** — for integrated APIs, document method, path, trigger, key params, and notes. For pages using mock/hardcoded data (detected via `setTimeout`/`Promise.resolve()` stubs, fixture files, or a `__mocks__` directory), reverse-engineer the API spec the page implies: method, suggested path, trigger, input params, output fields, and the core business logic — never leave a page's data needs undocumented just because it isn't wired up yet.

**F. Page Relationships** — inbound links (which pages link here, with what params), outbound navigation (where a user can go from here, with what params), and data coupling (pages that share data or trigger refreshes in each other).

## Phase 3 — Generate Documentation

Produce a structured document set: a system-overview document, one document per page, and an appendix.

**System overview** — a 2–3 paragraph description of what the system does, its business context, and its primary users; a module-to-page table (module, pages in it, core functionality); the full page inventory (page name, route, module, link to its detail doc); and a global-notes section covering the permission model and any system-wide interaction rules (e.g. "all deletes require confirmation," "lists default to created_at desc").

**Per-page document** — route, module, and generation date up top; a 2–3 sentence overview of the page's core function and use case; a layout breakdown by region; field tables per region (search filters, data table columns with sortable/filterable flags, action buttons with visibility conditions and behavior); an interactions section covering page load plus one subsection per scenario (trigger, behavior, special rules, and for modals/drawers the fields and validation inside them); an API-dependency table (API, method, path, trigger, notes); page relationships (inbound sources with params, outbound targets with params, data coupling); and a business-rules catch-all for anything that doesn't fit the sections above.

**Appendix** — an enum dictionary (every status code, type mapping, and constant with its meaning), a page-relationship map (the full navigation graph), and a complete API inventory across all pages.

## Key Principles

**Business language first.** Write "search button shows a spinner to prevent duplicate submissions," not "calls `useState` to manage loading state." Write "page automatically loads the first page of results on open," not "useEffect fetches on mount." Include technical detail only when it directly affects product behavior: API paths (engineers need them), validation rules (affect UX), permission conditions (affect visibility).

**Don't miss hidden logic** — field interdependencies, conditional button visibility, data formatting rules (currency decimals, date formats, status-label mappings), default sort order and page size, debounce/throttle effects, polling intervals. These exist in code whether or not a PM realizes it.

**Exhaustively list enums.** When code defines status codes, type codes, or role types, list every value and its meaning — these are often scattered across constants files, component config objects, and API response mappers.

**Mark uncertainty, don't guess.** If a field's or logic's business meaning can't be determined from the code (abbreviated variable names, overly complex conditionals), mark it `[TBC]` and explain what was observed and why it's uncertain. Never fabricate business meaning.

**Keep both audiences served in every section** — a PM should be able to skip the API table and still understand the page; an engineer should find every field, validation rule, and endpoint they need without reading prose.