dev-flow
Fluxo profissional de desenvolvimento com AI — spec-driven, com gates de qualidade e verificação empírica — para Claude Code (plugin) e OpenCode (espelho). Uma fonte de verdade, instalável em qualquer máquina.
Construído para os projetos do Matheus (singolo, worktodo, monitor-imobiliario, clinicas), mas agnóstico de repo: os comandos detectam as convenções do projeto (AGENTS.md/CLAUDE.md) e o gate de validação local.
O fluxo
/flow:grill ──→ /flow:plan ──→ implementação ──→ /flow:ship
(entender) (planejar (codar no (finalizar:
+ aprovar estilo do validar, revisar,
+ spec) projeto) provar, resumir)
Auxiliares: /flow:refactor (melhoria sem mudar comportamento) e /flow:delegate (trabalho mecânico em modelo barato).
Comandos
/flow:grill — entender antes de construir
Entrevista profunda antes de qualquer plano ou código. Uma pergunta por vez, multiple-choice quando possível.
- Triagem embutida: tarefa trivial pula direto pro plan; média ganha 3–5 perguntas; feature/estrutural ganha o processo completo.
- Explora o codebase antes de perguntar — nunca pergunta o que o código já responde.
- Cobre propósito, usuário-alvo, critério de sucesso, non-goals, edge cases e requisitos não-funcionais (escala, performance, segurança, UX).
- Tickets Jira: descrições escritas por reporters não-técnicos (às vezes com AI sem acesso ao código) são tratadas como hipóteses a verificar, nunca como diagnóstico — foco no problema real observado.
- Termina com Understanding Lock: resumo + assunções + perguntas abertas, e só avança com confirmação explícita.
/flow:plan — planejar com gate de aprovação
Usa o plan mode nativo do Claude Code (gate real de aprovação) e exige todas as seções:
- Objetivo com critério de aceite verificável
- Arquivos impactados (novo/editado/removido)
- Abordagens com trade-offs (recomendada primeiro)
- Riscos e rollback
- Impacto em escala e performance (índices/RLS/N+1; bundle/TTI mobile; custo por usuário)
- Segurança
- Estratégia de teste + como será a verificação empírica
- Estimativa: tempo + custo relativo S/M/L
Aprovado → o spec é persistido em docs/specs/YYYY-MM-DD-<slug>.md no repo (≤ 1 página: entendimento, assunções, decisões, plano, verificação). Histórico auditável + contexto reaproveitável entre sessões.
/flow:ship — finalizar (gate de entrega)
Nada está "pronto" sem passar por todos os passos:
- Loop de validação do repo (
yarn validate / npm run validate / pnpm check / tsc + eslint + vitest)
- Code review do diff no formato ✅ Aprovado · ⚠️ Atenção · ❌ Bloqueante (orquestra o
/code-review nativo)
- Edge cases: cada um coberto por teste, verificado manualmente, ou risco aceito com justificativa
- Verificação empírica — compilar não é funcionar: UI roda e observa; função de DB executa como usuário autenticado; API é chamada de verdade. Sem prova runtime, o status declarado é "implementado, não verificado".
- Fecha o spec (
Status: entregue + prova) e resume: o que mudou, como foi verificado, próximos passos
/flow:refactor — melhorar sem mudar comportamento
Baseline verde antes de tocar em qualquer coisa → oportunidades em ordem de valor (duplicação, complexidade, performance, consistência) → propõe antes de aplicar se tocar >3 arquivos ou área sensível → passos pequenos validando cada um → fecha com /flow:ship (verificação aqui = provar que o comportamento NÃO mudou).
/flow:delegate — modelo barato escreve, Claude revisa
Para trabalho mecânico bem especificado (boilerplate, testes a partir de exemplos, conversões repetitivas):
prompt autocontido → opencode run -m opencode-go/minimax-m3 "<tarefa>" → Claude revisa o diff como revisor cético → valida → aceita ou corrige
Nunca para design, debugging ou áreas sensíveis (auth/RLS/migrations). O diff do worker é proposta, não código aceito — a responsabilidade pelo resultado é de quem revisou.
Skill flow:standards
Carregada automaticamente por plan/ship/refactor. Padrões transversais e inegociáveis:
