wizz-method 2.2.0 → 2.3.1

package/src/skills-lib/security-audit-pentest/references/stage-1-validacao-entrada.md

@@ -1,50 +1,50 @@
-# Estágio 1 — Validação de entrada
+# Stage 1 — Input validation
 
-Você é um analista de validação de entrada.
+You are an input validation analyst.
 
-Premissa: validação no cliente não conta. Um atacante fala
-direto com a API. Considere apenas verificação no servidor.
+Premise: client-side validation doesn't count. An attacker talks
+directly to the API. Consider only server-side verification.
 
-Procure, nesta ordem de prioridade:
+Look for, in this priority order:
 
-1. ATRIBUIÇÃO EM MASSA — prioridade máxima
-   Todo endpoint de escrita onde o corpo da requisição é
-   repassado inteiro para o banco (spread do objeto, update
-   com o payload completo, create com todos os campos).
-   Para cada um: liste os campos da tabela que um atacante
-   conseguiria setar e que não estão no formulário.
-   Dê atenção especial a campos de papel, permissão, plano,
-   saldo, status de pagamento e id de dono.
+1. MASS ASSIGNMENT — top priority
+   Every write endpoint where the request body is
+   passed through wholesale to the database (object spread, update
+   with the full payload, create with all fields).
+   For each one: list the table fields an attacker
+   could set that aren't in the form.
+   Pay special attention to role, permission, plan,
+   balance, payment status and owner id fields.
 
-2. INJEÇÃO
-   Consultas montadas por concatenação ou template string
-   com valor vindo do usuário. Inclua SQL, NoSQL e comandos
-   de shell.
+2. INJECTION
+   Queries built by concatenation or template string
+   with a value coming from the user. Include SQL, NoSQL and
+   shell commands.
 
-3. RENDERIZAÇÃO INSEGURA
-   Conteúdo de usuário chegando em innerHTML,
-   dangerouslySetInnerHTML, v-html ou equivalente
-   sem sanitização no caminho.
+3. UNSAFE RENDERING
+   User content reaching innerHTML,
+   dangerouslySetInnerHTML, v-html or equivalent
+   with no sanitization along the way.
 
-4. SCHEMA AUSENTE
-   Endpoints sem validação de tipo, formato ou tamanho.
-   Sinalize campos de texto sem limite máximo — são vetor
-   de exaustão de recurso.
+4. MISSING SCHEMA
+   Endpoints with no type, format or size validation.
+   Flag text fields with no max length — they're a
+   resource-exhaustion vector.
 
-Para cada achado, o campo "Como se explora" deve conter
-o payload concreto que um atacante enviaria, não a categoria
-da vulnerabilidade.
+For every finding, the "How it's exploited" field must contain
+the concrete payload an attacker would send, not the vulnerability
+category.
 
-Formato de saída — tabela markdown, sem texto antes ou depois:
+Output format — markdown table, no text before or after:
 
-| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
+| # | Risk | Where (file:line) | How it's exploited | What prevents it | Severity |
 
-Gravidade: CRÍTICO, ALTO, MÉDIO.
+Severity: CRITICAL, HIGH, MEDIUM.
 
-REGRA DE CORTE: se você não conseguir preencher "Como se explora"
-com uma ação concreta e específica, NÃO inclua a linha.
-"Poderia ser melhor" não é achado. "Considere adicionar" não é achado.
-Prefiro dez linhas reais a cinquenta linhas de boa prática.
+CUTOFF RULE: if you can't fill in "How it's exploited"
+with a concrete, specific action, DON'T include the row.
+"Could be better" is not a finding. "Consider adding" is not a finding.
+Ten real rows beat fifty rows of best practices.
 
-Se não houver nenhum achado que passe nessa régua, responda
-apenas: NENHUM ACHADO NESTA ETAPA.
+If there's no finding that passes this ruler, answer
+only: NO FINDINGS AT THIS STAGE.

package/src/skills-lib/security-audit-pentest/references/stage-2-autorizacao.md

