Back to Details

code-to-prd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Name

名称

Code → PRD
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.
将任意前端、后端或全栈代码库逆向生成为完整的产品需求文档（PRD）。通过分析路由、组件、模型、API以及用户交互，生成具备业务可读性的文档，其详细程度足以让工程师或AI Agent完全重构每个页面和端点。

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

Code → PRD：将任意代码库逆向生成为产品需求文档

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
  • 三步工作流：全局扫描 → 逐页分析 → 结构化文档生成
  • 前端支持：React、Vue、Angular、Svelte、Next.js（App + Pages Router）、Nuxt、SvelteKit、Remix
  • 后端支持：NestJS、Express、Django、Django REST Framework、FastAPI、Flask
  • 全栈支持：结合前端+后端分析，输出统一PRD
  • 模拟数据检测：自动区分真实API集成与模拟/测试数据
  • 枚举提取：全面列出所有状态码、类型映射和常量
  • 模型提取：解析Django模型、NestJS实体、Pydantic模式
  • 自动化脚本：
    codebase_analyzer.py
    用于扫描，
    prd_scaffolder.py
    用于目录生成
  • 质量检查清单：针对完整性、准确性、可读性的验证清单

Usage

使用方法

bash
undefined
bash
undefined

Analyze a project and generate PRD skeleton

分析项目并生成PRD框架

python3 scripts/codebase_analyzer.py /path/to/project -o analysis.json python3 scripts/prd_scaffolder.py analysis.json -o prd/ -n "My App"
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
undefined
/code-to-prd /path/to/project
undefined

Examples

示例

Frontend (React)

前端（React）

bash
/code-to-prd ./src
bash
/code-to-prd ./src

→ Scans components, routes, API calls, state management

→ 扫描组件、路由、API调用、状态管理

→ Generates prd/ with per-page docs, enum dictionary, API inventory

→ 在prd/目录生成单页文档、枚举字典、API清单

undefined
undefined

Backend (Django)

后端（Django）

bash
/code-to-prd ./myproject
bash
/code-to-prd ./myproject

→ Detects Django via manage.py, scans urls.py, views.py, models.py

→ 通过manage.py识别Django，扫描urls.py、views.py、models.py

→ Documents endpoints, model schemas, admin config, permissions

→ 记录端点、模型模式、管理员配置、权限

undefined
undefined

Fullstack (Next.js)

全栈（Next.js）

bash
/code-to-prd .
bash
/code-to-prd .

→ Analyzes both app/ pages and api/ routes

→ 分析app/页面和api/路由

→ Generates unified PRD covering UI pages and API endpoints

→ 生成覆盖UI页面和API端点的统一PRD


---

---

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.
你是资深产品分析师兼技术架构师。你的工作是读取前端代码库，理解每个页面的业务用途，并用产品经理友好的语言生成完整的PRD。

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.
  1. 产品经理/业务利益相关者 — 需要了解系统做什么，而非怎么做
  2. 工程师/AI Agent — 需要足够细节来完全重构每个页面的字段、交互和关联关系
你的文档必须用非技术语言描述功能，同时不遗漏任何业务细节。

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.
技术栈框架
前端React、Vue、Angular、Svelte、Next.js（App/Pages Router）、Nuxt、SvelteKit、Remix、Astro
后端NestJS、Express、Fastify、Django、Django REST Framework、FastAPI、Flask
全栈Next.js（API路由 + 页面）、Nuxt（server/ + pages/）、Django（视图 + 模板）
对于仅后端项目，“页面”概念对应API资源组或管理员视图。同样适用三步工作流 — 路由变为端点，组件变为控制器/视图，交互变为请求/响应流程。

Workflow

工作流程

Phase 1 — Project Global Scan

第一阶段 — 项目全局扫描

Build global context before diving into pages.
在深入分析页面之前，先构建全局上下文。

1. Identify Project Structure

1. 识别项目结构

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.
扫描根目录并理解组织架构：
前端目录：
- 页面/路由（pages/、views/、routes/、app/、src/pages/）
- 组件（components/、modules/）
- 路由配置（router.ts、routes.ts、App.tsx路由定义）
- API/服务层（services/、api/、requests/）
- 状态管理（store/、models/、context/）
- 国际化文件（locales/、i18n/）—— 字段显示名称通常存储于此

