code-to-prd

code-to-prd skill 概览

code-to-prd 能做什么

code-to-prd 是一个 Claude skill，用于把已有的前端、后端或全栈代码库转换成结构化的 Product Requirements Document。它不是简单让 AI “总结这个 repo”，而是引导 agent 检查 routes、components、forms、state、API calls、permissions、enums 和 user interactions，并输出业务侧可读的 PRD 文件，供产品经理、工程师、QA 或 coding agents 使用。

最适合 Requirements Planning 的场景

当一个产品已经有代码实现、但缺少可靠文档时，适合使用 code-to-prd skill 来做 Requirements Planning。它尤其适用于迁移规划、AI 重建说明、遗留系统梳理、交接文档、页面清单、endpoint 清单，以及把实现细节转换成功能需求。它适配 React、Vue、Angular、Svelte、Next.js、Nuxt、Remix、NestJS、Express、Django、FastAPI、Flask 以及类似的 Web 应用技术栈。

它和普通 prompt 有什么不同

该 repository 包含明确的分析流程、框架模式参考、示例输出、PRD 质量检查清单和辅助脚本。真正的差异在于它要求的颗粒度：页面文档应覆盖 fields、validations、table columns、buttons、visibility rules、load behavior、API triggers、mock versus integrated data、enums 和 route relationships。也正因为如此，当目标是重建系统或校验需求时，code-to-prd 比高层级架构摘要更有价值。

什么时候不适合使用

不要把 code-to-prd 当作利益相关方访谈、产品战略或未来状态探索的替代品。它可以从代码中推断当前行为，但无法知道某个功能为什么存在、哪些流程已经过时，或哪些业务规则存在于 repository 之外。它也需要访问 repository；只有截图无法支撑完整工作流。

如何使用 code-to-prd skill

code-to-prd 安装上下文

如果你的 Claude skills 环境支持基于 GitHub 的安装，可以使用：

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

该 skill 位于 product-team/code-to-prd/skills/code-to-prd。安装后，先打开 SKILL.md，再查看 references/framework-patterns.md 和 references/prd-quality-checklist.md。如果想了解输出预期，请检查 expected_outputs/sample-prd-readme.md、expected_outputs/sample-page-user-list.md 和 expected_outputs/sample-enum-dictionary.md。

skill 需要哪些输入

为了让 code-to-prd 产出有用结果，请给 agent 一个真实的 repository path 或选定的 source folders，并说明期望的输出范围。高质量输入包括：

• framework 和 app type，如果已知
• 需要包含或排除的 directories
• 目标读者：product、QA、engineering、AI rebuild、compliance
• 要记录 frontend pages、backend endpoints，还是两者都要
• 输出格式和目标位置，例如 prd/README.md、prd/pages/ 和 prd/appendix/
• 已知的业务词汇、roles、permissions 或 modules
• 不允许修改或猜测的范围

较弱的 prompt 是：“Generate a PRD from this app.” 更好的 prompt 是：“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].”

建议工作流

先做全局扫描，再逐页编写。内置的 scripts/codebase_analyzer.py 可以帮助提取 routes、APIs、framework signals、state directories、models、DTOs 和结构信息，且只使用 Python standard library：

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

把生成的 inventory 当作地图，而不是最终 PRD。接着让 agent 针对每个 route 检查代表性文件：page/component files、layouts、forms、service/API clients、stores、guards、constants、validation schemas 和 backend handlers。最后生成 system overview、page inventory、API inventory、page docs、enum dictionary 和 appendices。

实用 prompt 模式

一个高效的 code-to-prd 引导 prompt 通常包含三部分：

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.”

这样可以减少幻觉，因为 agent 会清楚应该检查什么、避开什么，以及交付物应如何组织。

code-to-prd skill 常见问题

code-to-prd 对新手友好吗？

友好，只要你能把 agent 指向一个 repository，并说明你需要什么输出。新手建议先要求生成 inventory，然后审核后再生成完整 PRD。这样可以避免把时间浪费在错误模块或生成目录上。

它能同时记录前端和后端行为吗？

可以。该 skill 面向 frontend、backend 和 fullstack 项目设计。对于 frontend apps，它关注 pages、fields、UI actions、state 和 API usage。对于 backend services，它关注 routes、controllers、models、DTOs、request/response behavior、permissions 和 integration points。

code-to-prd 比直接问 Claude 好在哪里？

直接 prompt 可能生成一份可读的摘要，但经常会遗漏页面级细节、enum 完整性、mock API 标记、permission conditions 或输出结构。code-to-prd skill 提供可重复的工作流、示例交付物、框架查找指引，以及用于检查 PRD 完整性和准确性的 checklist。

什么时候应该避免使用 code-to-prd？

不要把它用于从零开始的产品构思、路线图优先级排序，或代码中没有体现的需求。也不要在没有先缩小范围的情况下，对一个很大的 monorepo 直接运行完整分析；应先请求 inventory 和 module map，再要求生成完整 PRD。

如何改进 code-to-prd skill

提升 code-to-prd 输出质量

影响质量最大的因素是证据。要求 agent 为关键 routes、fields、validation rules、permissions 和 API calls 引用 source paths。告诉它优先使用 UI labels，而不是内部变量名，并把交互写成“user action → system response”。这样生成的 PRD 对非工程人员更可用，同时不会牺牲实现准确性。

避免常见失败模式

常见失败包括页面过度概括、编造业务规则、漏掉 modals、忽略 empty states，以及把 mock data 当作 production API behavior。应要求 agent 在撰写最终文档前检查 form schemas、constants、guards、API clients、route handlers、loading/error states 和 sample data files，以此降低这些风险。

在第一版 PRD 后继续迭代

不要把第一版输出当作最终结果。先审核 page inventory、API inventory 和 enum dictionary。然后提出有针对性的追问，例如：“Re-check delete permissions,” “Expand validation rules for the user form,” “Separate mock endpoints from integrated endpoints,” 或 “Add inbound and outbound navigation for each page.” 通常，小范围验证比重新生成整份 PRD 更能提升准确性。

按团队习惯定制 skill

如果会反复使用，可以把组织内部的 PRD 规范加入 prompt：module naming、required sections、terminology、severity levels、accessibility notes、analytics events、localization rules 或 QA acceptance criteria。当 code-to-prd skill 的 repository-reading workflow 与团队对“完整需求”的定义结合时，效果最好。