Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
alirezarezvani avatar

Code To Prd

  • 625 installs
  • 23.5k repo stars
  • Updated July 17, 2026
  • alirezarezvani/claude-skills

code-to-prd is a Claude Code skill that automatically converts an existing Next.js or React codebase into a structured Product Requirements Document an agent can use for new feature planning or refactoring.

About

code-to-prd is a documentation generation skill from alirezarezvani/claude-skills that reverse-engineers Next.js and React projects into Product Requirements Documents. The skill scans project roots to detect frameworks, key dependencies like Next 14.1.0 and React 18.2.0, and structural metrics including total file counts, component directories, API route folders, and state management paths. Developers reach for code-to-prd when onboarding agents to a brownfield codebase, planning new features against existing architecture, or creating PRD artifacts from undocumented React applications. Example output maps 87 total files with 42 components and 35 modules, producing agent-readable PRD documents that capture stack type, route directories, and dependency versions.

  • Analyzes full project structure including 87 files, 42 components, 8 routes and detected frameworks
  • Extracts key dependencies, route mappings, API endpoints and state management patterns
  • Produces a structured PRD from real code that agents can immediately action
  • Works on fullstack TypeScript applications with Next.js, React Query and Tailwind
  • Creates the handoff artifact required before invoking feature-planning or implementation agents

Code To Prd by the numbers

  • 625 all-time installs (skills.sh)
  • Ranked #649 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
  • Security screen: LOW risk (skills.sh audit)
  • Data as of Jul 31, 2026 (Skillselion catalog sync)
npx skills add https://github.com/alirezarezvani/claude-skills --skill code-to-prd

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs625
repo stars23.5k
Security audit3 / 3 scanners passed
Last updatedJuly 17, 2026
Repositoryalirezarezvani/claude-skills

How do you generate a PRD from an existing React codebase?

Automatically convert an existing Next.js or React codebase into a clear Product Requirements Document that an agent can use for new features or refactoring.

Who is it for?

Developers onboarding AI agents to brownfield Next.js or React codebases who need a PRD before feature work or refactoring.

Skip if: Greenfield projects with no existing code or teams that already maintain up-to-date PRD documents.

When should I use this skill?

A developer asks to reverse-engineer a codebase into a PRD, document an existing Next.js or React app, or prepare agent context for refactoring.

What you get

Product Requirements Document with framework detection, dependency versions, route maps, and component structure inventory

  • Product Requirements Document
  • Codebase structure inventory

By the numbers

  • Example project scan maps 87 total files, 42 components, and 35 modules
  • Detects Next.js 14.1.0, React 18.2.0, Tailwind CSS 3.4.1, and TanStack React Query 5.17.0

Files

SKILL.mdMarkdownGitHub ↗

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

StackFrameworks
FrontendReact, Vue, Angular, Svelte, Next.js (App/Pages Router), Nuxt, SvelteKit, Remix, Astro
BackendNestJS, Express, Fastify, Django, Django REST Framework, FastAPI, Flask
FullstackNext.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:

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:

FieldDescription
Route pathe.g. /user/list, /order/:id
Page titleFrom route config, breadcrumbs, or page component
Module / menu levelWhere it sits in navigation
Component file pathSource 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:

FieldDescription
Endpoint pathe.g. /api/users, /api/orders/:id
HTTP methodGET, POST, PUT, DELETE, PATCH
Controller/viewSource file handling this route
Module/appWhich NestJS module or Django app owns it
Auth requiredWhether authentication/permissions are needed

For NestJS: extract from @Controller + @Get/@Post/@Put/@Delete decorators. For Django: extract from urls.pyurlpatterns 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 NameTypeRequiredDefaultValidationBusiness Description
UsernameText inputYesMax 20 charsSystem 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. 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/user/create with form data
[Success]    Toast "Created successfully", close modal, refresh list
[Failure]    Show API error message

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 NameMethodPathTriggerKey ParamsNotes
Get usersGET/api/user/listLoad, searchpage, size, keywordPaginated

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
  • __mocks__ 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):

prd/
├── README.md                     # System overview
├── pages/
│   ├── 01-user-mgmt-list.md      # One file per page
│   ├── 02-user-mgmt-detail.md
│   ├── 03-order-mgmt-list.md
│   └── ...
└── appendix/
    ├── enum-dictionary.md         # All enums, status codes, type mappings
    ├── page-relationships.md      # Navigation map between pages
    └── api-inventory.md           # Complete API reference
README.md Template
# [System Name] — Product Requirements Document

## System Overview
[2-3 paragraphs: what the system does, business context, primary users]

## Module Overview

| Module | Pages | Core Functionality |
|--------|-------|--------------------|
| User Management | User list, User detail, Role mgmt | CRUD users, assign roles and permissions |

## Page Inventory

| # | Page Name | Route | Module | Doc Link |
|---|-----------|-------|--------|----------|
| 1 | User List | /user/list | User Mgmt | [→](./pages/01-user-mgmt-list.md) |

