FelipeStruchel/landing-page-skills

Utile quand Felipe demande de redessiner les skills de landing page, de réviser les apprentissages accumulés, de traiter les retours en attente, de mettre à jour le fichier _regras-vivas.md, d'effectuer la migration initiale des règles, ou lorsque l'étape 0 propose la migration. Ne pas utiliser pendant la construction d'un client.

Qu'est-ce que landing-page-skills ?

Ce skill a pour mission de transformer le feedback brut en règles vérifiées et testées, en suivant une approche rigoureuse de TDD (RED, GREEN, REFACTOR). Il force l'utilisateur à ne jamais créer ou modifier une règle sans preuve concrète (évidence) et sans un test préalable qui échoue. Il s'applique principalement aux projets de landing page, en particulier pour le repository `criar-landing-page` et son kit d'assets. Le workflow inclut le listage des retours, la recherche de patterns similaires dans d'autres clients, la classification par impact et généralisabilité, la création de règles avec des identifiants formels (R-nnn), la rédaction de scénarios de test (RED), l'édition de la règle (GREEN), puis le refactoring (REFACTOR). Une phase d'élagage obligatoire supprime les règles redondantes, et une validation par des scripts intégrés garantit l'intégrité. Le skill est conçu pour les sous-agents de Claude Code ou Codex qui travaillent sur l'évolution continue des skills, avec une option de migration initiale où toutes les entrées `processado: não` sont traitées pour générer une première version de `_regras-vivas.md`. Il repose sur le prérequis `superpowers:writing-skills` pour gérer les scénarios de pression avec sous-agent.

Compatible avec✓Claude Code~Codex CLI~Cursor

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

Documentation

Landing : faire évoluer les skills

Transforme le feedback brut en règle vérifiée. Une règle sans test devient un dogme. Violer la lettre, c'est violer l'esprit.

Loi de fer

AUCUNE RÈGLE SANS PREUVE ET PORTÉE.
AUCUNE ÉDITION DE SKILL SANS UN TEST QUI ÉCHOUE AVANT.

CONTEXTE REQUIS : superpowers:writing-skills (scénarios de pression avec sous-agent ; RED, GREEN, REFACTOR).

Fonction de porte

Lister : node kit/processar-feedback.js listar (kit = ~/.claude/skills/criar-landing-page/assets/kit). Groupez par portée et catégorie.
Parallèles : pour chaque leçon, cherchez la même chez d'autres clients (grep -n dans les 02 et les 05-aprendizados.md) et lisez les entrées. Une preuve defeito ou resultado-medido pèse plus qu'une preferencia. Une hypothèse ne compte pas.
Classer selon la matrice :

Situation	Destination
Répétée et généralisable	candidate à règle générale
Répétée, dépendante de l'environnement	règle avec balises (`aplica_quando`)
Rare, à fort impact (secret exposé)	règle de sécurité, même avec une occurrence
Subjective, sans confirmation	reste hypothèse
Sans bénéfice ou déjà couverte par un script	ne pas promouvoir

Nouvelle règle : id R-nnn, preuve réelle (cliente/E<nn>), portée, aplica_quando du vocabulaire fermé, nao_se_aplica_quando, critère de suppression, vérification (script du kit ou nenhuma) et skill responsable.
Si la règle modifie une skill : écrivez le scénario de pression dans _testes-skills/cenarios/, exécutez sans la modification (RED, enregistrez la rationalisation), éditez, exécutez avec (GREEN), comblez les brèches (REFACTOR). Sans RED, supprimez l'édition.
Élagage obligatoire : supprimez ou fusionnez les règles redondantes, dupliquées entre skills ou déjà couvertes par un script. Aucun redessin n'ajoute seulement. node _testes-skills/lint-skill.mjs <skill> avant et après (mots).
Valider : node kit/check-regras.js --file ~/projets/criar-site/_regras-vivas.md et le test de sélection par balises des clients fictifs.
Clôturer : node kit/processar-feedback.js marcar --versao v<N> ; enregistrer dans _evolucao.md : ce qui a changé, ce qui a été élagué et les métriques (approbations rouvertes, erreurs par catégorie, régressions, faux positifs, fois où Felipe a rappelé l'enregistrement).

Mode migration : même processus avec toutes les entrées processado: não, en partant des 05-aprendizados.md, en générant _regras-vivas.md v1 et _evolucao.md. Divisez le fichier en _regras-vivas/ seulement sur critère mesuré (taille, échec de récupération, catégorie avec volume).

Drapeaux rouges : arrêtez

« C'est arrivé une fois, ça devient une règle générale » (sauf sécurité)
« C'est évident, je saute le test » · preuve inventée ou sans E<nn> réel
Règle d'un client promue en globale · ajouter sans élaguer

Rationalisation	Réalité
« Felipe aime ça, donc c'est une règle »	Préférence sans confirmation reste hypothèse avec portée
« C'est juste une ligne dans la skill »	Édition sans RED est la même violation du TDD
« Deux occurrences suffisent »	La fréquence est une priorité, pas un critère : évaluez l'applicabilité et le risque
« Plus de règles, plus de sécurité »	Trop de règles deviennent du bruit ; élaguer fait partie du travail