FelipeStruchel/landing-page-skills

Úsalo cuando Felipe pida rediseñar skills de landing page, revisar aprendizajes acumulados, procesar feedbacks pendientes, actualizar _regras-vivas.md, realizar la migración inicial de reglas, o cuando el Paso 0 ofrezca la migración. No usar durante la construcción de un cliente.

¿Qué es landing-page-skills?

Este skill está diseñado para evolucionar sistemáticamente las reglas de una landing page a partir de retroalimentación real. Convierte el feedback bruto en reglas verificadas, aplicando un riguroso proceso basado en evidencia y pruebas. Soporta plataformas como Claude Code y Cursor, y se fundamenta en un flujo TDD (RED, GREEN, REFACTOR) que garantiza que ninguna regla se introduzca sin un test que falle antes. El skill clasifica las lecciones según su repetibilidad e impacto, derivando reglas generales, reglas con condiciones de aplicación, o hipótesis sin confirmación. Incluye poda obligatoria de reglas redundantes, validación automatizada mediante scripts del kit, y un modo de migración para generar desde cero las reglas vivas y el historial de evolución. Su valor principal es evitar que las preferencias subjetivas o las ocurrencias aisladas se conviertan en dogma, manteniendo un conjunto de reglas eficiente y basado en datos.

Compatible con✓Claude Code~Codex CLI~Cursor

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

Documentación

Landing: evolucionar las skills

Transforma el feedback bruto en regla verificada. Regla sin test se convierte en dogma. Violar la letra es violar el espíritu.

Iron Law

NINGUNA REGLA SIN EVIDENCIA Y ALCANCE.
NINGUNA EDICIÓN DE SKILL SIN UN TEST QUE FALLE ANTES.

REQUIRED BACKGROUND: superpowers:writing-skills (escenarios de presión con subagente; RED, GREEN, REFACTOR).

Gate Function

Listar: node kit/processar-feedback.js listar (kit = ~/.claude/skills/criar-landing-page/assets/kit). Agrupa por alcance y categoría.
Paralelos: para cada lección, busca la misma en otros clientes (grep -n en los 02 y en los 05-aprendizados.md) y lee las entradas. La evidencia defecto o resultado-medido pesa más que preferencia. La hipótesis no cuenta.
Clasificar según la matriz:

Situación	Destino
Repetida y generalizable	candidata a regla general
Repetida, dependiente del entorno	regla con etiquetas (`aplica_quando`)
Rara, alto impacto (secreto expuesto)	regla de seguridad, incluso con una ocurrencia
Subjetiva, sin confirmación	permanece como hipótesis
Sin beneficio o ya cubierta por script	no promover

Regla nueva: id R-nnn, evidencia real (cliente/E<nn>), alcance, aplica_quando del vocabulario cerrado, nao_se_aplica_quando, criterio de eliminación, verificación (script del kit o ninguna) y skill responsable.
Si la regla modifica una skill: escribe el escenario de presión en _testes-skills/cenarios/, ejecuta sin el cambio (RED, registra la racionalización), edita, ejecuta con (GREEN), cierra las brechas (REFACTOR). Sin RED, borra la edición.
Poda obligatoria: elimina o fusiona reglas redundantes, duplicadas entre skills o cubiertas por script. Ningún rediseño solo añade. node _testes-skills/lint-skill.mjs <skill> antes y después (palabras).
Validar: node kit/check-regras.js --file ~/projetos/criar-site/_regras-vivas.md y la prueba de selección por etiquetas de los clientes ficticios.
Cerrar: node kit/processar-feedback.js marcar --versao v<N>; registrar en _evolucao.md: qué cambió, qué se podó y las métricas (aprobaciones reabiertas, errores por categoría, regresiones, falsos positivos, veces que Felipe recordó el registro).

Modo migración: el mismo proceso con todas las entradas processado: não, comenzando por los 05-aprendizados.md, generando _regras-vivas.md v1 y _evolucao.md. Divide el archivo en _regras-vivas/ solo por criterio medido (tamaño, fallo de recuperación, categoría con volumen).

Red Flags: para

"Ocurrió una vez, se convierte en regla general" (excepto seguridad)
"Es obvio, me salto el test" · evidencia inventada o sin E<nn> real
Regla de un cliente promovida a global · añadir sin podar

Racionalización	Realidad
"A Felipe le gusta, entonces es regla"	Preferencia sin confirmación queda como hipótesis con alcance
"Es solo una línea en la skill"	Edición sin RED es la misma violación del TDD
"Dos ocurrencias bastan"	La frecuencia es prioridad, no criterio: evalúa aplicabilidad y riesgo
"Más reglas, más seguridad"	Demasiadas reglas se convierten en ruido; podar es parte del trabajo