## Global Notes

### Permission Model
[Summarize auth/role system if present in code]

### Common Interaction Patterns
[Global rules: all deletes require confirmation, lists default to created_at desc, etc.]
Per-Page Document Template
# [Page Name]

> **Route:** `/xxx/xxx`
> **Module:** [Module name]
> **Generated:** [Date]

## Overview
[2-3 sentences: core function and use case]

## Layout
[Region breakdown — text description or ASCII diagram]

## Fields

### [Region: e.g. "Search Filters"]
| Field | Type | Required | Options / Enum | Default | Notes |
|-------|------|----------|---------------|---------|-------|

### [Region: e.g. "Data Table"]
| Column | Format | Sortable | Filterable | Notes |
|--------|--------|----------|-----------|-------|

### [Region: e.g. "Actions"]
| Button | Visibility Condition | Behavior |
|--------|---------------------|----------|

## Interactions

### Page Load
[What happens on mount]

### [Scenario: e.g. "Search"]
- **Trigger:** [User action]
- **Behavior:** [System response]
- **Special rules:** [If any]

### [Scenario: e.g. "Create"]
- **Trigger:** ...
- **Modal/drawer content:** [Fields and logic inside]
- **Validation:** ...
- **On success:** ...

## API Dependencies

| API | Method | Path | Trigger | Notes |
|-----|--------|------|---------|-------|
| ... | ... | ... | ... | ... |

## Page Relationships
- **From:** [Source pages + params]
- **To:** [Target pages + params]
- **Data coupling:** [Cross-page refresh triggers]

## Business Rules
[Anything that doesn't fit above]

---

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 TypeFocus Areas
List / TableSearch conditions, columns, row actions, pagination, bulk ops
Form / Create-EditEvery field, validation, interdependencies, post-submit behavior
Detail / ViewDisplayed info, tab/section organization, available actions
Modal / DrawerDescribe as part of triggering page — not a separate file. But fully document content
DashboardData cards, charts, metrics meaning, filter dimensions, refresh frequency

Backend Endpoints (NestJS / Django / Express)

Endpoint TypeFocus Areas
CRUD resourceAll fields (from DTO/serializer), validation rules, permissions, pagination, filtering, sorting
Auth endpointsLogin/register flow, token format, refresh logic, password reset, OAuth providers
File uploadAccepted types, size limits, storage destination, processing pipeline
Webhook / eventTrigger conditions, payload shape, retry policy, idempotency
Background jobTrigger, schedule, input/output, failure handling, monitoring
Admin views (Django)Registered models, list_display, search_fields, 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

PitfallFix
Using component names as page namesUserManagementTable → "User Management List"
Skipping modals and drawersThey contain critical business logic — document fully
Missing i18n field namesCheck translation files, not just component JSX
Ignoring dynamic route params/order/:id = page requires an order ID to load
Forgetting permission controlsDocument which roles see which buttons/pages
Assuming all APIs are realCheck for mock data patterns before documenting endpoints
Skipping Django admin customizationadmin.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 constraintsModel field constraints (unique, max_length, choices) are validation rules for the PRD
Overlooking middlewareAuth middleware, rate limiters, and CORS config define system-wide behavior

---

Tooling

Scripts

ScriptPurposeUsage
scripts/codebase_analyzer.pyScan codebase → extract routes, APIs, models, enums, structurepython3 codebase_analyzer.py /path/to/project
scripts/prd_scaffolder.pyGenerate PRD directory skeleton from analysis JSONpython3 prd_scaffolder.py analysis.json

Recommended workflow:

# 1. Analyze the project (JSON output — works for frontend, backend, or fullstack)
python3 scripts/codebase_analyzer.py /path/to/project -o analysis.json

# 2. Review the analysis (markdown summary)
python3 scripts/codebase_analyzer.py /path/to/project -f markdown

# 3. Scaffold the PRD directory with stubs
python3 scripts/prd_scaffolder.py analysis.json -o prd/ -n "My App"

# 4. Fill in TODO sections page-by-page using the SKILL.md workflow

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

References

FileContents
references/prd-quality-checklist.mdValidation checklist for completeness, accuracy, readability
references/framework-patterns.mdFramework-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).

Related skills

How it compares

Pick code-to-prd when you need agent-ready PRD artifacts from an existing Next.js or React repo rather than writing requirements from scratch.

FAQ

Which frameworks does code-to-prd support?

code-to-prd supports Next.js and React codebases. The skill detects frameworks, key dependencies with versions, route directories, API paths, state management folders, and component counts to build a structured PRD.

What does code-to-prd output include?

code-to-prd outputs a Product Requirements Document with project metadata, detected frameworks, dependency versions, stack type classification, and structural inventory of components, modules, routes, and API directories.

Is Code To Prd safe to install?

skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.

Productivity & Planningintegrationsfrontendbackend

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.