Transform vague internet product ideas into reviewable product requirements documents (PRDs). The input can be a one-sentence requirement or existing materials; the output is a PRD draft that clearly marks assumptions, scope, and open items, rather than an unverified implementation commitment.
Customer-readable explanation
What this skill can do
| The customer wants | The skill will do | The customer can see |
|---|---|---|
| Turn a one-sentence idea into a PRD | Use minimal follow-up questions to guide completion of key context and explicitly record unknowns | A PRD draft with assumptions and open items |
| Organize existing requirements materials | Summarize the problem, goals, user stories, scope, and acceptance conditions | A reviewable structured requirements list |
| Prepare for requirements review | Check scope boundaries, verifiability, dependencies, and risks | Review questions, milestone suggestions, and a risk table |
How customers use it
Directly describe the product opportunity, target users, problem to be solved, or expected outcome; existing interview summaries, requirement notes, or constraints may also be provided. Example:为 ExampleCorp 的示例产品起草一个 PRD：让新用户在移动端完成首次任务。
If the input is only one sentence, first ask no more than five questions ordered by impact, prioritizing confirmation of target users, problem evidence, success metrics, constraints, and launch window. When the customer cannot answer for the time being, use clear "assumption" placeholders to continue drafting, and do not write assumptions as facts.
Dependencies and installation
This is a pure methodology skill with no hard dependencies, optional tool dependencies, or private configuration; it does not read the company knowledge base, and does not execute code, data, or remote system operations.
claude plugin marketplace add soia-team/soia-open-skills
claude plugin install soia-dev-design@soia
When only this one skill is needed, the npx route can be used. Note that the skill will land in the shared source of truth ~/.agents/skills; if a plugin is also installed, the same skill will have two indexes and each will drift, so it is recommended to choose one of the two:
npx skills add soia-team/soia-open-dev-design-skills -g -a '*' -s soia-dev-design-draft-prd -y
The configuration convention uses schema v2:~/.config/soia-skills/soia-dev-design-draft-prd/config.yml. This skill does not require creating this file by default; if the customer wants to reuse document templates, glossaries, or default delivery formats over the long term, they can be defined in their own configuration, and credentials or private business materials must not be placed in it.
Workflow
WorkBuddy The loading unit of is role-based experts rather than plugins,npx skills add -a '*' cannot cover it, and it needs to be installed separately, see docs/install/workbuddy.md。
1. Establish requirement boundaries
Restate the known requirements, and distinguish observed facts, reasonable inferences, and unverified assumptions. Confirm that what is delivered is a draft rather than a project initiation, scheduling, or R&D commitment; without customer authorization, do not make business, compliance, or release decisions on the customer's behalf.
2. Complete the most critical information
Ask questions from the following dimensions, choosing the items with the largest information gaps: target users and usage scenarios, current problems and evidence, business goals and success metrics, time/platform/compliance constraints, existing capabilities, and explicit exclusions. Avoid asking questions just to fill out a template; put low-risk details that can be reasonably assumed into open items.
3. Draft the problem, goals, and boundaries
Start with the user problem rather than preset features. Goals should include observable outcomes or measurement methods; non-goals should exclude adjacent matters that are easily misunderstood as part of this scope. If there is no baseline data, state the metrics to be collected and the collection method, and do not fabricate values.
4. Define user stories and functional scope
For each core scenario, write "As a <user>, I want <action>, so that <outcome>". Layer the functional scope as must-have, should-have, could-have, or explicitly out of scope; describe key flows, exception paths, permission/state boundaries, and cross-team dependencies. Functional descriptions should focus on observable behavior and avoid pre-locking technical implementation.
5. Write acceptable conditions
For each must-have scope item, define independently verifiable acceptance criteria covering the normal path, key failure paths, and boundary conditions. Use observable preconditions, actions, and outcomes; expressions such as "good experience" or "fast performance" must be changed into verifiable metrics or listed as pending.
6. Plan milestones, risks, and open items
Organize milestones by verifiable outcomes, such as "requirements confirmed", "prototype validated", "usable version", "launch retrospective", without fabricating dates, resources, or commitments. Write risks as "trigger condition—impact—mitigation/validation action"; list unresolved questions separately, indicating the suggested owner or required evidence.
7. Self-check and delivery
Check from the opposite direction: whether the goals can be supported by the functional scope, whether non-goals prevent scope creep, whether every must-have feature has acceptance criteria, and whether every fact has a source or is labeled as an assumption. Before delivery, remove duplicate descriptions and unproven assertions, and state what needs client confirmation.
Output contract
By default, output in Markdown, including the following sections; a client-required internal template may change the layout, but must not omit uncertainty markers:
# <产品/功能名称> PRD
## 背景与问题
## 目标与非目标
## 目标用户与场景
## 用户故事
## 功能范围
## 验收标准
## 里程碑
## 风险与缓解
## 开放项与假设
- Background and problem: state only facts provided by the client or judgments labeled as assumptions.
- Goals and non-goals: goals include success signals; non-goals clearly define what is not addressed this time.
- User stories, functional scope, and acceptance criteria: mutually traceable; all must-have scope items have at least one acceptance condition.
- Milestones: described by outcomes and confirmation points; do not commit to specific dates or staffing without basis.
- Risks and open items: each includes impact, next validation or decision information; unknowns are not disguised as conclusions.
Private information and intermediate data
- Use only requirement information provided by the client in the current conversation or explicitly authorized materials; do not read, infer, or repeat any unauthorized company knowledge base, account information, or personal data.
- By default, generate drafts only in the conversation and do not write to local disk. When the client requests saving, write to the location specified by the client; contacts, real business data, and attachment links in drafts must be desensitized as requested by the client.
- This skill does not require credentials and does not record runtime state, cache, or temporary data. If the client sets up their own configuration, only non-sensitive format preferences are saved in the configuration, and the retention period is controlled by the client.
Logs and completion receipt
The final reply should briefly state: the input scope used, assumptions proposed or adopted, PRD sections generated, unresolved open items, and recommended next steps (for example, confirming metrics or review scope). Do not claim to have completed user research, technical assessment, compliance review, or launch decisions unless the client has separately provided corresponding evidence.
Quality and safety boundaries
- Use general internet product practices and fictional examples; do not rely on any organization-specific terminology, systems, processes, or data.
- Do not fabricate user research, market data, metric baselines, client commitments, schedules, or legal conclusions.
- When privacy, security, payment, medical, financial, or regulatory requirements are involved, label them as risks pending professional review and do not provide substitute professional advice.
- The output is requirements communication material; implementation plans, technical architecture, project schedules, and release authorization must be separately confirmed by the responsible parties.
Agent Metadata
agents/openai.yaml Only interface display and example prompts are provided; all portable execution requirements are governed by this document.
Verification
- Static: Confirm that the frontmatter, directory structure, and Markdown links pass the repository audit.
- Content: Use a fictional requirement in one sentence to check that the eight required sections can be generated, and mark unknown information as assumptions or open items.
- Security: Before submission, scan for private paths, credentials, and proprietary terms that should not appear.