@@ -1,61 +1,61 @@
-# Estágio 2 — Falha de autorização
-
-Você é um pentester especializado em falha de autorização.
-
-Distinção que governa toda essa análise:
-AUTENTICAÇÃO responde "quem é você". AUTORIZAÇÃO responde
-"você pode acessar ISSO". Estar logado não é permissão.
-
-Analise as três camadas.
-
-CAMADA 1 — APLICAÇÃO
-Para cada endpoint que lê ou escreve um recurso pertencente
-a um usuário, responda:
-  a) De onde vem a identidade de QUEM está pedindo?
-     Do token/sessão no servidor, ou de algo enviado pelo cliente
-     (body, query, header, param)?
-  b) A consulta ao banco amarra o id do recurso E o dono
-     na mesma condição?
-Marque CRÍTICO todo lugar onde um user_id, org_id, tenant_id
-ou equivalente é lido do que o cliente enviou e usado para
-determinar propriedade.
-
-CAMADA 2 — BANCO
-Leia os arquivos de migration, schema e policy.
-  a) Liste as tabelas e diga, para cada uma, se há RLS
-     habilitada nos arquivos versionados.
-  b) Marque CRÍTICO toda policy permissiva —
-     USING (true), WITH CHECK (true) ou equivalente.
-     Uma policy permissiva é PIOR que policy nenhuma,
-     porque o painel mostra a trava como ativa.
-  c) Sinalize qualquer tabela criada em migration recente
-     que não tenha policy correspondente.
-
-CAMADA 3 — MÁQUINA
-Para cada webhook e endpoint que recebe evento externo:
-  a) Há validação de assinatura ou token compartilhado?
-  b) O fluxo confia em valor de status, dinheiro ou permissão
-     vindo no corpo, sem confirmar com o provedor de origem?
-
-LIMITE DA SUA ANÁLISE — obrigatório:
-Você está lendo arquivos. RLS de verdade é estado do banco,
-não arquivo. Termine com uma seção "NÃO VERIFICÁVEL AQUI"
-listando tudo que precisa ser confirmado no banco ao vivo
-ou no painel do provedor. Não afirme que está seguro
-o que você não conseguiu ver.
-
-Formato de saída — tabela markdown, sem texto antes ou depois:
-
-| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
-
-Gravidade: CRÍTICO, ALTO, MÉDIO.
-
-REGRA DE CORTE: se você não conseguir preencher "Como se explora"
-com uma ação concreta e específica, NÃO inclua a linha.
-"Poderia ser melhor" não é achado. "Considere adicionar" não é achado.
-Prefiro dez linhas reais a cinquenta linhas de boa prática.
-
-Se não houver nenhum achado que passe nessa régua, responda
-apenas: NENHUM ACHADO NESTA ETAPA.
-
-(Após a tabela, inclua a seção obrigatória "NÃO VERIFICÁVEL AQUI".)
+# Stage 2 — Authorization failure
+
+You are a pentester specialized in authorization failures.
+
+The distinction that governs this whole analysis:
+AUTHENTICATION answers "who are you". AUTHORIZATION answers
+"can you access THIS". Being logged in is not permission.
+
+Analyze the three layers.
+
+LAYER 1 — APPLICATION
+For every endpoint that reads or writes a resource belonging
+to a user, answer:
+  a) Where does the identity of WHO is asking come from?
+     From the server-side token/session, or from something sent by
+     the client (body, query, header, param)?
+  b) Does the database query tie the resource id AND the owner
+     into the same condition?
+Mark CRITICAL every place where a user_id, org_id, tenant_id
+or equivalent is read from what the client sent and used to
+determine ownership.
+
+LAYER 2 — DATABASE
+Read the migration, schema and policy files.
+  a) List the tables and state, for each one, whether RLS
+     is enabled in the versioned files.
+  b) Mark CRITICAL every permissive policy —
+     USING (true), WITH CHECK (true) or equivalent.
+     A permissive policy is WORSE than no policy at all,
+     because the dashboard shows the lock as active.
+  c) Flag any table created in a recent migration
+     that has no matching policy.
+
+LAYER 3 — MACHINE
+For every webhook and endpoint that receives an external event:
+  a) Is there signature validation or a shared token?
+  b) Does the flow trust a status, money or permission value
+     coming in the body, without confirming with the source provider?
+
+LIMIT OF YOUR ANALYSIS — mandatory:
+You are reading files. Real RLS is database state,
+not a file. End with a "NOT VERIFIABLE HERE" section
+listing everything that needs to be confirmed against the live database
+or the provider's dashboard. Don't claim something is secure
+if you couldn't actually see it.
+
+Output format — markdown table, no text before or after:
+
+| # | Risk | Where (file:line) | How it's exploited | What prevents it | Severity |
+
+Severity: CRITICAL, HIGH, MEDIUM.
+
+CUTOFF RULE: if you can't fill in "How it's exploited"
+with a concrete, specific action, DON'T include the row.
+"Could be better" is not a finding. "Consider adding" is not a finding.
+Ten real rows beat fifty rows of best practices.
+
+If there's no finding that passes this ruler, answer
+only: NO FINDINGS AT THIS STAGE.
+
+(After the table, include the mandatory "NOT VERIFIABLE HERE" section.)

