Ir para o conteúdo

Product Discovery Flow
Tipo Produto — esteira upstream do board (discovery de nova feature)
Trigger /discover "{texto do que se quer}"
Fases Discovery → Refinamento → (Protótipo) → Publicação
Agentes product-discovery-agent → _shared/ticket-create.md (publicação)
Checkpoints humanos 3 ou 4 (CP-D3 só se houver protótipo)
Status 🔬 experimental (v1.5.0) — ADR-008

Pré-requisito: instalação concluída — ver 00 — Instalação e Setup. Para publicar cards, o MCP do provider (ou gh/az CLI) precisa estar autenticado com permissão de escrita.

1. O que é e quando usar

A maioria dos workflows do kit começa depois que a demanda já é um card. Este começa antes: o PO entra com um texto livre (sem nada no Azure DevOps/GitHub) e sai com épico + user stories prontos no board, opcionalmente com protótipo.

Use quando: você (PO) tem uma ideia/necessidade de produto e precisa transformá-la em backlog estruturado.

Não use quando: - A demanda já é um card → /route (esteira de sustentação) - É defeito reportado → Bug Flow · correção de dados → Data Fix - O escopo já está claro e é um único item → vá direto para Feature

2. As duas esteiras

ESTEIRA DE PRODUTO (esta — upstream)        ESTEIRA DE SUSTENTAÇÃO (já existe)
 PO tem um texto, nada no board              cliente/suporte → card no Azure/GitHub
 /discover                                    /route
   Discovery→Refino→Protótipo→Publica            ↓
        └────────── convergem no board ──────────┘
                       ↓  cada story → /feature → entrega

A esteira de produto cria a demanda no board já pronta; a de sustentação parte de uma demanda que já é card. As duas alimentam a esteira de dev.

3. Visão geral do fluxo

/discover "{iniciativa}"   → workspace local DISC-{slug} (sem ticket ainda)
    └── [Discovery]    → Product Brief
             ↓  ⚡ CP-D1 (PO valida problema/oportunidade)
    └── [Refinamento]  → FEAT-{N} + árvore Epic → Stories
             ↓  ⚡ CP-D2 (PO valida escopo e decomposição)
    └── [Protótipo]*   → Artifact (Claude) e/ou prompt Lovable
             ↓  ⚡ CP-D3 (validação visual — só se houve)
    └── [Publicação]   → cria Epic + Stories no provider
             ↓  ⚡ CP-D4 (PO aprova ANTES de escrever no board)
    Epic + Stories no board → cada story entra em /feature

4. Passo a passo

Discovery — product-discovery-agent (FASE 1)

Consulta o Speckit (sistema, regras de negócio, hotspots, ADRs), faz perguntas de clarificação e produz o Product Brief (problema, personas, objetivos, métricas de sucesso, escopo IN/OUT, restrições). Output: .ns-flow/product/{DISC_ID}-brief.md → ⚡ CP-D1

Refinamento + Decomposição — product-discovery-agent (FASE 2)

Vira requisitos FEAT-{N} (formato Specify) e decompõe em árvore Epic → User Stories com critérios Given/When/Then, dependências e sizing P/M/G. Output: .ns-flow/product/{DISC_ID}-backlog.md → ⚡ CP-D2

Protótipo (opcional)

O protótipo sempre segue o design, as regras e o layout do projeto (descobertos do código de UI existente, design tokens, PATTERNS.md, .speckit/architecture/ e CLAUDE.md) — não um visual genérico. Sem design system identificável → baseline neutro, sinalizado ao PO. - Claude (Artifact): skill artifact-design → protótipo HTML clicável com link compartilhável, no visual do produto. - Lovable (handoff): .ns-flow/product/{DISC_ID}-lovable-prompt.md (com o design system do projeto) para colar no lovable.dev (handoff, sem API). → ⚡ CP-D3 (só se houve protótipo)

Publicação — _shared/ticket-create.md

Detecta o provider, checa idempotência e cria Epic + Stories vinculados. Grava os IDs reais na Linhagem do Brief. → ⚡ CP-D4 (aprovar antes de escrever)

Convergência

Cada story criada entra em /feature {STORY_ID} — a Specify já encontra os FEAT-{N} prontos.

5. Checkpoints humanos

# Quando Quem aprova Verifica
CP-D1 após Discovery PO Problema/recorte certos? Personas e métrica fazem sentido?
CP-D2 após decomposição PO Escopo sem creep? MVP vs backlog? Critérios testáveis?
CP-D3 após protótipo (se houve) PO/stakeholder Solução visual validada?
CP-D4 antes de publicar PO Aprovar criação dos cards (irreversível)

6. Pastas e arquivos gerados

Fase Arquivo
Workspace .ns-flow/state/{DISC_ID}-state.md
Discovery .ns-flow/product/{DISC_ID}-brief.md
Refinamento .ns-flow/product/{DISC_ID}-backlog.md
Protótipo (Claude) .ns-flow/product/{DISC_ID}-prototype.html + Artifact publicado
Protótipo (Lovable) .ns-flow/product/{DISC_ID}-lovable-prompt.md
Publicação Epic + Stories no board (IDs na Linhagem do Brief)

7. Aplicação pelo time (papéis)

Papel Responsabilidade
PO Dispara /discover, responde clarificações, aprova CP-D1→CP-D4, escolhe se/como prototipar
Stakeholder / negócio Valida o protótipo (CP-D3)
Dev Pega cada story criada e roda /feature {STORY_ID} na esteira de dev

Ganho para o PO: entra com uma frase, sai com épico estruturado, stories testáveis e protótipo no board — sem criar nada manualmente nem escrever critérios de aceite na mão.

8. Exemplo (resumo)

PO tem só: "clientes querem acompanhar o status do reembolso sem ligar no suporte". Roda /discover "..." → o agente descobre que reembolso vive no CITWEB (Speckit), pergunta persona/canal, gera o Brief (CP-D1) → decompõe em Epic + 2 stories com FEAT-{N} (CP-D2) → gera protótipo clicável da tela "Meus reembolsos" (CP-D3) → cria ADO-7012 (Epic) + ADO-7013/7014 (Stories) no board após aprovação (CP-D4). Um dev então roda /feature ADO-7013.

Referências

Voltar ao topo