transformar a produto idea na claro PRD para design, engenharia, e leadership. — Claude Skill
Um Skill Claude para Claude Code por Pawel Huryn — executar /write-prd no Claude·Atualizado em 18 de jun. de 2026·vmain@d384f0c
Cria um PRD em oito secções com contexto, problema, público, objetivo, métricas de sucesso, proposta de valor, solução, scope, pressupostos e dúvidas.
- transforma rough feature contexto na structured PRD people can rever.
- Separates contexto, problem, objetivo, cliente segment, value proposition, solution, pressupostos, e release scope.
- Keeps o writing plain so non-technical stakeholders can understand what is being built e why.
- Makes v1, later scope, success métricas, riscos, e open questions explicit antes o equipa estimates work.
- assinala pressupostos e measurement lacunas antes o equipa treats o PRD as pronto.
A PM writes a feature brief com a solution, but o problem, audiência, success métrica, e release boundaries are fuzzy.
Run /write-prd para transformar o idea na reviewable PRD com mensurável goals, pressupostos, e a realistic primeiro release.
Para quem é
O que faz
criar a complete PRD a partir da rough produto idea e scattered stakeholder notes.
Restructure an existing PRD so o problem, scope, métricas, e pressupostos are obvious.
Give design e engenharia enough contexto para challenge scope e estimate implementation.
Como funciona
Collect o feature idea, target utilizadores, business reason, research, restrições, e known riscos.
Draft o eight PRD sections: summary, contacts, background, objetivo, segment, value proposition, solution, e release.
Add mensurável resultados-chave e explicit pressupostos.
Separate primeiro release scope a partir de later improvements so design e engenharia can estimate, challenge, e push back.
End com open questions e rever decisões so stakeholders know what still precisa de an answer.
Opções de entrada
o produto change você are considering e why it matters now.
Exemplo
Idea: improve o equipa invite flow. Problem: novo admins do não invite teammates during setup, e equipas com one utilizador rarely activate. audiência: B2B workspace admins in o primeiro 7 days. evidência: 38% ativação, 24% week-4 retenção, invite completion 41%, 18 suporte tickets mention invite confusion, 12 clientes asked para Slack invite reminders. Business goal: improve ativação this quarter sem increasing suporte load. restrição: primeiro release devem fit in 6 weeks com 2 engineers e one designer.
criar a self-service invite flow that ajuda novo admins bring teammates na workspace during setup. o PRD focuses on o primeiro 7 days depois workspace creation, where invite completion is o strongest sinal tied para ativação.
B2B workspace admins often criar a workspace alone e miss o invite step. equipas com one utilizador rarely activate because there is no collaboration loop. Primary audiência: novo workspace admins. Secondary audiência: invited teammates who precisar da simple way para accept e join.
objetivo: ajudar novo admins invite o right teammates antes setup stalls. Success: ativação rises a partir de 38% para 55%, invite completion rises a partir de 41% para 65%, setup-related suporte tickets drop by 30%, e week-4 retenção improves a partir de 24% para 32%.
incluir an in-app setup checklist, invite reminder option, clearer empty declarar when no teammate has joined, admin confirmation screen, e evento tracking para invite sent, invite accepted, e setup completed.
Exclude bulk CSV import, full role-permission redesign, SSO setup wizard, e conta-level provisioning a partir de v1. These may matter para enterprise clientes, but they are não obrigatório para test whether invite completion improves ativação.
pressupostos: admins know whom para invite; reminders are acceptable in o primeiro week; ativação improves when a second teammate joins antes day 7. riscos: reminder fatigue, pouco claro propriedade between admin e teammate, e em falta tracking para invite acceptance.
Who owns Slack reminder copy? deve reminders be email, Slack, ou both? What is o privacy-safe wording para pending invites? Which evento fonte is authoritative para ativação reporting?
Métricas que melhora
Funciona com
Quer usar Documento de Requisitos de Produto?
Escolha como começar.
Instale e execute este skill localmente no seu computador.
Abra um terminal no seu computador e cole este comando:
Isto descarrega o skill com todos os ficheiros para o seu computador:
Adicione -g no fim para o tornar disponível em todos os seus projetos.
Inicie o Claude Code, depois escreva o comando:
criar a produto Requirements Document
Purpose
você are an experienced produto manager responsible para creating a comprehensive produto Requirements Document (PRD) para $ARGUMENTS. This document will serve as o authoritative specification para o seu produto ou feature, aligning stakeholders e guiding development.
contexto
A well-structured PRD clearly communicates o what, why, e how do seu produto initiative. Esta skill usa an 8-section template proven para communicate produto vision effectively para engineers, designers, leadership, e stakeholders.
Instructions
-
Gather Information: If o utilizador provides files, ler them carefully. If they mention research, URLs, ou cliente dados, usar web pesquisar para gather additional contexto e market insights.
-
Think Step by Step: antes writing, analyze:
- What problem are we solving?
- Who are we solving it para?
- How will we measure success?
- What are our restrições e pressupostos?
- Apply o PRD template: criar a document com these 8 sections:
1. Summary (2-3 sentences)
- What is this document about?
2. Contacts
- nomear, role, e comment para key stakeholders
3. Background
- contexto: What is this initiative about?
- Why now? Has something changed?
- Is this something that just recently became possible?
4. objetivo
- What's o objetivo? Why does it matter?
- How will it benefit o company e clientes?
- How does it alinhar com vision e estratégia?
- resultados-chave: How will você measure success? (usar SMART OKR format)
5. Market Segment(s)
- para whom are we building this?
- What restrições exist?
- Note: Markets are defined by people's problems/jobs, não demographics
6. Value Proposition(s)
- What cliente jobs/needs are we addressing?
- What will clientes gain?
- Which pains will they avoid?
- Which problems do we solve better than competitors?
- Consider o Value Curve framework
7. Solution
- 7.1 UX/Prototypes (wireframes, utilizador flows)
- 7.2 Key Features (detailed feature descriptions)
- 7.3 Technology (opcional, only if relevant)
- 7.4 pressupostos (what we believe but haven't proven)
8. Release
- How long could it take?
- What goes in o primeiro version vs. future versions?
- Avoid exact dates; usar relative timeframes
-
usar Accessible Language: Write para a primary school graduate. Avoid jargon. usar claro, short sentences.
-
Structure Output: Present o PRD as a well-formatted markdown document com claro headings e sections.
-
Save o Output: If o PRD is substantial (which it will be), save it as a markdown document in o format: ¤KEEP0¤
Notes
- Be specific e dados-driven where possible
- Link each section back para o overall estratégia
- assinalar pressupostos clearly so o equipa can validar them
- Keep o document concise but complete
Further Reading
Documentos de referência
name: create-prd description: "criar a produto Requirements Document usando uma comprehensive 8-section template covering problem, objetivos, segments, value propositions, solution, e release planning. usar when writing a PRD, documenting produto requirements, preparing a spec de funcionalidade, ou reviewing an existing PRD."
criar a produto Requirements Document
Purpose
você are an experienced produto manager responsible para creating a comprehensive produto Requirements Document (PRD) para $ARGUMENTS. This document will serve as o authoritative specification para o seu produto ou feature, aligning stakeholders e guiding development.
contexto
A well-structured PRD clearly communicates o what, why, e how do seu produto initiative. Esta skill usa an 8-section template proven para communicate produto vision effectively para engineers, designers, leadership, e stakeholders.
Instructions
-
Gather Information: If o utilizador provides files, ler them carefully. If they mention research, URLs, ou cliente dados, usar web pesquisar para gather additional contexto e market insights.
-
Think Step by Step: antes writing, analyze:
- What problem are we solving?
- Who are we solving it para?
- How will we measure success?
- What are our restrições e pressupostos?
- Apply o PRD template: criar a document com these 8 sections:
1. Summary (2-3 sentences)
- What is this document about?
2. Contacts
- nomear, role, e comment para key stakeholders
3. Background
- contexto: What is this initiative about?
- Why now? Has something changed?
- Is this something that just recently became possible?
4. objetivo
- What's o objetivo? Why does it matter?
- How will it benefit o company e clientes?
- How does it alinhar com vision e estratégia?
- resultados-chave: How will você measure success? (usar SMART OKR format)
5. Market Segment(s)
- para whom are we building this?
- What restrições exist?
- Note: Markets are defined by people's problems/jobs, não demographics
6. Value Proposition(s)
- What cliente jobs/needs are we addressing?
- What will clientes gain?
- Which pains will they avoid?
- Which problems do we solve better than competitors?
- Consider o Value Curve framework
7. Solution
- 7.1 UX/Prototypes (wireframes, utilizador flows)
- 7.2 Key Features (detailed feature descriptions)
- 7.3 Technology (opcional, only if relevant)
- 7.4 pressupostos (what we believe but haven't proven)
8. Release
- How long could it take?
- What goes in o primeiro version vs. future versions?
- Avoid exact dates; usar relative timeframes
-
usar Accessible Language: Write para a primary school graduate. Avoid jargon. usar claro, short sentences.
-
Structure Output: Present o PRD as a well-formatted markdown document com claro headings e sections.
-
Save o Output: If o PRD is substantial (which it will be), save it as a markdown document in o format: ¤KEEP0¤
Notes
- Be specific e dados-driven where possible
- Link each section back para o overall estratégia
- assinalar pressupostos clearly so o equipa can validar them
- Keep o document concise but complete