package/src/skills-lib/security-audit-pentest/references/stage-3-abuso-volume.md

@@ -1,49 +1,49 @@
-# Estágio 3 — Abuso por volume
+# Stage 3 — Volume abuse
 
-Você é um analista de abuso por volume.
+You are a volume-abuse analyst.
 
-Enumere TODA rota de entrada do sistema e classifique cada uma:
-TEM LIMITADOR / NÃO TEM LIMITADOR / NÃO DETERMINADO.
+Enumerate EVERY entry route in the system and classify each one:
+HAS A LIMITER / HAS NO LIMITER / UNDETERMINED.
 
-Depois, marque as rotas nestas categorias:
+Then, flag the routes in these categories:
 
-A) AUTENTICAÇÃO
-   Login, cadastro, recuperação de senha, verificação de código.
-   Sem limitador aqui significa força bruta e teste de
-   credenciais vazadas. Marque CRÍTICO.
-   Verifique também: o limitador conta por IP apenas, ou também
-   por conta alvo? Contagem só por IP é contornada distribuindo
-   o ataque.
+A) AUTHENTICATION
+   Login, signup, password recovery, code verification.
+   No limiter here means brute force and testing of
+   leaked credentials. Mark CRITICAL.
+   Also check: does the limiter count by IP only, or also
+   by target account? Counting by IP only is bypassed by
+   distributing the attack.
 
-B) CUSTO POR CHAMADA
-   Rotas que gastam dinheiro real a cada execução:
-   chamada a modelo de linguagem, disparo de SMS, envio de e-mail,
-   processamento de arquivo, chamada a API paga de terceiro.
-   Para cada uma estime o custo unitário e o custo de
-   dez mil chamadas em loop.
-   Rota de agente de IA exposta sem limitador é CRÍTICO,
-   mesmo que não vaze nenhum dado.
+B) COST PER CALL
+   Routes that spend real money on every execution:
+   language model call, SMS dispatch, email send,
+   file processing, paid third-party API call.
+   For each one, estimate the unit cost and the cost of
+   ten thousand calls in a loop.
+   An AI agent route exposed with no limiter is CRITICAL,
+   even if it leaks no data at all.
 
-C) EXTRAÇÃO
-   Rotas que devolvem um registro por vez e que, chamadas em
-   sequência, entregam a base inteira.
+C) EXTRACTION
+   Routes that return one record at a time and that, called in
+   sequence, hand over the entire database.
 
-D) ORIGEM DO IP
-   Se o sistema roda atrás de proxy ou CDN, verifique de qual
-   cabeçalho o IP do cliente é lido. Se estiver lendo do
-   socket direto, o mundo inteiro conta como um IP só
-   e o limitador não existe na prática.
+D) IP ORIGIN
+   If the system runs behind a proxy or CDN, check which
+   header the client IP is read from. If it's reading straight
+   from the socket, the entire world counts as a single IP
+   and the limiter doesn't exist in practice.
 
-Formato de saída — tabela markdown, sem texto antes ou depois:
+Output format — markdown table, no text before or after:
 
-| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
+| # | Risk | Where (file:line) | How it's exploited | What prevents it | Severity |
 
-Gravidade: CRÍTICO, ALTO, MÉDIO.
+Severity: CRITICAL, HIGH, MEDIUM.
 
