# Verificar Antes De Reportar

> Exige prova medida antes de declarar qualquer trabalho como concluído — contraste, overflow, alvos de toque, endpoint respondendo, teste passando. Use ao terminar qualquer tarefa visual, de API ou de infraestrutura, antes de dizer que está pronto.

- Skill: `slayer1dev/verificar-antes-de-reportar` (Agent Skill)
- Install (CLI): `npx skillmds@latest add slayer1dev/verificar-antes-de-reportar`
- Raw SKILL.md: https://api.skillmd.com/api/skills/slayer1dev/verificar-antes-de-reportar/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: Slayer1Dev (https://skillmd.com/u/slayer1dev)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/slayer1dev/verificar-antes-de-reportar

---


# Verificar antes de reportar

"Ficou bom" não é verificação. "Contraste 5.55:1, mínimo AA é 4.5" é.

A diferença importa porque relatar sem medir **destrói a confiança em todo o resto**: uma vez que o usuário descobre uma afirmação não verificada, ele passa a checar todas as outras — e o trabalho de reportar perde o valor.

## A regra

Antes de escrever "pronto", "funcionando" ou "corrigido", responda: **qual comando eu rodei que prova isso?**

Se não houver comando, não houve verificação. Rode ou diga que não verificou.

## O que medir, por tipo de trabalho

### Visual

| Afirmação | Como provar |
|---|---|
| "contraste está bom" | calcular a razão e comparar com 4.5:1 (texto) / 3:1 (texto grande) |
| "é responsivo" | `document.documentElement.scrollWidth > window.innerWidth` em 375, 768, 1024, 1440 |
| "dá pra clicar no celular" | varrer `a, button` e achar altura < 44px |
| "o CSS carregou" | ler a cor computada do `body`, não olhar o print |
| "a fonte aplicou" | `getComputedStyle(el).fontFamily` — o navegador pode ter caído no fallback |

Print é útil para julgar estética, **não** para verificar medida. Olho não mede contraste.

### API e backend

- "o endpoint funciona" → `curl -o /dev/null -w "%{http_code}"`, e diga o código
- "a autenticação protege" → teste **sem** credencial (espera 401) **e** com (espera 200). Só o caminho feliz não prova nada
- "o banco está certo" → conte as linhas, liste as tabelas
- "não tem erro de tipo" → `tsc --noEmit`, e mostre que saiu vazio

### Infraestrutura

- "o serviço sobe" → `systemctl is-active`, e também `is-enabled` se precisa sobreviver a reboot
- "está no ar" → requisição do **cliente real**, não do próprio host. Bind em `127.0.0.1` responde local e falha de fora
- "o certificado é válido" → `curl` **sem** `-k`. Com `-k` você testou que existe TLS, não que ele é confiável

### Delegação para outro agente

Nunca confie no relatório de quem executou. Rode você mesmo o que prova:
- os testes que ele escreveu passam?
- o typecheck passa?
- ele respeitou as restrições? (`diff` nos arquivos que ele não deveria tocar)
- adicionou dependência que não devia?

Um agente que diz "implementei os 5 testes" e escreveu 5 testes que não rodam entregou zero.

## Quando a verificação falha

Reporte o número real, não o rótulo. "42px, faltam 2 para o mínimo" é acionável; "quase bom" não é.

Se você não conseguiu verificar — a ferramenta não estava disponível, o ambiente não permitia — **diga isso explicitamente** em vez de omitir. "Não consegui tirar screenshot, então validei por medição no DOM" é honesto e informa a limitação. Silêncio no lugar disso vira afirmação falsa.

## Armadilha comum

Verificar uma vez e assumir que continua valendo. Se você mudou o CSS depois de medir o contraste, a medição anterior não vale mais. Meça de novo, ou não afirme.

Igualmente: verificar em uma largura e afirmar sobre todas. Um alvo de toque que passa em desktop pode falhar em mobile, porque a fonte encolhe — já aconteceu, com `padding` fixo que virava 42px quando a fonte diminuía. `min-height` resolveu; a medição em uma só largura teria deixado passar.

