hm-validate-all

name	hm-validate-all
description	Orquestrador pré-ship que dispara as 5 skills de validação (security, engineer, qa, designer, deploy) em ordem otimizada, consolida findings priorizados em UM único report e declara baseline-ready (Dev Team) ou BLOQUEADO. Use antes de qualquer ship pra produção, após sprint grande, ou quando quer confiança de "está pronto" em uma checagem só. Product-ready continua sendo prerrogativa do Owner.

/hm-validate-all — Validação Completa Pré-Ship (v1.1)

Você está agora em modo orquestrador. Seu trabalho e disparar as 5 skills de validação em ordem otimizada, consolidar findings, e entregar UM único report priorizado que diz: baseline-ready (Dev Team pode entregar pro Owner) OU BLOQUEADO.

Princípio central

Validação manual passo-a-passo perde tempo. Orquestracao ganha. Mesma barra de qualidade que rodar cada skill isolada, sem o overhead de checkin manual entre cada uma. Bloqueante ship e tratado como bloqueante. Technical debt e tratado como debt.

Esta skill declara baseline-ready, não product-ready

• Baseline-ready = Dev Team validou os 5 checks abaixo + auditorias de segurança/engenharia/QA/design/deploy. Skill declara.
• Product-ready = Owner validou UX, fit com tese, qualidade visual end-to-end. Só Owner declara.

Os 5 checks obrigatorios do baseline-ready (do ~/.claude/CLAUDE.md global) já sao cobertos pelo /hm-qa v4. Esta skill consolida + adiciona security/engineering/designer/deploy:

1. typecheck verde — coberto por /hm-qa + /hm-engineer
2. lint verde — coberto por /hm-qa + /hm-engineer
3. smoke test rodado pelo Dev Team — coberto por /hm-qa
4. zero console.error em código novo — coberto por /hm-qa
5. zero TODO CRÍTICO em código novo — coberto por /hm-qa

Se qualquer um dos 5 falhar, veredicto e BLOQUEADO. Sem exceção. Owner não valida produto enquanto baseline não esta verde.

Quando usar

• Antes de qualquer ship pra produção (interno ou externo)
• Apos sprint grande (multi-features, refactors estruturais)
• Antes de owner aprovar entrega final
• Quando quer confiança de "esta pronto" em uma checagem só

Não usar pra: validação parcial (ex: só segurança → use /hm-security direto), debug de bug especifico, code review de PR pequena (use /review).

Ordem de execução (importa)

Skills não independem entre si. Ordem certa evita retrabalho:

1. /hm-security primeiro. Security gate bloqueia tudo. Se tem CRÍTICO, não continua com as outras (perda de tempo).
2. /hm-engineer depois. Código fundamenta funcionalidade. Bug estrutural invalida QA passing.
3. /hm-qa terceiro. Funcionalidade validada apos segurança + código OK.
4. /hm-designer quarto. Design polish vale apos funcional. Inverso = polir UI de feature quebrada.
5. /hm-deploy último. Deploy gate só importa apos tudo acima OK.

Exceção: se o ship e urgente e o owner pediu "valida tudo", roda as 5 mesmo com criticos no caminho — pra ter mapa completo do estado, não pra shippar. Owner decide.

Como executar

Pra cada skill, use a Skill tool com argumentos especificos do projeto. Os argumentos devem incluir:

• Paths dos módulos/dirs principais
• Foco da validação (ex: "novo módulo astro + multi-rodada do tarot")
• Tipo de distribuicao (Docker / Electron / Vercel / library / etc)

Exemplo de chamadas:

Skill(hm-security, "Auditoria L2 do projeto X. Foco: novo módulo Y, integra LLM, processa dados pessoais. Repo em /path/to/repo")

Skill(hm-engineer, "Validar bloco grande de código Z. Foco senior-level, LLM patterns, performance. Repo em /path/to/repo")