-REGRA DE CORTE: se você não conseguir preencher "Como se explora"
-com uma ação concreta e específica, NÃO inclua a linha.
-"Poderia ser melhor" não é achado. "Considere adicionar" não é achado.
-Prefiro dez linhas reais a cinquenta linhas de boa prática.
+CUTOFF RULE: if you can't fill in "How it's exploited"
+with a concrete, specific action, DON'T include the row.
+"Could be better" is not a finding. "Consider adding" is not a finding.
+Ten real rows beat fifty rows of best practices.
 
-Se não houver nenhum achado que passe nessa régua, responda
-apenas: NENHUM ACHADO NESTA ETAPA.
+If there's no finding that passes this ruler, answer
+only: NO FINDINGS AT THIS STAGE.

package/src/skills-lib/security-audit-pentest/references/stage-4-vazamento-resposta.md

@@ -1,52 +1,52 @@
-# Estágio 4 — Vazamento por resposta
-
-Você é um analista de vazamento por resposta.
-
-Premissa: toda resposta de erro é informação. Você está
-procurando o que o sistema conta a quem falhou.
-
-1. DETALHE TÉCNICO EM PRODUÇÃO
-   Stack trace, caminho de arquivo do servidor, nome e versão
-   de framework ou biblioteca, fragmento de consulta SQL,
-   nome de tabela ou coluna chegando na resposta ao cliente.
-   Confirme se existe separação real entre comportamento de
-   desenvolvimento e de produção, ou se é o mesmo caminho.
-
-2. DIVERGÊNCIA NA AUTENTICAÇÃO — prioridade máxima
-   Compare as respostas de: e-mail inexistente, e-mail existente
-   com senha errada, e conta bloqueada.
-   Divergem em mensagem? Em código de status? Em campo do corpo?
-   E divergem em TEMPO de resposta, porque o caminho do e-mail
-   existente executa a verificação de hash e o outro não?
-   Qualquer divergência transforma o login numa API de consulta
-   da base de clientes. Marque CRÍTICO.
-   O mesmo vale para cadastro ("e-mail já em uso") e recuperação
-   de senha.
-
-3. EXISTÊNCIA DE RECURSO
-   Quando o usuário pede um recurso que existe mas não é dele,
-   a resposta é diferente de quando o recurso não existe?
-   Se for, dá para mapear os ids válidos contando respostas.
-   O correto é responder "não encontrado" nos dois casos.
-
-4. LOG
-   Senha, token, cabeçalho de autorização, dado de cartão ou
-   documento sendo gravado em log.
-
-Para cada achado, o campo "Como se explora" deve conter
-o payload concreto que um atacante enviaria, não a categoria
-da vulnerabilidade.
-
-Formato de saída — tabela markdown, sem texto antes ou depois:
-
-| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
-
-Gravidade: CRÍTICO, ALTO, MÉDIO.
-
-REGRA DE CORTE: se você não conseguir preencher "Como se explora"
-com uma ação concreta e específica, NÃO inclua a linha.
-"Poderia ser melhor" não é achado. "Considere adicionar" não é achado.
-Prefiro dez linhas reais a cinquenta linhas de boa prática.
-
-Se não houver nenhum achado que passe nessa régua, responda
-apenas: NENHUM ACHADO NESTA ETAPA.
+# Stage 4 — Response leakage
+
+You are a response-leakage analyst.
+
+Premise: every error response is information. You're
+looking for what the system tells whoever failed.
+
+1. TECHNICAL DETAIL IN PRODUCTION
+   Stack trace, server file path, framework or library
+   name and version, SQL query fragment, table or column
+   name reaching the response sent to the client.
+   Confirm whether there's real separation between development
+   and production behavior, or whether it's the same code path.
+
+2. AUTHENTICATION DIVERGENCE — top priority
+   Compare the responses for: nonexistent email, existing
+   email with wrong password, and locked account.
+   Do they diverge in message? In status code? In a body field?
+   And do they diverge in response TIME, because the path for an
+   existing email runs the hash check and the other doesn't?
+   Any divergence turns login into a customer-database
+   query API. Mark CRITICAL.
+   The same applies to signup ("email already in use") and password
+   recovery.
+
+3. RESOURCE EXISTENCE
+   When the user requests a resource that exists but isn't theirs,
+   is the response different from when the resource doesn't exist at all?
+   If so, the valid ids can be mapped by counting responses.
+   The correct behavior is to answer "not found" in both cases.
+
+4. LOGGING
+   Password, token, authorization header, card data or
+   document being written to a log.
+
+For every finding, the "How it's exploited" field must contain
+the concrete payload an attacker would send, not the vulnerability
+category.
+
+Output format — markdown table, no text before or after:
+
+| # | Risk | Where (file:line) | How it's exploited | What prevents it | Severity |
+
+Severity: CRITICAL, HIGH, MEDIUM.
+
+CUTOFF RULE: if you can't fill in "How it's exploited"
+with a concrete, specific action, DON'T include the row.
+"Could be better" is not a finding. "Consider adding" is not a finding.
+Ten real rows beat fifty rows of best practices.
+
+If there's no finding that passes this ruler, answer
+only: NO FINDINGS AT THIS STAGE.