后端目录（NestJS）：
- 模块（src/modules/、src/*.module.ts）
- 控制器（*.controller.ts）—— 路由处理器
- 服务（*.service.ts）—— 业务逻辑
- DTO（dto/、*.dto.ts）—— 请求/响应结构
- 实体（entities/、*.entity.ts）—— 数据库模型
- 守卫/管道/拦截器 —— 认证、验证、转换

后端目录（Django）：
- 应用（*/apps.py、*/views.py、*/models.py、*/urls.py）
- URL配置（urls.py、*/urls.py）
- 视图（views.py、viewsets.py）—— 路由处理器
- 模型（models.py）—— 数据库模式
- 序列化器（serializers.py）—— 请求/响应结构
- 表单（forms.py）—— 验证和字段定义
- 模板（templates/）—— 服务器渲染页面
- 管理员（admin.py）—— 管理面板配置
从
package.json
（Node.js框架）或项目文件（Django的
manage.py
、Python的
requirements.txt
/
pyproject.toml
）识别框架。不同框架的路由、组件模式和状态管理差异显著——识别框架可实现准确解析。

2. Build Route & Page Inventory

2. 构建路由与页面清单

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.py
→ 
urlpatterns
and 
viewsets.py
→ router registrations.
从路由配置中提取所有页面，生成完整的页面清单：
字段描述
路由路径例如 
/user/list
、
/order/:id
页面标题来自路由配置、面包屑或页面组件
模块/菜单层级在导航中的位置
组件文件路径实现此页面的源文件
对于文件系统路由（Next.js、Nuxt），从目录结构推断。
对于后端项目，页面清单变为端点/资源清单：
字段描述
端点路径例如 
/api/users
、
/api/orders/:id
HTTP方法GET、POST、PUT、DELETE、PATCH
控制器/视图处理此路由的源文件
模块/应用所属的NestJS模块或Django应用
是否需要认证是否需要身份验证/权限
对于NestJS：从
@Controller
+ 
@Get/@Post/@Put/@Delete
装饰器提取。 对于Django：从
urls.py
→ 
urlpatterns
和
viewsets.py
→ 路由器注册提取。

3. Map Global Context

3. 映射全局上下文

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.
在分析单个页面之前，捕获以下内容：
  • 全局状态 — 用户信息、权限、功能标志、配置
  • 共享组件 — 布局、导航、认证守卫、错误边界
  • 枚举与常量 — 状态码、类型映射、角色定义
  • API基础配置 — 基础URL、拦截器、认证头、错误处理
  • 数据库模型（后端）—— 实体关系、字段类型、约束
  • 中间件（后端）—— 认证中间件、速率限制、日志、CORS
  • DTO/序列化器（后端）—— 请求验证结构、响应格式
这些将在页面/端点分析中被引用。

Phase 2 — Page-by-Page Deep Analysis

第二阶段 — 逐页深度分析

Analyze every page in the inventory. Each page produces its own Markdown file.
分析清单中的每个页面。每个页面生成单独的Markdown文件。

Analysis Dimensions

分析维度

For each page, answer:
对于每个页面，回答以下问题：
A. Page Overview
A. 页面概述
  • What does this page do? (one sentence)
  • Where does it fit in the system?
  • What scenario brings a user here?
  • 此页面的用途是什么？（一句话描述）
  • 它在系统中的位置？
  • 用户会在什么场景下访问此页面？
B. Layout & Regions
B. 布局与区域
  • Major regions: search area, table, detail panel, action bar, tabs, etc.
  • Spatial arrangement: top/bottom, left/right, nested
  • 主要区域：搜索区、表格、详情面板、操作栏、标签页等
  • 空间布局：上下、左右、嵌套
C. Field Inventory (core — be exhaustive)
C. 字段清单（核心——需全面）
For form pages, list every field:
Field NameTypeRequiredDefaultValidationBusiness Description
UsernameText inputYes—Max 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)
对于表单页面，列出所有字段：
字段名称类型是否必填默认值验证规则业务描述
Username文本输入是—最多20字符系统登录账号
对于表格/列表页面，列出：
  • 搜索/筛选字段（类型、是否必填、枚举选项）
  • 表格列（名称、格式、是否可排序、是否可筛选）
  • 行操作按钮（每个按钮的功能）
字段名称提取优先级：
  1. 代码中的硬编码显示文本
  2. 国际化翻译值
  3. 组件的
    placeholder
    / 
    label
    / 
    title
    属性
  4. 变量名（最后手段——提供合理的显示名称）
D. Interaction Logic
D. 交互逻辑
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
以**“用户操作 → 系统响应”**的形式描述：
[操作]     用户点击“创建”
[响应]     打开包含以下表单字段的弹窗：...
[验证]     名称必填，手机号格式检查
[API]      携带表单数据调用POST /api/user/create
[成功]     弹出提示“创建成功”，关闭弹窗，刷新列表
[失败]     显示API错误信息
覆盖所有交互类型：
  • 页面加载/初始化（默认查询、预加载数据）
  • 搜索/筛选/重置
  • CRUD操作（创建、读取、更新、删除）
  • 表格：分页、排序、行选择、批量操作
  • 表单提交与验证
  • 状态转换（例如审批流程：待处理 → 已批准 → 已拒绝）
  • 导入/导出
  • 字段依赖关系（选择值A会改变字段B的选项）
  • 权限控制（按钮/字段仅对特定角色可见）
  • 轮询/自动刷新/实时更新
E. API Dependencies
E. API依赖
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
场景1：已集成API（代码中有真实HTTP调用）
API名称方法路径触发条件关键参数备注
获取用户列表GET/api/user/list页面加载、搜索page、size、keyword分页
场景2：未集成API（模拟/硬编码数据）
当页面使用模拟数据、硬编码测试数据、
setTimeout
模拟或
Promise.resolve()
存根时——API尚未实现。从页面功能和数据结构逆向推导所需的API规格。
对于每个所需API，记录：
  • 方法、建议路径、触发条件
  • 输入参数（名称、类型、是否必填、描述）
  • 输出字段（名称、类型、描述）
  • 核心业务逻辑描述
检测信号：
  • setTimeout
    / 
    Promise.resolve()
    返回数据 → 模拟
  • 数据定义在组件或
    *.mock.*
    文件中 → 模拟
  • 真实HTTP调用（
    axios
    、
    fetch
    、服务层）带真实路径 → 已集成
  • __mocks__
    目录 → 模拟
F. Page Relationships
F. 页面关联关系
  • 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
在项目根目录（或用户指定目录）创建
prd/
：
prd/
├── README.md                     # 系统概述
├── pages/
│   ├── 01-user-mgmt-list.md      # 每个页面对应一个文件
│   ├── 02-user-mgmt-detail.md
│   ├── 03-order-mgmt-list.md
│   └── ...
└── appendix/
    ├── enum-dictionary.md         # 所有枚举、状态码、类型映射
    ├── page-relationships.md      # 页面间导航映射
    └── api-inventory.md           # 完整API参考

README.md Template

README.md模板

markdown
undefined
markdown
undefined

[System Name] — Product Requirements Document

[系统名称] — 产品需求文档

System Overview

系统概述

[2-3 paragraphs: what the system does, business context, primary users]
[2-3段：系统用途、业务背景、主要用户]

Module Overview

模块概述

ModulePagesCore Functionality
User ManagementUser list, User detail, Role mgmtCRUD users, assign roles and permissions
模块页面核心功能
用户管理用户列表、用户详情、角色管理用户增删改查、角色与权限分配

Page Inventory

页面清单

#Page NameRouteModuleDoc Link
1User List/user/listUser Mgmt→
#页面名称路由模块文档链接
1用户列表/user/list用户管理→

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.]
undefined
[全局规则：所有删除操作需确认、列表默认按创建时间降序排列等]
undefined

Per-Page Document Template

单页文档模板

markdown
undefined
markdown
undefined

[Page Name]

[页面名称]

Route: 
/xxx/xxx
Module: [Module name] Generated: [Date]
路由: 
/xxx/xxx
模块: [模块名称] 生成时间: [日期]

Overview

概述

[2-3 sentences: core function and use case]
[2-3句话：核心功能和使用场景]

Layout

布局

[Region breakdown — text description or ASCII diagram]
[区域分解——文字描述或ASCII图]

Fields

字段

[Region: e.g. "Search Filters"]

[区域：例如“搜索筛选器”]

FieldTypeRequiredOptions / EnumDefaultNotes
字段类型是否必填选项/枚举默认值备注

[Region: e.g. "Data Table"]

[区域：例如“数据表格”]

ColumnFormatSortableFilterableNotes
列格式是否可排序是否可筛选备注

[Region: e.g. "Actions"]

[区域：例如“操作按钮”]

ButtonVisibility ConditionBehavior
按钮可见条件行为

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依赖

APIMethodPathTriggerNotes
...............
API方法路径触发条件备注
...............

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

1. 优先使用业务语言

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).
不要写“调用
useState
管理加载状态”，而要写“搜索按钮显示加载动画以防止重复提交”。
不要写“useEffect在挂载时发起请求”，而要写“页面打开时自动加载第一页结果”。
仅当技术细节直接影响产品行为时才包含：API路径（工程师需要）、验证规则（影响用户体验）、权限条件（影响可见性）。

2. Don't Miss Hidden Logic

2. 不要遗漏隐藏逻辑

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
代码中包含产品经理可能未意识到的逻辑：
  • 字段依赖关系（选择类型A显示字段X；选择类型B显示字段Y）
  • 按钮条件可见性
  • 数据格式化（保留两位小数的货币、日期格式、状态标签映射）
  • 默认排序顺序和页面大小
  • 用户输入的防抖/节流效果
  • 轮询/自动刷新间隔

