Ir para o conteúdo

NS Flow Kit para Product Owners

Guia de como um PO usa o NS Flow Kit no dia a dia — em discovery e na integração com Azure DevOps/GitHub. Cobre as duas esteiras e o que cada uma entrega.

Pré-requisito: instalação concluída — ver 00 — Instalação e Setup.

As duas esteiras do PO

ESTEIRA DE PRODUTO (upstream do board)        ESTEIRA DE SUSTENTAÇÃO (card-first)
 ideia / texto livre                           demanda do cliente/suporte (já é card)
        │ /discover                                     │ /route
        ▼                                               ▼
 Discovery→Refino→Protótipo→Publica             triagem → bug / data-fix / feature
        └──────────────── convergem no board ──────────┘
                          ▼ cada story → /feature → entrega → learning-agent
  • Produto — você parte de uma ideia e cria a demanda no board já pronta. → Product Discovery Flow
  • Sustentação — a demanda já chegou como card; você triaga e refina.

Onde o PO entra no pipeline

O kit é "agentes executam, humanos decidem". O PO é um dos decisores e atua em 3 zonas:

ENTRADA              DISCOVERY/PRODUTO            ACOMPANHAMENTO
(triagem)            (refino + spec + protótipo)  (board + métricas)
 /route          →   /discover · azure-card-refiner   →   checkpoint-notify · /health-check

Cenários de uso

A. Construir uma feature nova a partir de uma ideia → /discover

Você tem só um texto e nada no board. O /discover conduz Discovery → Refinamento → Protótipo → Publicação, e ao final cria Epic + User Stories prontos. Detalhe completo em Product Discovery Flow.

B. Triar uma demanda que chegou → /route

Card novo no board ("é bug ou regra?"). O /route <ticket> classifica o flow, aponta o repo, sugere severidade P1–P4 com evidência, e cruza com as business-rules do Speckit. Output em .ns-flow/intake/.

C. Refinar um card antes do planning → azure-card-refiner / github-issue-refiner

"Refinar o card 12345". O refiner lê o card + o épico pai, mapeia sistemas impactados, gera critérios de aceite (Given/When/Then), dúvidas para o PO e complexidade P/M/G. Comenta de volta no work item com a tag refinado-claude. Cobre cards dev e não-dev (operações, financeiro, processo).

D. Entender um sistema legado desconhecido → /new-app-expert-agent

Cria um expert da app; depois você pergunta em linguagem natural "como o sistema calcula X?" / "com quais sistemas ele se integra?".

E. Acompanhar progresso sem sair do board → comentários automáticos (checkpoint-notify)

Com checkpointNotifications habilitado, os comandos do fluxo executam o snippet .claude/agents/_shared/checkpoint-notify.md para postar comentários no work item; o learning-agent fecha a issue após o deploy com link do release.

F. Preparar a review com dados → metrics-feed + /health-check

Cada ticket fechado grava cycle time, discovery time, retrabalho e reincidência em .speckit/incidents/metrics-feed.jsonl. O /health-check {sistema} agrega (médias dos últimos 10 tickets).

Discovery — o que muda com a esteira de produto

Antes Com /discover
Discovery em documentos soltos, fora do kit Brief rastreável em .ns-flow/product/
PO escreve critérios de aceite na mão FEAT-{N} Given/When/Then gerados e revisados no CP-D2
Épico/stories digitados manualmente no board Criados via /discover após aprovação (CP-D4)
Validar UI exige designer/ferramenta externa Protótipo clicável (Artifact) ou handoff Lovable

Integração com Azure DevOps / GitHub

Capacidade Como Direção
Ler card (incl. épico pai, comentários, anexos) MCP do provider (ticket-fetch) board → kit
Refinar e comentar no card azure-card-refiner / github-issue-refiner kit → board
Triar a demanda /route board → kit
Criar Epic + User Stories /discover → _shared/ticket-create.md kit → board
Notificar checkpoints / fechar issue checkpoint-notify · learning-agent kit → board

Criação de cards (a peça nova): GitHub via mcp__github__create_issue/gh; Azure via MCP/az boards work-item create. Epic no GitHub = issue com label epic; no Azure é tipo nativo. Tudo marcado com criado-via-nsflow e idempotente.

Limites atuais (honestos)

  • /route e os refiners são 1 card por vez (sem triagem em lote ainda).
  • Não há dashboard de métricas dedicado ao PO — só o jsonl + /health-check por sistema.
  • Lovable é handoff (prompt), não integração automática.
  • A esteira de produto é experimental (ADR-008) — pode mudar após os primeiros pilotos.

Referências

Voltar ao topo