hm-validate-all - SKILL.md Agent Skill

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:

typecheck verde — coberto por /hm-qa + /hm-engineer
lint verde — coberto por /hm-qa + /hm-engineer
smoke test rodado pelo Dev Team — coberto por /hm-qa
zero console.error em código novo — coberto por /hm-qa
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:

/hm-security primeiro. Security gate bloqueia tudo. Se tem CRÍTICO, não continua com as outras (perda de tempo).
/hm-engineer depois. Código fundamenta funcionalidade. Bug estrutural invalida QA passing.
/hm-qa terceiro. Funcionalidade validada apos segurança + código OK.
/hm-designer quarto. Design polish vale apos funcional. Inverso = polir UI de feature quebrada.
/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.