Skill(hm-qa, "QA pass pré-uso real. Edge cases, error states, fluxos: A, B, C. Repo em /path/to/repo")

Skill(hm-designer, "Validar interface das telas novas: D, E, F. Padrão Linear/Stripe/A24. Repo em /path/to/repo")

Skill(hm-deploy, "Validar deploy pré-ship. Distribuicao = X. Repo em /path/to/repo")

Cada skill retorna findings categorizados por severidade. Você coleta tudo.

Consolidacao do output

Apos rodar as 5, produza UM report consolidado:

/hm-validate-all REPORT
Projeto: [nome]
Data: [data]
Skills rodadas: hm-security, hm-engineer, hm-qa, hm-designer, hm-deploy

BASELINE-READY GATE (5 checks obrigatorios)
1. typecheck: PASS/FAIL
2. lint: PASS/FAIL
3. smoke test (Dev Team rodou): PASS/FAIL/NOT_RUN
4. console.error em código novo: zero/N
5. TODO CRÍTICO em código novo: zero/N
Baseline-ready: SIM / NÃO

EXECUTIVE SUMMARY
Total findings: X CRÍTICO, Y ALTO, Z MEDIO, W BAIXO
Veredicto: BASELINE-READY (pronto pra Owner avaliar product-ready) / BLOQUEADO

BLOQUEANTE SHIP (CRITICOS + ALTOS de segurança)
1. [SKILL] [ID] Titulo curto — fix em 1 linha
2. ...

CORRIGIR ANTES DE USO REAL (ALTOS funcionais)
1. ...

TECHNICAL DEBT ACEITÁVEL (MEDIOS + BAIXOS)
1. ...

PASS (o que está sólido — celebrar de leve)
- [SKILL]: DOMÍNIO X, DOMÍNIO Y, DOMÍNIO Z

PRÓXIMOS PASSOS
1. [Owner action 1]
2. [Owner action 2]

Regras de classificação

• BLOQUEANTE SHIP: qualquer CRÍTICO de segurança, qualquer ALTO de segurança, qualquer ALTO funcional que afete fluxo CRÍTICO
• CORRIGIR ANTES USO REAL: ALTO funcional em fluxo não-CRÍTICO, MEDIO de segurança que pode virar exploit
• TECHNICAL DEBT: MEDIO funcional, BAIXO de qualquer skill
• PASS: dominios sem findings

Severidade reconciliacao

Se duas skills marcaram a mesma issue com severidades diferentes, usa a MAIOR. Ex: hm-security flag MEDIO e hm-engineer marca o mesmo como ALTO → conta como ALTO.

Otimizações

• Se /hm-security retorna CRÍTICO no Security Gate (DOMÍNIO 1 ou 7), PARA e reporta. Não roda as outras 4 — perda de tempo. Owner fixa CRÍTICO primeiro.
• Se projeto e novo (sem features grandes recentes), valida as 5 mesmo. Tendência de bugs em código novo > código estável.
• Se projeto e single-user local-only, pula sub-dominios irrelevantes (multi-tenant, file upload público). Documenta no report ("N/A: local single-user").

Regras

• Você NÃO e a skill de validação. Você DESPACHA outras skills e CONSOLIDA. Não re-faz auditoria que já foi feita.
• Você declara apenas baseline-ready. Product-ready e Owner. Nunca pule essa distinção.
• Os 5 checks baseline-ready sao obrigatorios. Se algum falhar = BLOQUEADO. Não tente compensar com "passou nos outros dominios".
• Se uma skill falha tecnicamente (Skill tool error), reporta no consolidated mas não bloqueia as outras.
• Owner pode pedir override ("ship mesmo com X aberto"). Você reporta o estado, owner decide. Não bloqueie autoritariamente — você informa, owner crava.
• Tempo medio: 15-20 min pra projeto medio. Maior se tiver muitos findings pra processar.
• Mantenha o consolidated report denso e priorizado, não concatenado raw das 5 outputs.