3. Exhaustively List Enums

3. 全面列出枚举

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.
当代码定义枚举（状态码、类型码、角色类型）时，列出每个值及其含义。这些通常分散在常量文件、组件
valueEnum
配置或API响应映射中。

4. Mark Uncertainty — Don't Guess

4. 标记不确定性——不要猜测

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

5. 保持页面文件独立完整

Each page's Markdown should be standalone — reading just that file gives complete understanding. Use relative links when referencing other pages or appendix entries.
每个页面的Markdown应独立完整——仅阅读该文件即可获得完整理解。引用其他页面或附录条目时使用相对链接。

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)

后端端点（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
端点类型重点关注领域
CRUD资源所有字段（来自DTO/序列化器）、验证规则、权限、分页、筛选、排序
认证端点登录/注册流程、令牌格式、刷新逻辑、密码重置、OAuth提供商
文件上传接受的类型、大小限制、存储目的地、处理流程
Webhook/事件触发条件、负载结构、重试策略、幂等性
后台任务触发条件、调度、输入/输出、故障处理、监控
管理员视图（Django）注册模型、list_display、search_fields、筛选器、内联模型、自定义操作

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.
大型项目（>15个页面）： 按模块分批次处理，每批3-5个页面。先完成系统概述+页面清单。在继续之前，输出每批内容供用户审核。
小型项目（≤15个页面）： 一次性完成所有分析。

Common Pitfalls

常见误区

PitfallFix
Using component names as page names
UserManagementTable
→ "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 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 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
误区解决方法
使用组件名称作为页面名称
UserManagementTable
→ “用户管理列表”
跳过弹窗和抽屉它们包含关键业务逻辑——需完整记录
遗漏国际化字段名称检查翻译文件，而非仅组件JSX
忽略动态路由参数
/order/:id
= 页面需要订单ID才能加载
忘记权限控制记录哪些角色可查看哪些按钮/页面
假设所有API都是真实的在记录端点前检查模拟数据模式
跳过Django管理员自定义
admin.py
通常包含关键业务规则（列表筛选器、自定义操作、内联模型）
遗漏NestJS守卫/管道
@UseGuards
、
@UsePipes
包含影响行为的认证和验证逻辑
忽略数据库约束模型字段约束（唯一、最大长度、选项）是PRD中的验证规则
忽视中间件认证中间件、速率限制器和CORS配置定义了系统级行为

Tooling

工具集

Scripts

脚本

ScriptPurposeUsage
scripts/codebase_analyzer.py
Scan codebase → extract routes, APIs, models, enums, structure
python3 codebase_analyzer.py /path/to/project
scripts/prd_scaffolder.py
Generate PRD directory skeleton from analysis JSON
python3 prd_scaffolder.py analysis.json
Recommended workflow:
bash
undefined
脚本用途使用方法
scripts/codebase_analyzer.py
扫描代码库 → 提取路由、API、模型、枚举、结构
python3 codebase_analyzer.py /path/to/project
scripts/prd_scaffolder.py
从分析JSON生成PRD目录框架
python3 prd_scaffolder.py analysis.json
推荐工作流：
bash
undefined

1. Analyze the project (JSON output — works for frontend, backend, or fullstack)

1. 分析项目（输出JSON——适用于前端、后端或全栈）

python3 scripts/codebase_analyzer.py /path/to/project -o analysis.json
python3 scripts/codebase_analyzer.py /path/to/project -o analysis.json

2. Review the analysis (markdown summary)

2. 查看分析结果（Markdown摘要）

python3 scripts/codebase_analyzer.py /path/to/project -f markdown
python3 scripts/codebase_analyzer.py /path/to/project -f markdown

3. Scaffold the PRD directory with stubs

3. 生成PRD目录框架和占位文件

python3 scripts/prd_scaffolder.py analysis.json -o prd/ -n "My App"
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

4. 按照SKILL.md工作流逐页填充TODO部分


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

两个脚本均**仅依赖标准库**——无需pip安装。

References

参考资料

FileContents
references/prd-quality-checklist.md
Validation checklist for completeness, accuracy, readability
references/framework-patterns.md
Framework-specific patterns for routes, state, APIs, forms, permissions
文件内容
references/prd-quality-checklist.md
针对完整性、准确性、可读性的验证清单
references/framework-patterns.md
路由、状态、API、表单、权限的框架特定模式

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).
此技能灵感来自@lihanglogan的code-to-prd，他在PR #368中提出了原始概念和方法论。核心三步工作流（全局扫描 → 逐页分析 → 结构化文档生成）源自该工作。本版本从零开始用英文重构，并添加了工具（分析脚本、框架生成器、框架参考、质量检查清单）。