From dev-team-kit-fv
Generates product feature specs with user stories, testable acceptance criteria, scope IN/OUT, priority, success metrics, and vertical slices for multi-layer features. Use for business requirements and dev handoffs.
npx claudepluginhub felvieira/claude-skills-fvThis skill uses the workspace's default tool permissions.
O PO é o guardião do valor de negócio. Toda feature nova começa aqui.
Writes structured feature specs or PRDs from problem statements or ideas. Covers problem, goals/non-goals, user stories, prioritized requirements, and success metrics.
Conducts structured requirements workshops producing feature specifications, user stories, EARS-format requirements, acceptance criteria, and implementation checklists. Use for defining features or gathering requirements.
Share bugs, ideas, or general feedback.
O PO é o guardião do valor de negócio. Toda feature nova começa aqui.
Esta skill segue GLOBAL.md, policies/execution.md, policies/handoffs.md, policies/token-efficiency.md e policies/evals.md.
Para exemplos longos e checklists completos, consultar docs/skill-guides/po-feature-spec.md apenas quando necessario.
Toda nova feature deve cobrir, no minimo:
IN e OUTPara spec completa e exemplos extensos, consultar docs/skill-guides/po-feature-spec.md.
Se a feature envolve >1 camada (front + back + DB ou similar), a spec deve organizar user stories como vertical slices demo-able. Cada slice e uma feature ponta-a-ponta testavel sozinha — nao subdividir por camada (ex: "spec do front", "spec do back" — errado).
Exemplo bom (vertical):
Exemplo ruim (layered):
Cada slice deve:
Detalhes em policies/vertical-slices.md.
Critérios de aceitação devem ser:
Exemplo ruim: "O sistema deve ser rápido" Exemplo bom: "DADO que o usuário está na listagem QUANDO clicar em filtrar ENTÃO os resultados carregam em menos de 500ms"
Use a fórmula: Score = (Impacto × Urgência) / Esforço
| Impacto | Valor |
|---|---|
| Alto | 3 |
| Médio | 2 |
| Baixo | 1 |
| Urgência | Valor |
|---|---|
| Alta | 3 |
| Média | 2 |
| Baixa | 1 |
| Esforço | Valor |
|---|---|
| PP | 1 |
| P | 2 |
| M | 3 |
| G | 5 |
| GG | 8 |
Score > 3 = Prioridade máxima Score 1.5-3 = Próximo sprint Score < 1.5 = Backlog
Ao finalizar a spec, entregar para UI/UX:
Para features ambíguas ou inovadoras, use frameworks de ideação antes de especificar.
Consultar: docs/skill-guides/ideation-frameworks.md
Quando usar:
Quando pular:
Ordem recomendada: JTBD → HMW → SCAMPER → First Principles
Antes de iniciar a spec, calcular o ambiguity score para decidir se o briefing e suficiente.
Formula:
ambiguity = 1 - (goal * 0.40 + constraints * 0.30 + criteria * 0.30)
Variante Brownfield (codebase conhecida):
ambiguity = 1 - (goal * 0.30 + constraints * 0.25 + criteria * 0.25 + context_clarity * 0.20)
Thresholds:
score < 0.4 → prosseguir diretoscore 0.4-0.7 → enrich mode (inferir do repo-audit e confirmar)score > 0.7 → iniciar Deep InterviewUsar devkit_ambiguity_score (MCP) para calcular programaticamente.
Acionar quando score > 0.7. Seguir templates/deep-interview.md.
Principios:
Enrich Mode (score 0.4-0.7): Usar repo-audit, session summary, git log e stack para inferir o que falta. Apresentar:
"Entendi que voce quer [X]. Baseado no projeto:
- Escopo: [inferido do repo-audit]
- Arquivos provaveis: [do repo-audit]
- Constraints: [da stack conhecida]
→ Bora assim?
→ Quer ajustar ou detalhar algo?
→ Ou era outra coisa?"
Codigo deve priorizar clareza. Comentarios so fazem sentido quando explicam contexto nao obvio, restricoes externas ou workarounds temporarios.