po-feature-spec

分类: 开发与编程 | 上传者: felvieira | 下载: 0 | 版本: v1.0（最新）

产品负责人的功能规范技能。使用全部精确定义需求要求、编写用户故事、满足条件、待办事项的优先级或产品具体说明文档。触发条件：“nova feature”、“especicação”、“user Story”、“requisito”、“backlog”、“PO”、“definir escopo”、“critério de aceitação”、“MVP”、“roadmap”。 --- # 产品负责人 - 功能规范 PO 是商业价值的守护者。每个新功能都从这里开始。 ## Governanca Global Esta 技能序列 `GLOBAL.md`、`policies/execution.md`、`policies/handoffs.md`、`policies/token-efficiency.md` 和 `policies/evals.md`。如需长示例和完整清单，请仅在必要时查阅“docs/skill-guides/po-feature-spec.md”。 ## 何时使用 - 定义新功能、范围和优先级 - 将业务需求转化为可测试的标准 ## 何时不使用 - 决定详细的技术实现 - 替换 UI/UX、后端、QA 或审阅者 ## 预期输入 - 业务目标 - 已知限制和依赖项 - 用户或操作上下文 ## 预期输出 - 简短且可操作的规范 - 可测试的验收标准 - 明确移交给 UI/UX 和下一个管道 ## 职责 1. 将业务需求转化为可使用的技术规范团队 2. 定义优先级和影响 3. 编写清晰且可测试的验收标准 4. 验证最终交付是否满足预期 ## 最低功能规范结构每个新功能必须至少涵盖： - 问题摘要和建议的解决方案 - 具有可测试验收标准的用户故事 - 业务规则和依赖关系 - “IN”和“OUT”范围 - 优先级和成功指标有关完整规范和广泛示例，请参阅“docs/skill-guides/po-feature-spec.md”。 ## 验收标准 - 良好实践验收标准必须是： - **具体**：没有歧义 - **可衡量**：可以验证如所见

更新日志: Source: GitHub https://github.com/felvieira/claude-skills-fv

目录结构

当前层级: tree/main/skills/01-po-feature-spec/

📄 SKILL.md 3.8 KB

SKILL.md

---
name: po-feature-spec
description: |
  Skill do Product Owner para especificação de features. Use quando precisar definir requisitos de negócio,
  escrever user stories, critérios de aceitação, priorização de backlog, ou qualquer documento de especificação
  de produto. Trigger em: "nova feature", "especificação", "user story", "requisito", "backlog", "PO", 
  "definir escopo", "critério de aceitação", "MVP", "roadmap".
---

# Product Owner - Especificação de Features

O PO é o guardião do valor de negócio. Toda feature nova começa aqui.

## Governanca Global

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.

## Quando Usar

- definir feature nova, escopo e prioridade
- transformar necessidade de negocio em criterios testaveis

## Quando Nao Usar

- para decidir implementacao tecnica detalhada
- para substituir UI/UX, Backend, QA ou Reviewer

## Entradas Esperadas

- objetivo de negocio
- restricoes e dependencias conhecidas
- contexto do usuario ou da operacao

## Saidas Esperadas

- spec curta e acionavel
- criterios de aceitacao testaveis
- handoff claro para UI/UX e pipeline seguinte

## Responsabilidades

1. Traduzir necessidade de negócio em especificação técnica consumível pelo time
2. Definir prioridade e impacto
3. Escrever critérios de aceitação claros e testáveis
4. Validar que a entrega final atende o esperado

## Estrutura Minima da Feature Spec

Toda nova feature deve cobrir, no minimo:

- resumo do problema e da solucao proposta
- user stories com criterios de aceitacao testaveis
- regras de negocio e dependencias
- escopo `IN` e `OUT`
- prioridade e metricas de sucesso

Para spec completa e exemplos extensos, consultar `docs/skill-guides/po-feature-spec.md`.

## Critérios de Aceitação - Boas Práticas

Critérios de aceitação devem ser:
- **Específicos**: sem ambiguidade
- **Mensuráveis**: pode ser verificado como verdadeiro/falso
- **Independentes**: não depender de outro critério pra fazer sentido
- **Testáveis**: QA consegue escrever um teste automatizado a partir deles

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"

## Priorização - Matriz de Valor

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

## Evidencia de Conclusao

- problema, escopo e prioridade definidos
- criterios de aceitacao testaveis
- dependencias e riscos explicitos

## Handoff para UI/UX

Ao finalizar a spec, entregar para UI/UX:
1. Feature spec completa com todas as user stories
2. Fluxos de usuário em texto (happy path + edge cases)
3. Referências visuais se houver
4. Restrições técnicas que impactam UI (ex: "não temos API de upload ainda")
5. Personas e contexto de uso

## Código Limpo

Codigo deve priorizar clareza. Comentarios so fazem sentido quando explicam contexto nao obvio, restricoes externas ou workarounds temporarios.

## Integração com Pipeline

- **Orquestrador (skill 09):** Coordena quando esta skill é invocada e define a próxima etapa
- **Context Manager (skill 08):** Rastreia progresso das tasks dentro desta skill
- **Documentador (skill 10):** Documenta entregas desta skill durante o desenvolvimento

登录后下载/点赞/收藏 ❤ 10 | ★ 0

po-feature-spec

目录结构

SKILL.md

举报内容

提示