code-to-prd

Overview of code-to-prd skill

What code-to-prd does

code-to-prd is a Claude skill for turning an existing frontend, backend, or fullstack codebase into a structured Product Requirements Document. Instead of asking an AI to “summarize this repo,” it guides the agent to inspect routes, components, forms, state, API calls, permissions, enums, and user interactions, then produce business-readable PRD files that product managers, engineers, QA, or coding agents can use.

Best fit for Requirements Planning

Use the code-to-prd skill when you need Requirements Planning for a product that already exists in code but lacks reliable documentation. It is strongest for migration planning, AI rebuild briefs, legacy system discovery, handoff documentation, page inventories, endpoint inventories, and converting implementation details into functional requirements. It fits React, Vue, Angular, Svelte, Next.js, Nuxt, Remix, NestJS, Express, Django, FastAPI, Flask, and similar web application stacks.

What makes it different from a generic prompt

The repository includes a defined analysis workflow, framework pattern references, sample outputs, a PRD quality checklist, and helper scripts. The important differentiator is the expected granularity: page docs should capture fields, validations, table columns, buttons, visibility rules, load behavior, API triggers, mock versus integrated data, enums, and route relationships. That makes code-to-prd more useful than a high-level architecture summary when the goal is reconstruction or requirements validation.

When it is not the right tool

Do not use code-to-prd as a substitute for stakeholder interviews, product strategy, or future-state discovery. It can infer current behavior from code, but it cannot know why a feature exists, which workflows are obsolete, or which business rules live outside the repository. It also needs repository access; screenshots alone are not enough for the full workflow.

How to Use code-to-prd skill

code-to-prd install context

If your Claude skills environment supports GitHub-based installation, install with:

npx skills add alirezarezvani/claude-skills --skill code-to-prd

The skill lives at product-team/code-to-prd/skills/code-to-prd. After installing, open SKILL.md first, then review references/framework-patterns.md and references/prd-quality-checklist.md. For output expectations, inspect expected_outputs/sample-prd-readme.md, expected_outputs/sample-page-user-list.md, and expected_outputs/sample-enum-dictionary.md.

Inputs the skill needs

For useful code-to-prd usage, give the agent a real repository path or selected source folders, plus the desired output scope. Strong inputs include:

• framework and app type, if known
• directories to include or exclude
• target audience: product, QA, engineering, AI rebuild, compliance
• whether to document frontend pages, backend endpoints, or both
• output format and destination, such as prd/README.md, prd/pages/, and prd/appendix/
• known business vocabulary, roles, permissions, or modules
• areas that must not be changed or guessed

A weak prompt is: “Generate a PRD from this app.” A stronger prompt is: “Use code-to-prd to analyze this Next.js app. Document every route under app/, every API route under app/api/, forms, table columns, role-based visibility, enum values, and mock versus integrated APIs. Write output to prd/ and mark uncertain behavior as [TBC].”

Suggested workflow

Start with a global scan before page-by-page writing. The included scripts/codebase_analyzer.py can help extract routes, APIs, framework signals, state directories, models, DTOs, and structure using Python standard library only:

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

Use the resulting inventory as a map, not as the final PRD. Then ask the agent to inspect representative files for each route: page/component files, layouts, forms, service/API clients, stores, guards, constants, validation schemas, and backend handlers. Finally, generate a system overview, page inventory, API inventory, page docs, enum dictionary, and appendices.

Practical prompt pattern

A productive code-to-prd guide prompt usually has three parts:

1. Scope: “Analyze apps/admin only; ignore node_modules, generated files, tests, and Storybook.”
2. Evidence rules: “Use actual labels and validation from code. Do not invent missing business rules. Mark uncertain items [TBC].”
3. Output contract: “Create prd/README.md, one file per route in prd/pages/, and appendices for APIs, enums, permissions, and open questions.”

This reduces hallucination because the agent knows what to inspect, what to avoid, and how to structure the deliverable.

code-to-prd skill FAQ

Is code-to-prd beginner friendly?

Yes, if you can point the agent at a repository and describe the output you need. Beginners should start by asking for an inventory first, then review it before generating the full PRD. This avoids wasting time on wrong modules or generated directories.

Can it document both frontend and backend behavior?

Yes. The skill is designed for frontend, backend, and fullstack projects. For frontend apps, it focuses on pages, fields, UI actions, state, and API usage. For backend services, it focuses on routes, controllers, models, DTOs, request/response behavior, permissions, and integration points.

How is code-to-prd better than asking Claude directly?

A direct prompt may produce a readable summary, but it often misses page-level details, enum exhaustiveness, mock API flags, permission conditions, or output structure. The code-to-prd skill supplies a repeatable workflow, sample deliverables, framework lookup guidance, and a checklist for PRD completeness and accuracy.

When should I avoid code-to-prd?

Avoid using it for greenfield product ideation, roadmap prioritization, or requirements that are not represented in code. Also avoid running it across a very large monorepo without narrowing scope first; ask for an inventory and module map before requesting full PRD generation.

How to Improve code-to-prd skill

Improve code-to-prd output quality

The biggest quality lever is evidence. Ask the agent to cite source paths for important routes, fields, validation rules, permissions, and API calls. Tell it to prefer UI labels over internal variable names, and to document interactions as “user action → system response.” This produces PRDs that are usable by non-engineers without losing implementation accuracy.

Prevent common failure modes

Common failures include over-summarized pages, invented business rules, missing modals, ignored empty states, and treating mock data as production API behavior. Counter these by requiring the agent to check form schemas, constants, guards, API clients, route handlers, loading/error states, and sample data files before writing final docs.

Iterate after the first PRD draft

Do not treat the first output as final. Review the page inventory, API inventory, and enum dictionary first. Then ask targeted follow-ups such as: “Re-check delete permissions,” “Expand validation rules for the user form,” “Separate mock endpoints from integrated endpoints,” or “Add inbound and outbound navigation for each page.” Small verification passes usually improve accuracy more than regenerating the entire PRD.

Customize the skill for your team

For recurring use, add your organization’s PRD conventions to the prompt: module naming, required sections, terminology, severity levels, accessibility notes, analytics events, localization rules, or QA acceptance criteria. The code-to-prd skill works best when its repository-reading workflow is combined with your team’s definition of a complete requirement.