菜单
Create a Product Requirements Document through user interview, codebase exploration, and module sketching, then file it as local Markdown. Use when user wants a PRD, product requirements, feature spec, or to formalize a feature idea into a shareable document.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/ghalex/skills --skill create-a-prd命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | create-a-prd |
| description | Create a Product Requirements Document through user interview, codebase exploration, and module sketching, then file it as local Markdown. Use when user wants a PRD, product requirements, feature spec, or to formalize a feature idea into a shareable document. |
| license | MIT |
| effort | high |
| allowed-tools | Read Write Edit Bash Glob Grep Skill |
Create a PRD by interviewing the user, exploring the codebase, sketching deep modules, then filing the PRD as a local Markdown file.
You may skip steps when the conversation already covered them — capture, don't re-interview.
Ask the user for a long, detailed description of the problem they want to solve and any potential solutions they've considered. Encourage rambling — you'll structure it later.
Explore the repo to confirm the user's assertions and understand current state. If the user says "we don't have X yet", check. If they say "this currently does Y", trace it.
Interview relentlessly about every aspect of the plan. For every question, provide your recommended answer — lead with "I'd recommend X because Y. Want to go with that, or something different?"
Walk down each branch of the design tree, resolving dependencies between decisions one at a time. Sub-decisions before siblings.
If a question can be answered by the codebase, explore the codebase instead of asking.
Park anything the user can't answer yet in an Open Questions list — don't let unresolved decisions stall the interview or get silently dropped. They go into the PRD's Open Questions section.
If grilling gets long, hand off to /grill-me for a tighter loop.
Sketch the major modules you'll need to build or modify. Actively look for opportunities to extract deep modules that can be tested in isolation.
A deep module = small interface + lots of implementation. The interface rarely changes; the implementation hides complexity. Shallow modules = wide interface + thin implementation, and should be avoided.
Ask the user: do these modules match expectations? Which need tests? What's the test surface — unit, integration, end-to-end?
Before writing the file, present a short outline — the title, the problem statement, the user-story list, and the module sketch — and wait for the user's approval. A PRD is a durable artifact; don't file it as a surprise. Incorporate their corrections, then proceed.
Once the outline is approved, write the PRD in Markdown using the template below. The PRD should be self-contained — understandable without reading the codebase — and durable — it should not break when the code moves or changes.
Pick a short, descriptive feature name for the title (the # heading). Derive the filename from it, lowercased and hyphenated: a PRD titled "Add a new payment method" is filed at prds/prd-add-a-new-payment-method.md.
Before writing, check whether the target file already exists. If it does, ask the user whether to overwrite it, file under a new name, or stop — never clobber an existing PRD silently.
Durability rule: do NOT include specific file paths, line numbers, or current code snippets. Code moves; the PRD shouldn't break the moment it's read three weeks from now. Describe modules, behaviors, and contracts — not implementation.
Status: Draft · Created:
The problem the user is facing, from the user's perspective. Not "the system has bug X" but "users can't accomplish Y because of X".
The solution to the problem, from the user's perspective. What changes for them when this ships?
How we'll know the problem is actually solved — observable, measurable outcomes. Not "the feature exists" but "X is now possible / Y dropped / Z is measurable". A handful of concrete signals.
A LONG, numbered list of user stories. Each follows the format:
As an <actor>, I want <feature>, so that <benefit>
Example:
For each non-trivial story, add a short Acceptance criteria sub-list — the conditions that make it "done." These become the basis for issues and tests downstream.
This list should be extensive — cover all aspects of the feature, including edge cases, error states, and admin paths. Aim for ≥ 8 stories on a non-trivial feature.
Decisions made during the interview. Include:
Do NOT include file paths, line numbers, or code snippets — they go stale.
What is NOT being built in this PRD. Be explicit. This prevents gold-plating during implementation.
Decisions raised during the interview but deferred — anything unresolved that implementation depends on. Omit if everything was settled.
Optional. Anything else worth recording.
After filing, share the file path with the user. Suggest prd-to-issues as the next step.
