Les 13 pieges a eviter
13 anti-patterns compiles depuis l'analyse de 10 skills existants, avec table de rationalisation.
Ces 13 anti-patterns sont compiles a partir de l'analyse de 10 skills existants. Chacun est un piege reel, observe en production.
Les 13 anti-patterns
| # | Anti-pattern | Pourquoi c'est un probleme | Fix |
|---|---|---|---|
| 1 | Description qui leak le workflow | L'agent saute le body et produit un resultat generique | Description = triggers seulement |
| 2 | SKILL.md de plus de 500 lignes | Noie le contexte, l'agent oublie des instructions | Debordement dans references/ |
| 3 | Auto-evaluation (pas de grader independant) | Biais de confirmation, le createur ne trouve pas ses propres erreurs | Grader = agent different |
| 4 | 1 seul run de test | Bruit, pas signal. Le resultat peut etre un coup de chance | Minimum 3 runs, calculer mean +/- stddev |
| 5 | Pas de baseline without-skill | Impossible de mesurer la valeur ajoutee | Toujours tester AVEC et SANS le skill |
| 6 | Merge A+B sans tester la combinaison | Les 2 versions marchent seules mais pas ensemble | Tester la version mergee avant de commit |
| 7 | ALWAYS/NEVER en caps sans expliquer le WHY | L'agent obeit mecaniquement sans comprendre | Expliquer la raison derriere chaque regle |
| 8 | Overfitter aux test cases | Le skill marche sur les tests mais pas en conditions reelles | Generaliser : le feedback est un signal, pas une commande |
| 9 | Placeholder code, TODO, stubs | Le skill est inacheve mais deploye comme complet | Zero TODO. Si c'est pas fini, c'est pas publie |
| 10 | Narrative storytelling au lieu de patterns | L'agent lit une histoire mais ne sait pas quoi faire | Patterns actionnables : quand/quoi/comment |
| 11 | Recommander un skill sans verifier qualite | Le skill recommande peut etre casse ou obsolete | Verifier stars, usage, date de derniere update |
| 12 | Critic trop genereux (scorer 8 quand c'est 6) | Le skill passe le gate alors qu'il a de vrais problemes | Scorer honnetement. 7 = problemes reels |
| 13 | Pas de versioning | Modifier sans trace, impossible de rollback | Semver des le jour 1, changelog a chaque modification |
Table de rationalisation
Tu reconnais ces pensees ? Chacune est un signal d'alerte.
| Tu penses ca | La realite |
|---|---|
| "C'est trop simple pour tester" | Les skills simples cassent. 3 runs prennent 30 secondes. |
| "Je sais que c'est bon" | Tu ne sais pas. Le test prouve. |
| "Le user est presse" | Utilise le FAST PATH (5 min). Ca inclut la validation. |
| "La validation est overkill" | Les scripts attrapent ce que tu rates. 5 secondes a lancer. |
| "La description est fine" | La description est le premier point de defaillance. Toujours verifier. |
| "Je vais ajouter les tests plus tard" | Plus tard = jamais. RED avant GREEN. |
La pression ne justifie jamais de skipper
Le FAST PATH prend 5 minutes et inclut la validation. Si tu n'as pas 5 minutes, tu ne devrais pas publier un skill.
Les 3 erreurs les plus frequentes
1. Description qui leak le workflow (anti-pattern 1)
Le probleme le plus courant. L'agent lit la description, produit un output generique, et ne consulte jamais le body du skill.
Test : demande a un agent de faire la tache en lisant uniquement la description. Si le resultat est acceptable, la description leak.
2. Pas de baseline (anti-pattern 5)
Sans baseline, tu ne peux pas prouver que le skill ajoute de la valeur. La comparaison AVEC/SANS est le seul moyen de mesurer l'impact.
3. Critic trop genereux (anti-pattern 12)
Un score de 7/10 signifie que des problemes reels existent. Un Critic qui score 8 quand la realite est a 6 laisse passer des skills defectueux.
Lecture liee
- Tester un skill -- le cycle TDD qui detecte ces erreurs
- Iterer avec 3 agents -- la boucle qui corrige ces erreurs
- Lifecycle complet -- le cadre complet qui previent ces erreurs