package/src/skills-lib/site-launch-kit/SKILL.md

@@ -1,52 +1,52 @@
 ---
 name: site-launch-kit
-description: "Checklist operacional de pré-lançamento de site em 15 rodadas corretivas: CTA principal acima da dobra, barra fixa mobile, promessa de tempo de resposta, prova social real, FAQ de decisão com FAQPage, imagens reais (não stock), endereço e como chegar, titles únicos, Open Graph, breadcrumbs, alt text, schema do negócio local, robots/sitemap, privacidade e termos LGPD, medição de eventos. Use quando o site estiver pronto ou quase pronto pra ir ao ar: 'vamos lançar', 'subir o site', 'revisar antes do deploy', 'checklist de lançamento', 'pré-go-live', 'o site tá pronto?', ou quando o pedido for um dos itens isolados (ex: 'arruma a prévia do WhatsApp', 'coloca FAQ com schema', 'confere robots.txt antes de subir'). Roda DEPOIS do site construído e ANTES do deploy. Regra central: nenhum dado de negócio inventado entra no site; o que faltar vira placeholder e entra em PENDÊNCIAS."
+description: "Operational pre-launch website checklist in 15 corrective rounds: main CTA above the fold, mobile sticky bar, response-time promise, real social proof, decision-focused FAQ with FAQPage, real images (not stock), address and directions, unique titles, Open Graph, breadcrumbs, alt text, local business schema, robots/sitemap, LGPD privacy policy and terms, event measurement. Use when the site is ready or nearly ready to go live: 'vamos lançar', 'subir o site', 'revisar antes do deploy', 'checklist de lançamento', 'pré-go-live', 'o site tá pronto?', or when the request is one of the individual items (e.g. 'arruma a prévia do WhatsApp', 'coloca FAQ com schema', 'confere robots.txt antes de subir'). Runs AFTER the site is built and BEFORE deploy. Central rule: no invented business data goes into the site; whatever is missing becomes a placeholder and goes into PENDING ITEMS."
 ---
 
-# Site Launch Kit · Revisão de Pré-Lançamento
+# Site Launch Kit · Pre-Launch Review
 
-15 rodadas corretivas para rodar **depois que o site está construído e antes do deploy**. Cada rodada é um passe fechado: escopo único, saída padronizada, regra de corte própria. Não é skill de construção de página (isso é `wizz-premium-landing-ui-researcher` / `wizz-taste-skill`) nem de diagnóstico amplo de SEO (isso é `wizz-seo-audit`): aqui é conserto pontual pré-go-live.
+15 corrective rounds to run **after the site is built and before deploy**. Each round is a closed pass: single scope, standardized output, its own cutoff rule. This is not a page-building skill (that's `wizz-premium-landing-ui-researcher` / `wizz-taste-skill`) nor a broad SEO diagnostic (that's `wizz-seo-audit`): this is targeted pre-go-live fixing.
 
-## Contrato comum (vale para TODAS as rodadas)
+## Common contract (applies to ALL rounds)
 
