FelipeStruchel/landing-page-skills

Use quando o Felipe pedir para redesenhar skills de landing page, revisar aprendizados acumulados, processar feedbacks pendentes, atualizar o _regras-vivas.md, fazer a migração inicial das regras, ou quando o Passo 0 oferecer a migração. Não use durante a construção de um cliente.

O que é landing-page-skills?

Esta skill transforma feedback bruto em regras verificadas para o desenvolvimento de landing pages, seguindo uma abordagem rigorosa baseada em evidências. Ela é essencial para manter a qualidade e a consistência das regras que guiam o agente de IA, evitando que preferências subjetivas ou incidentes isolados se tornem regras gerais. A skill suporta a coleta e classificação de feedbacks por escopo e categoria, a criação de regras com identificação única, evidências reais e critérios de aplicação, além de um ciclo de teste TDD (RED, GREEN, REFACTOR) para qualquer mudança em skills existentes. Sua utilidade principal está em evitar regras dogmáticas ("nenhuma regra sem evidência e escopo"), promover a poda de regras redundantes e garantir que toda alteração seja validada por testes que falham antes da edição. A skill opera em projetos de landing page que utilizam o kit de ferramentas localizado em `~/.claude/skills/criar-landing-page/assets/kit/` e inclui scripts para listar feedbacks, validar regras e registrar a evolução. Ela é indicada para desenvolvedores e usuários de agentes de IA (como Claude Code, Cursor) que precisam refinar as regras de comportamento do agente de forma metódica, com base em dados reais de múltiplos clientes. Exige conhecimento prévio da skill superpowers:writing-skills para entender cenários de pressão com subagentes.

Funciona com✓Claude Code~Codex CLI~Cursor

npx skills add https://github.com/FelipeStruchel/landing-page-skills/tree/HEAD/skills/landing-evoluir-skill

Documentação

Landing: evoluir as skills

Transforma feedback bruto em regra verificada. Regra sem teste vira dogma. Violar a letra é violar o espírito.

Iron Law

NENHUMA REGRA SEM EVIDÊNCIA E ESCOPO.
NENHUMA EDIÇÃO DE SKILL SEM UM TESTE QUE FALHA ANTES.

REQUIRED BACKGROUND: superpowers:writing-skills (cenários de pressão com subagente; RED, GREEN, REFACTOR).

Gate Function

Listar: node kit/processar-feedback.js listar (kit = ~/.claude/skills/criar-landing-page/assets/kit). Agrupe por escopo e categoria.
Paralelos: para cada lição, procure a mesma em outros clientes (grep -n nos 02 e nos 05-aprendizados.md) e leia as entradas. Evidência defeito ou resultado-medido pesa mais que preferencia. Hipótese não conta.
Classificar pela matriz:

Situação	Destino
Repetida e generalizável	candidata a regra geral
Repetida, dependente do ambiente	regra com tags (`aplica_quando`)
Rara, alto impacto (segredo exposto)	regra de segurança, mesmo com uma ocorrência
Subjetiva, sem confirmação	permanece hipótese
Sem benefício ou já coberta por script	não promover

Regra nova: id R-nnn, evidência real (cliente/E<nn>), escopo, aplica_quando do vocabulário fechado, nao_se_aplica_quando, critério de remoção, checagem (script do kit ou nenhuma) e skill responsável.
Se a regra muda uma skill: escreva o cenário de pressão em _testes-skills/cenarios/, rode sem a mudança (RED, registre a racionalização), edite, rode com (GREEN), feche as brechas (REFACTOR). Sem RED, apague a edição.
Poda obrigatória: remova ou funda regras redundantes, duplicadas entre skills ou cobertas por script. Nenhum redesenho só acrescenta. node _testes-skills/lint-skill.mjs <skill> antes e depois (palavras).
Validar: node kit/check-regras.js --file ~/projetos/criar-site/_regras-vivas.md e o teste de seleção por tags dos clientes fictícios.
Fechar: node kit/processar-feedback.js marcar --versao v<N>; registrar em _evolucao.md: o que mudou, o que foi podado e as métricas (aprovações reabertas, erros por categoria, regressões, falsos positivos, vezes em que o Felipe lembrou o registro).

Modo migração: mesmo processo com todas as entradas processado: não, partindo dos 05-aprendizados.md, gerando _regras-vivas.md v1 e _evolucao.md. Divida o arquivo em _regras-vivas/ só por critério medido (tamanho, falha de recuperação, categoria com volume).

Red Flags: pare

"Aconteceu uma vez, vira regra geral" (exceto segurança)
"É óbvio, pulo o teste" · evidência inventada ou sem E<nn> real
Regra de um cliente promovida a global · acrescentar sem podar

Racionalização	Realidade
"O Felipe gosta, então é regra"	Preferência sem confirmação fica como hipótese com escopo
"É só uma linha na skill"	Edição sem RED é a mesma violação do TDD
"Duas ocorrências bastam"	Frequência é prioridade, não critério: avalie aplicabilidade e risco
"Mais regras, mais segurança"	Regra demais vira ruído; podar é parte do trabalho