[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KBTGMB4WZFD684TXWBZJ7K":3,"skill-same:01M6KBTGMB4WZFD684TXWBZJ7K":144},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":68,"commitSha":69,"skillDirectory":70,"forksCount":71,"repositoryHtmlUrl":72,"repositoryHomepageUrl":6,"ownerHtmlUrl":73,"ownerBlogUrl":74,"ownerDescription":6,"updatedAt":75,"install":76,"resources":89},"01M6KBTGMB4WZFD684TXWBZJ7K","code-to-prd",null,"Reverse-engineer any codebase into a complete Product Requirements Document (PRD).\nAnalyzes routes, components, state management, API integrations, and user interactions to produce\nbusiness-readable documentation detailed enough for engineers or AI agents to fully reconstruct\nevery page and endpoint. Works with frontend frameworks (React, Vue, Angular, Svelte, Next.js, Nuxt),\nbackend frameworks (NestJS, Django, Express, FastAPI), and fullstack applications.\n\nTrigger when users mention: generate PRD, reverse-engineer requirements, code to documentation,\nextract product specs from code, document page logic, analyze page fields and interactions,\ncreate a functional inventory, write requirements from an existing codebase, document API endpoints,\nor analyze backend routes.","afaizalam2003\u002FMaster-claude-skill","afaizalam2003","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F222019359?v=4","01M6K8F2XNT0HKBPF00JQ78SV3","Faiz Alam","01M6K8F31EBXAPER0EG8R9HTR5",3,"MIT","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002FSKILL.md",[18,23,26,31],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000031","产品经理",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"to prd","code","prd","code to prd","Existing","frontend","for","functional","express","frameworks","document","engineer","write","analyze","applications","vue","generate","create","react","components","2026-11-10 10:12:30",false,"---\nName: code-to-prd\nTier: STANDARD\nCategory: product\nDependencies: none\nAuthor: Md Faiz Alam\nVersion: 2.1.2\nname: code-to-prd\ndescription: |\n  Reverse-engineer any codebase into a complete Product Requirements Document (PRD).\n  Analyzes routes, components, state management, API integrations, and user interactions to produce\n  business-readable documentation detailed enough for engineers or AI agents to fully reconstruct\n  every page and endpoint. Works with frontend frameworks (React, Vue, Angular, Svelte, Next.js, Nuxt),\n  backend frameworks (NestJS, Django, Express, FastAPI), and fullstack applications.\n\n  Trigger when users mention: generate PRD, reverse-engineer requirements, code to documentation,\n  extract product specs from code, document page logic, analyze page fields and interactions,\n  create a functional inventory, write requirements from an existing codebase, document API endpoints,\n  or analyze backend routes.\nlicense: MIT\nmetadata:\n  updated: 2026-03-17\n---\n\n## Name\n\nCode → PRD\n\n## Description\n\nReverse-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.\n\n# Code → PRD: Reverse-Engineer Any Codebase into Product Requirements\n\n## Features\n\n- **3-phase workflow**: global scan → page-by-page analysis → structured document generation\n- **Frontend support**: React, Vue, Angular, Svelte, Next.js (App + Pages Router), Nuxt, SvelteKit, Remix\n- **Backend support**: NestJS, Express, Django, Django REST Framework, FastAPI, Flask\n- **Fullstack support**: Combined frontend + backend analysis with unified PRD output\n- **Mock detection**: Automatically distinguishes real API integrations from mock\u002Ffixture data\n- **Enum extraction**: Exhaustively lists all status codes, type mappings, and constants\n- **Model extraction**: Parses Django models, NestJS entities, Pydantic schemas\n- **Automation scripts**: `codebase_analyzer.py` for scanning, `prd_scaffolder.py` for directory generation\n- **Quality checklist**: Validation checklist for completeness, accuracy, readability\n\n## Usage\n\n```bash\n# Analyze a project and generate PRD skeleton\npython3 scripts\u002Fcodebase_analyzer.py \u002Fpath\u002Fto\u002Fproject -o analysis.json\npython3 scripts\u002Fprd_scaffolder.py analysis.json -o prd\u002F -n \"My App\"\n\n# Or use the slash command\n\u002Fcode-to-prd \u002Fpath\u002Fto\u002Fproject\n```\n\n## Examples\n\n### Frontend (React)\n```bash\n\u002Fcode-to-prd .\u002Fsrc\n# → Scans components, routes, API calls, state management\n# → Generates prd\u002F with per-page docs, enum dictionary, API inventory\n```\n\n### Backend (Django)\n```bash\n\u002Fcode-to-prd .\u002Fmyproject\n# → Detects Django via manage.py, scans urls.py, views.py, models.py\n# → Documents endpoints, model schemas, admin config, permissions\n```\n\n### Fullstack (Next.js)\n```bash\n\u002Fcode-to-prd .\n# → Analyzes both app\u002F pages and api\u002F routes\n# → Generates unified PRD covering UI pages and API endpoints\n```\n\n---\n\n## Role\n\nYou 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**.\n\n### Dual Audience\n\n1. **Product managers \u002F business stakeholders** — need to understand *what* the system does, not *how*\n2. **Engineers \u002F AI agents** — need enough detail to **fully reconstruct** every page's fields, interactions, and relationships\n\nYour document must describe functionality in non-technical language while omitting zero business details.\n\n### Supported Stacks\n\n| Stack | Frameworks |\n|-------|-----------|\n| **Frontend** | React, Vue, Angular, Svelte, Next.js (App\u002FPages Router), Nuxt, SvelteKit, Remix, Astro |\n| **Backend** | NestJS, Express, Fastify, Django, Django REST Framework, FastAPI, Flask |\n| **Fullstack** | Next.js (API routes + pages), Nuxt (server\u002F + pages\u002F), Django (views + templates) |\n\nFor **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\u002Fviews, and interactions become request\u002Fresponse flows.\n\n---\n\n## Workflow\n\n### Phase 1 — Project Global Scan\n\nBuild global context before diving into pages.\n\n#### 1. Identify Project Structure\n\nScan the root directory and understand organization:\n\n```\nFrontend directories:\n- Pages\u002Froutes (pages\u002F, views\u002F, routes\u002F, app\u002F, src\u002Fpages\u002F)\n- Components (components\u002F, modules\u002F)\n- Route config (router.ts, routes.ts, App.tsx route definitions)\n- API\u002Fservice layer (services\u002F, api\u002F, requests\u002F)\n- State management (store\u002F, models\u002F, context\u002F)\n- i18n files (locales\u002F, i18n\u002F) — field display names often live here\n\nBackend directories (NestJS):\n- Modules (src\u002Fmodules\u002F, src\u002F*.module.ts)\n- Controllers (*.controller.ts) — route handlers\n- Services (*.service.ts) — business logic\n- DTOs (dto\u002F, *.dto.ts) — request\u002Fresponse shapes\n- Entities (entities\u002F, *.entity.ts) — database models\n- Guards\u002Fpipes\u002Finterceptors — auth, validation, transformation\n\nBackend directories (Django):\n- Apps (*\u002Fapps.py, *\u002Fviews.py, *\u002Fmodels.py, *\u002Furls.py)\n- URL config (urls.py, *\u002Furls.py)\n- Views (views.py, viewsets.py) — route handlers\n- Models (models.py) — database schema\n- Serializers (serializers.py) — request\u002Fresponse shapes\n- Forms (forms.py) — validation and field definitions\n- Templates (templates\u002F) — server-rendered pages\n- Admin (admin.py) — admin panel configuration\n```\n\n**Identify framework** from `package.json` (Node.js frameworks) or project files (`manage.py` for Django, `requirements.txt`\u002F`pyproject.toml` for Python). Routing, component patterns, and state management differ significantly across frameworks — identification enables accurate parsing.\n\n#### 2. Build Route & Page Inventory\n\nExtract all pages from route config into a complete **page inventory**:\n\n| Field | Description |\n|-------|-------------|\n| Route path | e.g. `\u002Fuser\u002Flist`, `\u002Forder\u002F:id` |\n| Page title | From route config, breadcrumbs, or page component |\n| Module \u002F menu level | Where it sits in navigation |\n| Component file path | Source file(s) implementing this page |\n\nFor file-system routing (Next.js, Nuxt), infer from directory structure.\n\n**For backend projects**, the page inventory becomes an **endpoint\u002Fresource inventory**:\n\n| Field | Description |\n|-------|-------------|\n| Endpoint path | e.g. `\u002Fapi\u002Fusers`, `\u002Fapi\u002Forders\u002F:id` |\n| HTTP method | GET, POST, PUT, DELETE, PATCH |\n| Controller\u002Fview | Source file handling this route |\n| Module\u002Fapp | Which NestJS module or Django app owns it |\n| Auth required | Whether authentication\u002Fpermissions are needed |\n\nFor NestJS: extract from `@Controller` + `@Get\u002F@Post\u002F@Put\u002F@Delete` decorators.\nFor Django: extract from `urls.py` → `urlpatterns` and `viewsets.py` → router registrations.\n\n#### 3. Map Global Context\n\nBefore analyzing individual pages, capture:\n\n- **Global state** — user info, permissions, feature flags, config\n- **Shared components** — layout, nav, auth guards, error boundaries\n- **Enums & constants** — status codes, type mappings, role definitions\n- **API base config** — base URL, interceptors, auth headers, error handling\n- **Database models** (backend) — entity relationships, field types, constraints\n- **Middleware** (backend) — auth middleware, rate limiting, logging, CORS\n- **DTOs\u002FSerializers** (backend) — request validation shapes, response formats\n\nThese will be referenced throughout page\u002Fendpoint analysis.\n\n---\n\n### Phase 2 — Page-by-Page Deep Analysis\n\nAnalyze every page in the inventory. **Each page produces its own Markdown file.**\n\n#### Analysis Dimensions\n\nFor each page, answer:\n\n##### A. Page Overview\n- What does this page do? (one sentence)\n- Where does it fit in the system?\n- What scenario brings a user here?\n\n##### B. Layout & Regions\n- Major regions: search area, table, detail panel, action bar, tabs, etc.\n- Spatial arrangement: top\u002Fbottom, left\u002Fright, nested\n\n##### C. Field Inventory (core — be exhaustive)\n\n**For form pages**, list every field:\n\n| Field Name | Type | Required | Default | Validation | Business Description |\n|-----------|------|----------|---------|------------|---------------------|\n| Username | Text input | Yes | — | Max 20 chars | System login account |\n\n**For table\u002Flist pages**, list:\n- Search\u002Ffilter fields (type, required, enum options)\n- Table columns (name, format, sortable, filterable)\n- Row action buttons (what each one does)\n\n**Field name extraction priority:**\n1. Hardcoded display text in code\n2. i18n translation values\n3. Component `placeholder` \u002F `label` \u002F `title` props\n4. Variable names (last resort — provide reasonable display name)\n\n##### D. Interaction Logic\n\nDescribe as **\"user action → system response\"**:\n\n```\n[Action]     User clicks \"Create\"\n[Response]   Modal opens with form fields: ...\n[Validation] Name required, phone format check\n[API]        POST \u002Fapi\u002Fuser\u002Fcreate with form data\n[Success]    Toast \"Created successfully\", close modal, refresh list\n[Failure]    Show API error message\n```\n\n**Cover all interaction types:**\n- Page load \u002F initialization (default queries, preloaded data)\n- Search \u002F filter \u002F reset\n- CRUD operations (create, read, update, delete)\n- Table: pagination, sorting, row selection, bulk actions\n- Form submission & validation\n- Status transitions (e.g. approval flows: pending → approved → rejected)\n- Import \u002F export\n- Field interdependencies (selecting value A changes options in field B)\n- Permission controls (buttons\u002Ffields visible only to certain roles)\n- Polling \u002F auto-refresh \u002F real-time updates\n\n##### E. API Dependencies\n\n**Case 1: API is integrated** (real HTTP calls in code)\n\n| API Name | Method | Path | Trigger | Key Params | Notes |\n|----------|--------|------|---------|-----------|-------|\n| Get users | GET | \u002Fapi\u002Fuser\u002Flist | Load, search | page, size, keyword | Paginated |\n\n**Case 2: API not integrated** (mock\u002Fhardcoded data)\n\nWhen 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.\n\nFor each needed API, document:\n- Method, suggested path, trigger\n- Input params (name, type, required, description)\n- Output fields (name, type, description)\n- Core business logic description\n\n**Detection signals:**\n- `setTimeout` \u002F `Promise.resolve()` returning data → mock\n- Data defined in component or `*.mock.*` files → mock\n- Real HTTP calls (`axios`, `fetch`, service layer) with real paths → integrated\n- `__mocks__` directory → mock\n\n##### F. Page Relationships\n\n- **Inbound**: Which pages link here? What parameters do they pass?\n- **Outbound**: Where can users navigate from here? What parameters?\n- **Data coupling**: Which pages share data or trigger refreshes in each other?\n\n---\n\n### Phase 3 — Generate Documentation\n\n#### Output Structure\n\nCreate `prd\u002F` in project root (or user-specified directory):\n\n```\nprd\u002F\n├── README.md                     # System overview\n├── pages\u002F\n│   ├── 01-user-mgmt-list.md      # One file per page\n│   ├── 02-user-mgmt-detail.md\n│   ├── 03-order-mgmt-list.md\n│   └── ...\n└── appendix\u002F\n    ├── enum-dictionary.md         # All enums, status codes, type mappings\n    ├── page-relationships.md      # Navigation map between pages\n    └── api-inventory.md           # Complete API reference\n```\n\n#### README.md Template\n\n```markdown\n# [System Name] — Product Requirements Document\n\n## System Overview\n[2-3 paragraphs: what the system does, business context, primary users]\n\n## Module Overview\n\n| Module | Pages | Core Functionality |\n|--------|-------|--------------------|\n| User Management | User list, User detail, Role mgmt | CRUD users, assign roles and permissions |\n\n## Page Inventory\n\n| # | Page Name | Route | Module | Doc Link |\n|---|-----------|-------|--------|----------|\n| 1 | User List | \u002Fuser\u002Flist | User Mgmt | [→](.\u002Fpages\u002F01-user-mgmt-list.md) |\n\n## Global Notes\n\n### Permission Model\n[Summarize auth\u002Frole system if present in code]\n\n### Common Interaction Patterns\n[Global rules: all deletes require confirmation, lists default to created_at desc, etc.]\n```\n\n#### Per-Page Document Template\n\n```markdown\n# [Page Name]\n\n> **Route:** `\u002Fxxx\u002Fxxx`\n> **Module:** [Module name]\n> **Generated:** [Date]\n\n## Overview\n[2-3 sentences: core function and use case]\n\n## Layout\n[Region breakdown — text description or ASCII diagram]\n\n## Fields\n\n### [Region: e.g. \"Search Filters\"]\n| Field | Type | Required | Options \u002F Enum | Default | Notes |\n|-------|------|----------|---------------|---------|-------|\n\n### [Region: e.g. \"Data Table\"]\n| Column | Format | Sortable | Filterable | Notes |\n|--------|--------|----------|-----------|-------|\n\n### [Region: e.g. \"Actions\"]\n| Button | Visibility Condition | Behavior |\n|--------|---------------------|----------|\n\n## Interactions\n\n### Page Load\n[What happens on mount]\n\n### [Scenario: e.g. \"Search\"]\n- **Trigger:** [User action]\n- **Behavior:** [System response]\n- **Special rules:** [If any]\n\n### [Scenario: e.g. \"Create\"]\n- **Trigger:** ...\n- **Modal\u002Fdrawer content:** [Fields and logic inside]\n- **Validation:** ...\n- **On success:** ...\n\n## API Dependencies\n\n| API | Method | Path | Trigger | Notes |\n|-----|--------|------|---------|-------|\n| ... | ... | ... | ... | ... |\n\n## Page Relationships\n- **From:** [Source pages + params]\n- **To:** [Target pages + params]\n- **Data coupling:** [Cross-page refresh triggers]\n\n## Business Rules\n[Anything that doesn't fit above]\n```\n\n---\n\n## Key Principles\n\n### 1. Business Language First\nDon't write \"calls `useState` to manage loading state.\" Write \"search button shows a spinner to prevent duplicate submissions.\"\n\nDon't write \"useEffect fetches on mount.\" Write \"page automatically loads the first page of results on open.\"\n\nInclude technical details only when they **directly affect product behavior**: API paths (engineers need them), validation rules (affect UX), permission conditions (affect visibility).\n\n### 2. Don't Miss Hidden Logic\nCode contains logic PMs may not realize exists:\n- Field interdependencies (type A shows field X; type B shows field Y)\n- Conditional button visibility\n- Data formatting (currency with 2 decimals, date formats, status label mappings)\n- Default sort order and page size\n- Debounce\u002Fthrottle effects on user input\n- Polling \u002F auto-refresh intervals\n\n### 3. Exhaustively List Enums\nWhen 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.\n\n### 4. Mark Uncertainty — Don't Guess\nIf 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.\n\n### 5. Keep Page Files Self-Contained\nEach page's Markdown should be **standalone** — reading just that file gives complete understanding. Use relative links when referencing other pages or appendix entries.\n\n---\n\n## Page Type Strategies\n\n### Frontend Pages\n\n| Page Type | Focus Areas |\n|-----------|------------|\n| **List \u002F Table** | Search conditions, columns, row actions, pagination, bulk ops |\n| **Form \u002F Create-Edit** | Every field, validation, interdependencies, post-submit behavior |\n| **Detail \u002F View** | Displayed info, tab\u002Fsection organization, available actions |\n| **Modal \u002F Drawer** | Describe as part of triggering page — not a separate file. But fully document content |\n| **Dashboard** | Data cards, charts, metrics meaning, filter dimensions, refresh frequency |\n\n### Backend Endpoints (NestJS \u002F Django \u002F Express)\n\n| Endpoint Type | Focus Areas |\n|---------------|------------|\n| **CRUD resource** | All fields (from DTO\u002Fserializer), validation rules, permissions, pagination, filtering, sorting |\n| **Auth endpoints** | Login\u002Fregister flow, token format, refresh logic, password reset, OAuth providers |\n| **File upload** | Accepted types, size limits, storage destination, processing pipeline |\n| **Webhook \u002F event** | Trigger conditions, payload shape, retry policy, idempotency |\n| **Background job** | Trigger, schedule, input\u002Foutput, failure handling, monitoring |\n| **Admin views** (Django) | Registered models, list_display, search_fields, filters, inline models, custom actions |\n\n---\n\n## Execution Pacing\n\n**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.\n\n**Small projects (≤15 pages):** Complete all analysis in one pass.\n\n---\n\n## Common Pitfalls\n\n| Pitfall | Fix |\n|---------|-----|\n| Using component names as page names | `UserManagementTable` → \"User Management List\" |\n| Skipping modals and drawers | They contain critical business logic — document fully |\n| Missing i18n field names | Check translation files, not just component JSX |\n| Ignoring dynamic route params | `\u002Forder\u002F:id` = page requires an order ID to load |\n| Forgetting permission controls | Document which roles see which buttons\u002Fpages |\n| Assuming all APIs are real | Check for mock data patterns before documenting endpoints |\n| Skipping Django admin customization | `admin.py` often contains critical business rules (list filters, custom actions, inlines) |\n| Missing NestJS guards\u002Fpipes | `@UseGuards`, `@UsePipes` contain auth and validation logic that affects behavior |\n| Ignoring database constraints | Model field constraints (unique, max_length, choices) are validation rules for the PRD |\n| Overlooking middleware | Auth middleware, rate limiters, and CORS config define system-wide behavior |\n\n---\n\n## Tooling\n\n### Scripts\n\n| Script | Purpose | Usage |\n|--------|---------|-------|\n| `scripts\u002Fcodebase_analyzer.py` | Scan codebase → extract routes, APIs, models, enums, structure | `python3 codebase_analyzer.py \u002Fpath\u002Fto\u002Fproject` |\n| `scripts\u002Fprd_scaffolder.py` | Generate PRD directory skeleton from analysis JSON | `python3 prd_scaffolder.py analysis.json` |\n\n**Recommended workflow:**\n```bash\n# 1. Analyze the project (JSON output — works for frontend, backend, or fullstack)\npython3 scripts\u002Fcodebase_analyzer.py \u002Fpath\u002Fto\u002Fproject -o analysis.json\n\n# 2. Review the analysis (markdown summary)\npython3 scripts\u002Fcodebase_analyzer.py \u002Fpath\u002Fto\u002Fproject -f markdown\n\n# 3. Scaffold the PRD directory with stubs\npython3 scripts\u002Fprd_scaffolder.py analysis.json -o prd\u002F -n \"My App\"\n\n# 4. Fill in TODO sections page-by-page using the SKILL.md workflow\n```\n\nBoth scripts are **stdlib-only** — no pip install needed.\n\n### References\n\n| File | Contents |\n|------|----------|\n| `references\u002Fprd-quality-checklist.md` | Validation checklist for completeness, accuracy, readability |\n| `references\u002Fframework-patterns.md` | Framework-specific patterns for routes, state, APIs, forms, permissions |\n\n---\n\n## Attribution\n\nThis skill was inspired by [code-to-prd](https:\u002F\u002Fgithub.com\u002Flihanglogan\u002Fcode-to-prd) by [@lihanglogan](https:\u002F\u002Fgithub.com\u002Flihanglogan), who proposed the original concept and methodology in [PR #368](https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fpull\u002F368). 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).\n","## Name\n\nCode → PRD\n\n## Description\n\nReverse-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.\n\n# Code → PRD: Reverse-Engineer Any Codebase into Product Requirements\n\n## Features\n\n- **3-phase workflow**: global scan → page-by-page analysis → structured document generation\n- **Frontend support**: React, Vue, Angular, Svelte, Next.js (App + Pages Router), Nuxt, SvelteKit, Remix\n- **Backend support**: NestJS, Express, Django, Django REST Framework, FastAPI, Flask\n- **Fullstack support**: Combined frontend + backend analysis with unified PRD output\n- **Mock detection**: Automatically distinguishes real API integrations from mock\u002Ffixture data\n- **Enum extraction**: Exhaustively lists all status codes, type mappings, and constants\n- **Model extraction**: Parses Django models, NestJS entities, Pydantic schemas\n- **Automation scripts**: `codebase_analyzer.py` for scanning, `prd_scaffolder.py` for directory generation\n- **Quality checklist**: Validation checklist for completeness, accuracy, readability\n\n## Usage\n\n```bash\n# Analyze a project and generate PRD skeleton\npython3 scripts\u002Fcodebase_analyzer.py \u002Fpath\u002Fto\u002Fproject -o analysis.json\npython3 scripts\u002Fprd_scaffolder.py analysis.json -o prd\u002F -n \"My App\"\n\n# Or use the slash command\n\u002Fcode-to-prd \u002Fpath\u002Fto\u002Fproject\n```\n\n## Examples\n\n### Frontend (React)\n```bash\n\u002Fcode-to-prd .\u002Fsrc\n# → Scans components, routes, API calls, state management\n# → Generates prd\u002F with per-page docs, enum dictionary, API inventory\n```\n\n### Backend (Django)\n```bash\n\u002Fcode-to-prd .\u002Fmyproject\n# → Detects Django via manage.py, scans urls.py, views.py, models.py\n# → Documents endpoints, model schemas, admin config, permissions\n```\n\n### Fullstack (Next.js)\n```bash\n\u002Fcode-to-prd .\n# → Analyzes both app\u002F pages and api\u002F routes\n# → Generates unified PRD covering UI pages and API endpoints\n```\n\n---\n\n## Role\n\nYou 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**.\n\n### Dual Audience\n\n1. **Product managers \u002F business stakeholders** — need to understand *what* the system does, not *how*\n2. **Engineers \u002F AI agents** — need enough detail to **fully reconstruct** every page's fields, interactions, and relationships\n\nYour document must describe functionality in non-technical language while omitting zero business details.\n\n### Supported Stacks\n\n| Stack | Frameworks |\n|-------|-----------|\n| **Frontend** | React, Vue, Angular, Svelte, Next.js (App\u002FPages Router), Nuxt, SvelteKit, Remix, Astro |\n| **Backend** | NestJS, Express, Fastify, Django, Django REST Framework, FastAPI, Flask |\n| **Fullstack** | Next.js (API routes + pages), Nuxt (server\u002F + pages\u002F), Django (views + templates) |\n\nFor **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\u002Fviews, and interactions become request\u002Fresponse flows.\n\n---\n\n## Workflow\n\n### Phase 1 — Project Global Scan\n\nBuild global context before diving into pages.\n\n#### 1. Identify Project Structure\n\nScan the root directory and understand organization:\n\n```\nFrontend directories:\n- Pages\u002Froutes (pages\u002F, views\u002F, routes\u002F, app\u002F, src\u002Fpages\u002F)\n- Components (components\u002F, modules\u002F)\n- Route config (router.ts, routes.ts, App.tsx route definitions)\n- API\u002Fservice layer (services\u002F, api\u002F, requests\u002F)\n- State management (store\u002F, models\u002F, context\u002F)\n- i18n files (locales\u002F, i18n\u002F) — field display names often live here\n\nBackend directories (NestJS):\n- Modules (src\u002Fmodules\u002F, src\u002F*.module.ts)\n- Controllers (*.controller.ts) — route handlers\n- Services (*.service.ts) — business logic\n- DTOs (dto\u002F, *.dto.ts) — request\u002Fresponse shapes\n- Entities (entities\u002F, *.entity.ts) — database models\n- Guards\u002Fpipes\u002Finterceptors — auth, validation, transformation\n\nBackend directories (Django):\n- Apps (*\u002Fapps.py, *\u002Fviews.py, *\u002Fmodels.py, *\u002Furls.py)\n- URL config (urls.py, *\u002Furls.py)\n- Views (views.py, viewsets.py) — route handlers\n- Models (models.py) — database schema\n- Serializers (serializers.py) — request\u002Fresponse shapes\n- Forms (forms.py) — validation and field definitions\n- Templates (templates\u002F) — server-rendered pages\n- Admin (admin.py) — admin panel configuration\n```\n\n**Identify framework** from `package.json` (Node.js frameworks) or project files (`manage.py` for Django, `requirements.txt`\u002F`pyproject.toml` for Python). Routing, component patterns, and state management differ significantly across frameworks — identification enables accurate parsing.\n\n#### 2. Build Route & Page Inventory\n\nExtract all pages from route config into a complete **page inventory**:\n\n| Field | Description |\n|-------|-------------|\n| Route path | e.g. `\u002Fuser\u002Flist`, `\u002Forder\u002F:id` |\n| Page title | From route config, breadcrumbs, or page component |\n| Module \u002F menu level | Where it sits in navigation |\n| Component file path | Source file(s) implementing this page |\n\nFor file-system routing (Next.js, Nuxt), infer from directory structure.\n\n**For backend projects**, the page inventory becomes an **endpoint\u002Fresource inventory**:\n\n| Field | Description |\n|-------|-------------|\n| Endpoint path | e.g. `\u002Fapi\u002Fusers`, `\u002Fapi\u002Forders\u002F:id` |\n| HTTP method | GET, POST, PUT, DELETE, PATCH |\n| Controller\u002Fview | Source file handling this route |\n| Module\u002Fapp | Which NestJS module or Django app owns it |\n| Auth required | Whether authentication\u002Fpermissions are needed |\n\nFor NestJS: extract from `@Controller` + `@Get\u002F@Post\u002F@Put\u002F@Delete` decorators.\nFor Django: extract from `urls.py` → `urlpatterns` and `viewsets.py` → router registrations.\n\n#### 3. Map Global Context\n\nBefore analyzing individual pages, capture:\n\n- **Global state** — user info, permissions, feature flags, config\n- **Shared components** — layout, nav, auth guards, error boundaries\n- **Enums & constants** — status codes, type mappings, role definitions\n- **API base config** — base URL, interceptors, auth headers, error handling\n- **Database models** (backend) — entity relationships, field types, constraints\n- **Middleware** (backend) — auth middleware, rate limiting, logging, CORS\n- **DTOs\u002FSerializers** (backend) — request validation shapes, response formats\n\nThese will be referenced throughout page\u002Fendpoint analysis.\n\n---\n\n### Phase 2 — Page-by-Page Deep Analysis\n\nAnalyze every page in the inventory. **Each page produces its own Markdown file.**\n\n#### Analysis Dimensions\n\nFor each page, answer:\n\n##### A. Page Overview\n- What does this page do? (one sentence)\n- Where does it fit in the system?\n- What scenario brings a user here?\n\n##### B. Layout & Regions\n- Major regions: search area, table, detail panel, action bar, tabs, etc.\n- Spatial arrangement: top\u002Fbottom, left\u002Fright, nested\n\n##### C. Field Inventory (core — be exhaustive)\n\n**For form pages**, list every field:\n\n| Field Name | Type | Required | Default | Validation | Business Description |\n|-----------|------|----------|---------|------------|---------------------|\n| Username | Text input | Yes | — | Max 20 chars | System login account |\n\n**For table\u002Flist pages**, list:\n- Search\u002Ffilter fields (type, required, enum options)\n- Table columns (name, format, sortable, filterable)\n- Row action buttons (what each one does)\n\n**Field name extraction priority:**\n1. Hardcoded display text in code\n2. i18n translation values\n3. Component `placeholder` \u002F `label` \u002F `title` props\n4. Variable names (last resort — provide reasonable display name)\n\n##### D. Interaction Logic\n\nDescribe as **\"user action → system response\"**:\n\n```\n[Action]     User clicks \"Create\"\n[Response]   Modal opens with form fields: ...\n[Validation] Name required, phone format check\n[API]        POST \u002Fapi\u002Fuser\u002Fcreate with form data\n[Success]    Toast \"Created successfully\", close modal, refresh list\n[Failure]    Show API error message\n```\n\n**Cover all interaction types:**\n- Page load \u002F initialization (default queries, preloaded data)\n- Search \u002F filter \u002F reset\n- CRUD operations (create, read, update, delete)\n- Table: pagination, sorting, row selection, bulk actions\n- Form submission & validation\n- Status transitions (e.g. approval flows: pending → approved → rejected)\n- Import \u002F export\n- Field interdependencies (selecting value A changes options in field B)\n- Permission controls (buttons\u002Ffields visible only to certain roles)\n- Polling \u002F auto-refresh \u002F real-time updates\n\n##### E. API Dependencies\n\n**Case 1: API is integrated** (real HTTP calls in code)\n\n| API Name | Method | Path | Trigger | Key Params | Notes |\n|----------|--------|------|---------|-----------|-------|\n| Get users | GET | \u002Fapi\u002Fuser\u002Flist | Load, search | page, size, keyword | Paginated |\n\n**Case 2: API not integrated** (mock\u002Fhardcoded data)\n\nWhen 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.\n\nFor each needed API, document:\n- Method, suggested path, trigger\n- Input params (name, type, required, description)\n- Output fields (name, type, description)\n- Core business logic description\n\n**Detection signals:**\n- `setTimeout` \u002F `Promise.resolve()` returning data → mock\n- Data defined in component or `*.mock.*` files → mock\n- Real HTTP calls (`axios`, `fetch`, service layer) with real paths → integrated\n- `__mocks__` directory → mock\n\n##### F. Page Relationships\n\n- **Inbound**: Which pages link here? What parameters do they pass?\n- **Outbound**: Where can users navigate from here? What parameters?\n- **Data coupling**: Which pages share data or trigger refreshes in each other?\n\n---\n\n### Phase 3 — Generate Documentation\n\n#### Output Structure\n\nCreate `prd\u002F` in project root (or user-specified directory):\n\n```\nprd\u002F\n├── README.md                     # System overview\n├── pages\u002F\n│   ├── 01-user-mgmt-list.md      # One file per page\n│   ├── 02-user-mgmt-detail.md\n│   ├── 03-order-mgmt-list.md\n│   └── ...\n└── appendix\u002F\n    ├── enum-dictionary.md         # All enums, status codes, type mappings\n    ├── page-relationships.md      # Navigation map between pages\n    └── api-inventory.md           # Complete API reference\n```\n\n#### README.md Template\n\n```markdown\n# [System Name] — Product Requirements Document\n\n## System Overview\n[2-3 paragraphs: what the system does, business context, primary users]\n\n## Module Overview\n\n| Module | Pages | Core Functionality |\n|--------|-------|--------------------|\n| User Management | User list, User detail, Role mgmt | CRUD users, assign roles and permissions |\n\n## Page Inventory\n\n| # | Page Name | Route | Module | Doc Link |\n|---|-----------|-------|--------|----------|\n| 1 | User List | \u002Fuser\u002Flist | User Mgmt | [→](.\u002Fpages\u002F01-user-mgmt-list.md) |\n\n## Global Notes\n\n### Permission Model\n[Summarize auth\u002Frole system if present in code]\n\n### Common Interaction Patterns\n[Global rules: all deletes require confirmation, lists default to created_at desc, etc.]\n```\n\n#### Per-Page Document Template\n\n```markdown\n# [Page Name]\n\n> **Route:** `\u002Fxxx\u002Fxxx`\n> **Module:** [Module name]\n> **Generated:** [Date]\n\n## Overview\n[2-3 sentences: core function and use case]\n\n## Layout\n[Region breakdown — text description or ASCII diagram]\n\n## Fields\n\n### [Region: e.g. \"Search Filters\"]\n| Field | Type | Required | Options \u002F Enum | Default | Notes |\n|-------|------|----------|---------------|---------|-------|\n\n### [Region: e.g. \"Data Table\"]\n| Column | Format | Sortable | Filterable | Notes |\n|--------|--------|----------|-----------|-------|\n\n### [Region: e.g. \"Actions\"]\n| Button | Visibility Condition | Behavior |\n|--------|---------------------|----------|\n\n## Interactions\n\n### Page Load\n[What happens on mount]\n\n### [Scenario: e.g. \"Search\"]\n- **Trigger:** [User action]\n- **Behavior:** [System response]\n- **Special rules:** [If any]\n\n### [Scenario: e.g. \"Create\"]\n- **Trigger:** ...\n- **Modal\u002Fdrawer content:** [Fields and logic inside]\n- **Validation:** ...\n- **On success:** ...\n\n## API Dependencies\n\n| API | Method | Path | Trigger | Notes |\n|-----|--------|------|---------|-------|\n| ... | ... | ... | ... | ... |\n\n## Page Relationships\n- **From:** [Source pages + params]\n- **To:** [Target pages + params]\n- **Data coupling:** [Cross-page refresh triggers]\n\n## Business Rules\n[Anything that doesn't fit above]\n```\n\n---\n\n## Key Principles\n\n### 1. Business Language First\nDon't write \"calls `useState` to manage loading state.\" Write \"search button shows a spinner to prevent duplicate submissions.\"\n\nDon't write \"useEffect fetches on mount.\" Write \"page automatically loads the first page of results on open.\"\n\nInclude technical details only when they **directly affect product behavior**: API paths (engineers need them), validation rules (affect UX), permission conditions (affect visibility).\n\n### 2. Don't Miss Hidden Logic\nCode contains logic PMs may not realize exists:\n- Field interdependencies (type A shows field X; type B shows field Y)\n- Conditional button visibility\n- Data formatting (currency with 2 decimals, date formats, status label mappings)\n- Default sort order and page size\n- Debounce\u002Fthrottle effects on user input\n- Polling \u002F auto-refresh intervals\n\n### 3. Exhaustively List Enums\nWhen 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.\n\n### 4. Mark Uncertainty — Don't Guess\nIf 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.\n\n### 5. Keep Page Files Self-Contained\nEach page's Markdown should be **standalone** — reading just that file gives complete understanding. Use relative links when referencing other pages or appendix entries.\n\n---\n\n## Page Type Strategies\n\n### Frontend Pages\n\n| Page Type | Focus Areas |\n|-----------|------------|\n| **List \u002F Table** | Search conditions, columns, row actions, pagination, bulk ops |\n| **Form \u002F Create-Edit** | Every field, validation, interdependencies, post-submit behavior |\n| **Detail \u002F View** | Displayed info, tab\u002Fsection organization, available actions |\n| **Modal \u002F Drawer** | Describe as part of triggering page — not a separate file. But fully document content |\n| **Dashboard** | Data cards, charts, metrics meaning, filter dimensions, refresh frequency |\n\n### Backend Endpoints (NestJS \u002F Django \u002F Express)\n\n| Endpoint Type | Focus Areas |\n|---------------|------------|\n| **CRUD resource** | All fields (from DTO\u002Fserializer), validation rules, permissions, pagination, filtering, sorting |\n| **Auth endpoints** | Login\u002Fregister flow, token format, refresh logic, password reset, OAuth providers |\n| **File upload** | Accepted types, size limits, storage destination, processing pipeline |\n| **Webhook \u002F event** | Trigger conditions, payload shape, retry policy, idempotency |\n| **Background job** | Trigger, schedule, input\u002Foutput, failure handling, monitoring |\n| **Admin views** (Django) | Registered models, list_display, search_fields, filters, inline models, custom actions |\n\n---\n\n## Execution Pacing\n\n**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.\n\n**Small projects (≤15 pages):** Complete all analysis in one pass.\n\n---\n\n## Common Pitfalls\n\n| Pitfall | Fix |\n|---------|-----|\n| Using component names as page names | `UserManagementTable` → \"User Management List\" |\n| Skipping modals and drawers | They contain critical business logic — document fully |\n| Missing i18n field names | Check translation files, not just component JSX |\n| Ignoring dynamic route params | `\u002Forder\u002F:id` = page requires an order ID to load |\n| Forgetting permission controls | Document which roles see which buttons\u002Fpages |\n| Assuming all APIs are real | Check for mock data patterns before documenting endpoints |\n| Skipping Django admin customization | `admin.py` often contains critical business rules (list filters, custom actions, inlines) |\n| Missing NestJS guards\u002Fpipes | `@UseGuards`, `@UsePipes` contain auth and validation logic that affects behavior |\n| Ignoring database constraints | Model field constraints (unique, max_length, choices) are validation rules for the PRD |\n| Overlooking middleware | Auth middleware, rate limiters, and CORS config define system-wide behavior |\n\n---\n\n## Tooling\n\n### Scripts\n\n| Script | Purpose | Usage |\n|--------|---------|-------|\n| `scripts\u002Fcodebase_analyzer.py` | Scan codebase → extract routes, APIs, models, enums, structure | `python3 codebase_analyzer.py \u002Fpath\u002Fto\u002Fproject` |\n| `scripts\u002Fprd_scaffolder.py` | Generate PRD directory skeleton from analysis JSON | `python3 prd_scaffolder.py analysis.json` |\n\n**Recommended workflow:**\n```bash\n# 1. Analyze the project (JSON output — works for frontend, backend, or fullstack)\npython3 scripts\u002Fcodebase_analyzer.py \u002Fpath\u002Fto\u002Fproject -o analysis.json\n\n# 2. Review the analysis (markdown summary)\npython3 scripts\u002Fcodebase_analyzer.py \u002Fpath\u002Fto\u002Fproject -f markdown\n\n# 3. Scaffold the PRD directory with stubs\npython3 scripts\u002Fprd_scaffolder.py analysis.json -o prd\u002F -n \"My App\"\n\n# 4. Fill in TODO sections page-by-page using the SKILL.md workflow\n```\n\nBoth scripts are **stdlib-only** — no pip install needed.\n\n### References\n\n| File | Contents |\n|------|----------|\n| `references\u002Fprd-quality-checklist.md` | Validation checklist for completeness, accuracy, readability |\n| `references\u002Fframework-patterns.md` | Framework-specific patterns for routes, state, APIs, forms, permissions |\n\n---\n\n## Attribution\n\nThis skill was inspired by [code-to-prd](https:\u002F\u002Fgithub.com\u002Flihanglogan\u002Fcode-to-prd) by [@lihanglogan](https:\u002F\u002Fgithub.com\u002Flihanglogan), who proposed the original concept and methodology in [PR #368](https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fpull\u002F368). 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).\n",{"Name":5,"Tier":60,"name":5,"Author":61,"Version":62,"license":15,"Category":63,"metadata":64,"description":66,"Dependencies":67},"STANDARD","Md Faiz Alam","2.1.2","product",{"updated":65},1773705600000,"Reverse-engineer any codebase into a complete Product Requirements Document (PRD).\nAnalyzes routes, components, state management, API integrations, and user interactions to produce\nbusiness-readable documentation detailed enough for engineers or AI agents to fully reconstruct\nevery page and endpoint. Works with frontend frameworks (React, Vue, Angular, Svelte, Next.js, Nuxt),\nbackend frameworks (NestJS, Django, Express, FastAPI), and fullstack applications.\n\nTrigger when users mention: generate PRD, reverse-engineer requirements, code to documentation,\nextract product specs from code, document page logic, analyze page fields and interactions,\ncreate a functional inventory, write requirements from an existing codebase, document API endpoints,\nor analyze backend routes.\n","none","main","0b48cbb0e6d5be6ff68c0f6b28bc0c65ee21c4a1","product-team\u002Fcode-to-prd",2,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill","https:\u002F\u002Fgithub.com\u002Fafaizalam2003","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fmdfaizalam2003\u002F","2026-04-01 04:35:43",{"source":8,"skillName":5,"commands":77,"prompt":87,"zipAvailable":88},[78,81,84],{"tool":79,"command":80},"npx","npx skills add afaizalam2003\u002FMaster-claude-skill --skill code-to-prd",{"tool":82,"command":83},"bunx","bunx skills add afaizalam2003\u002FMaster-claude-skill --skill code-to-prd",{"tool":85,"command":86},"pnpm","pnpm dlx skills add afaizalam2003\u002FMaster-claude-skill --skill code-to-prd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002FSKILL.md",true,[90,96,102,106,110,114,118,122,126,132,136,140],{"path":91,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":94,"sourceHtmlUrl":95},".claude-plugin\u002Fplugin.json","REFERENCE","参考文档",631,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002F.claude-plugin\u002Fplugin.json",{"path":97,"resourceType":98,"resourceTypeDesc":99,"sizeBytes":100,"sourceHtmlUrl":101},"assets\u002Fsample-analysis.json","ASSET","资产文件",2926,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002Fassets\u002Fsample-analysis.json",{"path":103,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":104,"sourceHtmlUrl":105},"expected_outputs\u002Fsample-enum-dictionary.md",729,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002Fexpected_outputs\u002Fsample-enum-dictionary.md",{"path":107,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":108,"sourceHtmlUrl":109},"expected_outputs\u002Fsample-page-user-list.md",3041,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002Fexpected_outputs\u002Fsample-page-user-list.md",{"path":111,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":112,"sourceHtmlUrl":113},"expected_outputs\u002Fsample-prd-readme.md",1705,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002Fexpected_outputs\u002Fsample-prd-readme.md",{"path":115,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":116,"sourceHtmlUrl":117},"README.md",1694,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002FREADME.md",{"path":119,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":120,"sourceHtmlUrl":121},"references\u002Fframework-patterns.md",7757,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002Freferences\u002Fframework-patterns.md",{"path":123,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":124,"sourceHtmlUrl":125},"references\u002Fprd-quality-checklist.md",3008,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002Freferences\u002Fprd-quality-checklist.md",{"path":127,"resourceType":128,"resourceTypeDesc":129,"sizeBytes":130,"sourceHtmlUrl":131},"scripts\u002F.gitignore","SCRIPT","脚本",5,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002Fscripts\u002F.gitignore",{"path":133,"resourceType":128,"resourceTypeDesc":129,"sizeBytes":134,"sourceHtmlUrl":135},"scripts\u002Fcodebase_analyzer.py",26199,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002Fscripts\u002Fcodebase_analyzer.py",{"path":137,"resourceType":128,"resourceTypeDesc":129,"sizeBytes":138,"sourceHtmlUrl":139},"scripts\u002Fprd_scaffolder.py",14989,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002Fscripts\u002Fprd_scaffolder.py",{"path":141,"resourceType":92,"resourceTypeDesc":93,"sizeBytes":142,"sourceHtmlUrl":143},"settings.json",766,"https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fproduct-team\u002Fcode-to-prd\u002Fsettings.json",[145,174,198,222,251,271],{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":154,"publishedAt":55},"01M6KC4E8MYR9DBAZTAXHKYMMH","soc2-compliance","Use when the user asks to prepare for SOC 2 audits, map Trust Service Criteria, build control matrices, collect audit evidence, perform gap analysis, or assess SOC 2 Type I vs Type II readiness.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fsoc2-compliance\u002FSKILL.md",[151],{"categoryNo":152,"categoryName":153,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000037","律师与法务",[155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,41],"compliance","soc2","soc2 compliance","audit evidence","audit","collect","soc","analysis","use","evidence","trust","build","map","control","type","gap","readiness","gap analysis","assess",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":55},"01M6KC461R3GKGZ1TAYHVR1MW9","risk-management-specialist","Medical device risk management specialist implementing ISO 14971 throughout product lifecycle. Provides risk analysis, risk evaluation, risk control, and post-production information analysis. Use when user mentions risk management, ISO 14971, risk analysis, FMEA, fault tree analysis, hazard identification, risk control, risk matrix, benefit-risk analysis, residual risk, risk acceptability, or post-market risk.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Frisk-management-specialist\u002FSKILL.md",[],[181,182,183,184,185,63,186,187,162,163,188,189,190,191,192,193,194,195,196,197],"risk","risk management specialist","management","risk management","risk evaluation","Evaluation","lifecycle","risk matrix","iso","medical","iso 14971","identification","information","post-production","tree","matrix","implementing",{"skillNo":199,"name":200,"nameZh":6,"description":201,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":202,"categories":203,"keywords":204,"publishedAt":55},"01M6KC3HF5ZFSSP2NZF68PEPFB","regulatory-affairs-head","Senior Regulatory Affairs Manager for HealthTech and MedTech companies. Prepares FDA 510(k), De Novo, and PMA submission packages; analyzes regulatory pathways for new medical devices; drafts responses to FDA deficiency letters and Notified Body queries; develops CE marking technical documentation under EU MDR 2017\u002F745; coordinates multi-market approval strategies across FDA, EU, Health Canada, PMDA, and NMPA; and maintains regulatory intelligence on evolving standards. Use when users need to plan or execute FDA submissions, navigate 510(k) or PMA approval processes, achieve CE marking, prepare pre-submission meeting materials, write regulatory strategy documents, respond to agency queries, or manage compliance documentation for medical device market access.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fregulatory-affairs-head\u002FSKILL.md",[],[205,206,207,208,209,210,211,47,212,163,213,214,215,216,217,218,219,220,221,41],"regulatory affairs head","regulatory","head","documents","devices","health","plan","strategy","standards","queries","manage","strategies","de","users","respond","medical devices","manager",{"skillNo":223,"name":224,"nameZh":6,"description":225,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":226,"categories":227,"keywords":234,"publishedAt":55},"01M6KC34Z8M1559EY1CXYBJB1A","quality-manager-qms-iso13485","ISO 13485 Quality Management System implementation and maintenance for medical device organizations. Provides QMS design, documentation control, internal auditing, CAPA management, and certification support. Use when working with medical device quality systems, preparing for ISO 13485 audits, managing regulatory compliance documentation, setting up corrective actions, or building audit preparation programs. Useful for quality management, audit preparation, regulatory compliance, medical device documentation, and corrective action workflows.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fquality-manager-qms-iso13485\u002FSKILL.md",[228,231],{"categoryNo":229,"categoryName":230,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":232,"categoryName":233,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师",[235,236,221,237,238,239,240,241,242,163,243,45,244,245,246,247,248,249,41,250],"quality manager qms iso13485","quality","design","workflows","validation","actions","certification","system","maintenance","systems","records","ISO 13485","organizations","corrective action","internal audit","preparation",{"skillNo":252,"name":253,"nameZh":6,"description":254,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":255,"categories":256,"keywords":258,"publishedAt":55},"01M6KC2FXHBHXYX2ZZ17Y3GDB4","quality-manager-qmr","Senior Quality Manager Responsible Person (QMR) for HealthTech and MedTech companies. Provides quality system governance, management review leadership, regulatory compliance oversight, and quality performance monitoring per ISO 13485 Clause 5.5.2.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fquality-manager-qmr\u002FSKILL.md",[257],{"categoryNo":152,"categoryName":153,"taxonomyType":29,"taxonomyTypeDesc":30},[259,236,221,260,261,262,263,264,155,265,242,266,206,267,268,269,189,246,41,270],"quality manager qmr","review","policy","performance","governance","monitoring","regulatory compliance","oversight","cost","culture","leadership","person",{"skillNo":272,"name":273,"nameZh":6,"description":274,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":275,"categories":276,"keywords":284,"publishedAt":55},"01M6KC1VRR5JTDBNZANHPS6VR6","quality-documentation-manager","Document control system management for medical device QMS. Covers document numbering, version control, change management, and 21 CFR Part 11 compliance. Use for document control procedures, change control workflow, document numbering, version management, electronic signature compliance, or regulatory documentation review.","https:\u002F\u002Fgithub.com\u002Fafaizalam2003\u002FMaster-claude-skill\u002Fblob\u002Fmain\u002Fra-qm-team\u002Fquality-documentation-manager\u002FSKILL.md",[277,280,283],{"categoryNo":278,"categoryName":279,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":281,"categoryName":282,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":152,"categoryName":153,"taxonomyType":29,"taxonomyTypeDesc":30},[285,286,236,221,260,287,288,159,242,289,290,291,292,293,190,294,295,296,297,41],"documentation","quality documentation manager","workflow","change","change management","list","master","system management","documentation review","cfr","21 cfr part 11","change control","retention"]