-1. **Detecte o terreno lendo o repositório**, não perguntando: framework, roteamento, onde moram as páginas públicas, onde ficam metadados e estilos.
-2. **Nenhum dado de negócio inventado entra no site**: preço, prazo, telefone, endereço, depoimento, nota, horário, CNPJ, domínio. O que faltar vira placeholder explícito (`{{ASSIM}}`) e entra em PENDÊNCIAS. Nunca preencha por estimativa.
-3. **Saída padronizada**: tabela markdown definida na rodada (sem texto antes dela) + seção **PENDÊNCIAS** no formato "o que falta · onde entra / de quem obter · como obter / o que destrava". Sem pendências, escreva "NENHUMA PENDÊNCIA".
-4. **Respeite a REGRA DE CORTE** de cada rodada: ela decide o empate entre "entregar bonito" e "entregar honesto". Honesto ganha sempre.
-5. **Rodadas condicionais** (07 endereço, 10 breadcrumbs): primeiro verifique se o item se aplica; se não, responda "ITEM NÃO SE APLICA" com uma linha de justificativa e pare.
-6. **Uma rodada por vez.** Não misture escopos no mesmo passe.
+1. **Detect the terrain by reading the repository**, not by asking: framework, routing, where public pages live, where metadata and styles live.
+2. **No invented business data goes into the site**: price, timeframe, phone, address, testimonial, rating, hours, tax ID (CNPJ), domain. Whatever is missing becomes an explicit placeholder (`{{LIKE_THIS}}`) and goes into PENDING ITEMS. Never fill it in by guesswork.
+3. **Standardized output**: the markdown table defined in the round (with no text before it) + a **PENDING ITEMS** section in the format "what's missing · where it goes / who to get it from · how to get it / what it unblocks". With no pending items, write "NO PENDING ITEMS".
+4. **Follow the CUTOFF RULE** of each round: it decides the tie between "deliver something pretty" and "deliver something honest." Honest always wins.
+5. **Conditional rounds** (07 address, 10 breadcrumbs): first check whether the item applies; if not, answer "ITEM DOES NOT APPLY" with one line of justification and stop.
+6. **One round at a time.** Don't mix scopes in the same pass.
 
-## As 15 rodadas (ordem recomendada)
+## The 15 rounds (recommended order)
 
-| # | Rodada | Arquivo |
+| # | Round | File |
 |---|---|---|
-| 01 | CTA principal acima da dobra | [references/01-cta-principal.md](references/01-cta-principal.md) |
-| 02 | Barra de ação fixa no mobile | [references/02-barra-fixa-mobile.md](references/02-barra-fixa-mobile.md) |
-| 03 | Promessa de tempo de resposta | [references/03-tempo-de-resposta.md](references/03-tempo-de-resposta.md) |
-| 04 | Prova social real | [references/04-prova-social.md](references/04-prova-social.md) |
-| 05 | FAQ de decisão + FAQPage | [references/05-faq-decisao.md](references/05-faq-decisao.md) |
-| 06 | Imagens reais, não stock | [references/06-imagens-reais.md](references/06-imagens-reais.md) |
-| 07 | Endereço e como chegar | [references/07-endereco-como-chegar.md](references/07-endereco-como-chegar.md) |
-| 08 | Title próprio por página | [references/08-titles.md](references/08-titles.md) |
-| 09 | Prévia de link (Open Graph) | [references/09-open-graph.md](references/09-open-graph.md) |
-| 10 | Trilha de navegação (breadcrumbs) | [references/10-breadcrumbs.md](references/10-breadcrumbs.md) |
-| 11 | Texto alternativo correto | [references/11-alt-text.md](references/11-alt-text.md) |
-| 12 | Dados estruturados do negócio | [references/12-schema-local.md](references/12-schema-local.md) |
-| 13 | robots.txt e sitemap | [references/13-robots-sitemap.md](references/13-robots-sitemap.md) |
-| 14 | Privacidade e termos (LGPD) | [references/14-privacidade-termos.md](references/14-privacidade-termos.md) |
-| 15 | Medição de lançamento | [references/15-medicao.md](references/15-medicao.md) |
-
-**Dependências entre rodadas:** a 12 (schema) usa a mesma fonte de dados da 07 (endereço) e só inclui `aggregateRating` se a 04 (prova social) tiver deixado avaliação real no ar; a 02 (barra fixa) reaproveita o rótulo definido na 01 (CTA); a 15 (medição) marca a página de obrigado que a 03 (tempo de resposta) também toca. Rodando fora de ordem, leia antes a rodada da qual a atual depende.
-
-## Como executar
-
-- **Pedido genérico** ("revisa o site antes de subir", "checklist de lançamento"): rode na ordem 01→15, uma rodada por vez, entregando a tabela + PENDÊNCIAS de cada uma antes de abrir a próxima. Ao final, consolide todas as PENDÊNCIAS em uma lista única para o dono do site.
-- **Pedido pontual** ("arruma o og:image", "coloca FAQ"): rode só a rodada correspondente, com o mesmo contrato.
-- **Prioridade quando o tempo é curto:** 13 (robots/sitemap: o achado mais caro), 01 (CTA), 09 (Open Graph), 14 (LGPD), 15 (medição).
-
-## O que esta skill NÃO faz
-
-- Não redesenha layout, paleta ou conteúdo de seções (use `wizz-taste-skill` / `wizz-impeccable`).
-- Não cria a página do zero (use `wizz-premium-landing-ui-researcher`).
-- Não faz diagnóstico amplo de ranking/tráfego (use `wizz-seo-audit`).
-- Não escreve copy de venda nova (use `wizz-copywriting`); aqui só se ajusta rótulo e microcopy de atrito com material que já existe no site.
+| 01 | Main CTA above the fold | [references/01-cta-principal.md](references/01-cta-principal.md) |
+| 02 | Sticky mobile action bar | [references/02-barra-fixa-mobile.md](references/02-barra-fixa-mobile.md) |
+| 03 | Response-time promise | [references/03-tempo-de-resposta.md](references/03-tempo-de-resposta.md) |
+| 04 | Real social proof | [references/04-prova-social.md](references/04-prova-social.md) |
+| 05 | Decision-focused FAQ + FAQPage | [references/05-faq-decisao.md](references/05-faq-decisao.md) |
+| 06 | Real images, not stock | [references/06-imagens-reais.md](references/06-imagens-reais.md) |
+| 07 | Address and directions | [references/07-endereco-como-chegar.md](references/07-endereco-como-chegar.md) |
+| 08 | Unique title per page | [references/08-titles.md](references/08-titles.md) |
+| 09 | Link preview (Open Graph) | [references/09-open-graph.md](references/09-open-graph.md) |
+| 10 | Breadcrumb trail | [references/10-breadcrumbs.md](references/10-breadcrumbs.md) |
+| 11 | Correct alt text | [references/11-alt-text.md](references/11-alt-text.md) |
+| 12 | Business structured data | [references/12-schema-local.md](references/12-schema-local.md) |
+| 13 | robots.txt and sitemap | [references/13-robots-sitemap.md](references/13-robots-sitemap.md) |
+| 14 | Privacy policy and terms (LGPD) | [references/14-privacidade-termos.md](references/14-privacidade-termos.md) |
+| 15 | Launch measurement | [references/15-medicao.md](references/15-medicao.md) |
+
+**Dependencies between rounds:** round 12 (schema) uses the same data source as round 07 (address) and only includes `aggregateRating` if round 04 (social proof) has a real review live; round 02 (sticky bar) reuses the label defined in round 01 (CTA); round 15 (measurement) flags the thank-you page that round 03 (response time) also touches. When running out of order, read the round the current one depends on first.
+
+## How to run it
+
+- **Generic request** ("review the site before it goes live", "launch checklist"): run in order 01→15, one round at a time, delivering the table + PENDING ITEMS for each before opening the next. At the end, consolidate all PENDING ITEMS into a single list for the site owner.
+- **Targeted request** ("fix the og:image", "add an FAQ"): run just the matching round, with the same contract.
+- **Priority when time is short:** 13 (robots/sitemap: the most expensive finding), 01 (CTA), 09 (Open Graph), 14 (LGPD), 15 (measurement).
+
+## What this skill does NOT do
+
+- Doesn't redesign layout, palette, or section content (use `wizz-taste-skill` / `wizz-impeccable`).
+- Doesn't build the page from scratch (use `wizz-premium-landing-ui-researcher`).
+- Doesn't do a broad ranking/traffic diagnostic (use `wizz-seo-audit`).
+- Doesn't write new sales copy (use `wizz-copywriting`); here it only adjusts labels and friction microcopy using material that already exists on the site.