@neikyun/ciel 6.11.2 → 6.13.0

package/assets/skills/appsec/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: appsec
+description: "Application Security — OWASP Top 10, defense in depth, auth (OAuth2/OIDC), input validation, session security. À charger quand on sécurise une application."
+---
+
+# Application Security
+
+**Principe premier :** La sécurité applicative n'est pas une feature — c'est une propriété émergente d'un système où chaque couche suppose que celle d'avant a échoué. Si ton input validation compte sur le WAF, et que ton WAF compte sur le framework, personne ne valide vraiment. La défense en profondeur n'est pas "plusieurs couches" — c'est "chaque couche traite l'input comme hostile, même si une autre couche est censée l'avoir déjà nettoyé". Assume breach à chaque étage.
+
+## Checklist
+- [ ] Toutes les entrées utilisateur sont validées à la frontière — type, longueur, charset, range
+- [ ] Requêtes SQL/NoSQL paramétrées — jamais de concaténation (injection)
+- [ ] Authentification via OAuth2/OIDC avec providers éprouvés — pas d'auth maison
+- [ ] Sessions : HttpOnly, Secure, SameSite=Lax, rotation d'ID après login
+- [ ] CSRF protégé sur toutes les mutations (SameSite + token si nécessaire)
+- [ ] Rate limiting sur TOUS les endpoints sensibles (login, API, upload, reset password)
+- [ ] Headers de sécurité : CSP, HSTS, X-Frame-Options, X-Content-Type-Options
+- [ ] Mots de passe hashés avec argon2id (pas de SHA, pas de MD5)
+
+## Anti-patterns
+### Auth maison
+**Ce qu'on voit :** `const token = jwt.sign({userId}, SECRET)` — JWT sans expiration, sans refresh, sans blacklist. Le token volé = accès permanent.
+**Pourquoi c'est dangereux :** l'authentification est le problème de sécurité le plus résolu — et le plus mal implémenté. Un JWT mal configuré n'a pas de révocation possible. Si l'attaquant vole un token, il a un accès permanent. Construire son propre système d'auth est la cause #1 des failles critiques.
+**Faire plutôt :** OAuth2/OIDC via un provider éprouvé (Auth0, Clerk, NextAuth, Keycloak). Access token courte durée (15 min), refresh token longue durée (7j) avec rotation. Blacklist côté serveur pour les tokens révoqués.
+
+### Validation "plus tard"
+**Ce qu'on voit :** les données arrivent dans le controller, passent dans le service, arrivent dans la DB sans validation. "Le frontend valide". "L'ORM échappe".
+**Pourquoi c'est dangereux :** le frontend est sous le contrôle de l'attaquant. Un simple `curl` contourne toute validation frontend. L'ORM échappe le SQL mais ne valide pas le type, la longueur, le charset, le business logic. Sans validation à la frontière, la DB reçoit n'importe quoi.
+**Faire plutôt :** validation à l'entrée de l'API (middleware/guard). Schéma (Zod, JSON Schema, Pydantic). Rejeter tout ce qui ne matche PAS le schéma — ne pas essayer de "corriger". Whitelist, pas blacklist.
+
+### Rate limiting absent
+**Ce qu'on voit :** `POST /login` sans rate limiting. Un attaquant brute-force 10 000 mots de passe par seconde.
+**Pourquoi c'est dangereux :** le brute-force est l'attaque la plus simple et la plus efficace. Sans rate limiting, un mot de passe faible tombe en minutes. Le rate limiting n'est pas une feature — c'est la seule défense contre l'énumération.
+**Faire plutôt :** rate limiting sur /login (5 tentatives/min/IP + compte), /api (100 req/s par clé), /reset-password (1 tentative/min/email). Retourner 429 avec `Retry-After`. Bloquer (pas juste ralentir) après N échecs.
+
+## Patterns
+### Defense in depth
+**Quand :** toute application manipulant des données sensibles.
+**Comment :** WAF → Input validation → Auth → Authorization → SQL paramétré → Output encoding → CSP → Encryption at rest. Chaque couche suppose que les précédentes ont failli. Exemple : même avec du SQL paramétré, valider le type de l'input avant. Même avec HTTPS, marquer les cookies Secure.
+
+### Structured security review (OWASP Top 10)
+**Quand :** à chaque release ou changement majeur.
+**Comment :** passer en revue le Top 10 OWASP pour CHAQUE endpoint critique. Injection, Broken Auth, Sensitive Data Exposure, XXE, Broken Access Control, Security Misconfiguration, XSS, Insecure Deserialization, Vulnerable Components, Insufficient Logging. Pas un audit annuel — une habitude de release.

package/assets/skills/architecture/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: architecture
+description: "Architecture Logicielle — monolithe modulaire, microservices, ports/adapters, ADR, Strangler Fig, trade-offs. A charger quand on definit la structure d'un projet."
+---
+
+# Architecture Logicielle
+
+**Principe premier :** L'architecture n'est pas une collection de patterns — c'est la gestion explicite des dependances. La qualite d'une architecture se mesure a une chose : combien de modules dois-je toucher pour faire un changement metier ? Si la reponse est > 3, l'architecture est cassee, peu importe le pattern utilise. Le bon pattern depend du contexte (taille d'equipe, frequence de changement, exigences de scale), pas de la mode.
+
+## Checklist
+- [ ] Le choix d'architecture est justifie par le contexte et documente (ADR)
+- [ ] Les dependances pointent vers le domaine — jamais l'inverse (Domain <> Infrastructure)
+- [ ] Les modules sont nommes par capacite metier (billing, shipping), pas par couche technique (controllers, services, utils)
+- [ ] Chaque module a une interface explicite (contrat) — pas de couplage par import direct interne
+- [ ] Demarrer simple (monolithe modulaire) — extraire en service UNIQUEMENT quand le besoin est prouve
+- [ ] Le diagramme de contexte (C4 niveau 1-2) existe et est visible des nouveaux
+
+## Trade-offs : les 3 architectures
+
+### Monolithe simple vs Monolithe modulaire vs Microservices
+
+| | Monolithe simple | Monolithe modulaire | Microservices |
+|--|-----------------|-------------------|--------------|
+| **Structure** | 1 codebase, pas de frontieres internes | 1 codebase, modules separes par domaine (billing/, orders/) | N codebases independantes |
+| **Deploiement** | 1 artefact | 1 artefact | N artefacts |
+| **Avantages** | Simple, rapide a demarrer | Deploiement simple, frontieres claires, peut extraire en service plus tard | Scale independant, equipes autonomes, isolation de pannes |
+| **Desavantages** | Devient vite un "big ball of mud" | Modules peuvent se coupler par import direct si pas discipline | Cout reseau, latence, serialisation, deploiements coordonnes |
+| **Quand choisir** | POC, equipe 1-3, court-terme | Equipe 4-20, projet long-terme | > 5 equipes, besoin de scale independant |
+| **Piege** | "On modularisera plus tard" → jamais fait | Modules deviennent des services deguises (imports croises) | Microservices sans equipes autonomes = pire que monolithe |
+
+**Regle :** commencer monolithe modulaire. Extraire en microservice quand : (1) l'equipe est trop grande pour une codebase (> 20), OU (2) un module a besoin de scale independant, OU (3) un module a un cycle de release different.
+
+## Anti-patterns
+### Microservices comme defaut
+**Ce qu'on voit :** 12 services, 12 repos, 12 pipelines — pour 3 devs et 100 utilisateurs. Un changement simple touche 4 repos.
+**Pourquoi c'est dangereux :** les microservices deplacent la complexite du code vers le reseau. Chaque service ajoute latence, serialisation, gestion d'erreur reseau. Le seuil n'est pas technologique, il est organisationnel : une equipe par service.
+**Faire plutot :** monolithe modulaire. Domaines separes en modules, interfaces explicites, meme codebase. Un commit = un changement. Extraire un service quand l'equipe grandit (> 20) ou qu'un module a besoin de scale independant.
+
+### Architecture en couches videe
+**Ce qu'on voit :** Controller → Service → Repository. Le Service fait 3 lignes : `return this.repository.findById(id)`. Le domaine n'existe pas — c'est un tuyau HTTP→DB.
+**Pourquoi c'est dangereux :** les regles metier sont eparpillees dans les controllers, validateurs, middlewares. Changer une regle oblige a traquer la logique dans 6 fichiers.
+**Faire plutot :** le domaine contient les regles. `order.approve()` verifie le statut, le credit, la dispo. Le service orchestre, le repository persiste, le controller traduit HTTP. Chaque couche a une VRAIE responsabilite.
+
+### Architecture decidee puis figee
+**Ce qu'on voit :** un diagramme dessine il y a 3 ans. L'archi reelle a diverge. Personne ne l'a documente.
+**Pourquoi c'est dangereux :** l'architecture documentee est un mensonge. Les nouveaux devs prennent des decisions sur une base fausse. La derive architecturale s'accelere.
+**Faire plutot :** ADR (Architecture Decision Records) pour les decisions importantes. Diagrammes regeneres (C4 via structurizr ou PlantUML). L'architecture est vivante.
+
+## Patterns
+### Monolithe modulaire
+**Quand :** debut de projet, equipe < 20, pas de besoin de scale independant.
+**Comment :** modules par domaine (billing/, shipping/, auth/). Chaque module a son propre schema DB logique. Communication inter-module par interfaces explicites.
+- **Avantages :** deploy simple, refactoring facile (un commit), pas de latence reseau
+- **Desavantages :** scale tout-ou-rien, un module peut bloquer le deploiement
+- **Mise en place :** (1) Creer un dossier par domaine (`src/billing/`, `src/shipping/`). (2) Chaque module expose une interface publique (`index.ts` avec exports explicites). (3) Les imports entre modules passent UNIQUEMENT par l'interface publique. (4) Chaque module a ses propres migrations DB. (5) Tester les modules isolement. (6) Si un module devient trop gros → Strangler Fig pour l'extraire.
+
+### Ports & Adapters (Hexagonale)
+**Quand :** le domaine metier doit survivre aux changements d'infrastructure.
+**Comment :** le domaine definit des interfaces (ports : `OrderRepository`, `PaymentGateway`). Les adapters implementent ces interfaces (PostgresAdapter, StripeAdapter). Le domaine ne depend de rien d'externe.
+- **Avantages :** changer de DB ou de payment provider sans toucher le domaine. Testable sans infra.
+- **Desavantages :** couche d'abstraction supplementaire. Plus de fichiers.
+- **Mise en place :** (1) Definir les ports dans le domaine. (2) Implementer les adapters dans un dossier `infrastructure/`. (3) Injecter les adapters au runtime (constructor injection). (4) Tester le domaine avec des adapters in-memory. (5) Tester les vrais adapters en integration.
+
+### Strangler Fig (migration progressive)
+**Quand :** migration d'un legacy vers une nouvelle architecture sans big bang.
+**Comment :** router le trafic progressivement. Nouvelle fonctionnalite → nouveau systeme. Ancienne migree → proxy vers nouveau, puis suppression.
+- **Avantages :** chaque etape est deployable et rollbackable. Zero downtime.
+- **Desavantages :** plus lent qu'un big bang. Cout de maintenance du proxy et des deux systemes en parallele.
+- **Mise en place :** (1) Placer un proxy/API Gateway devant le legacy. (2) Creer le nouveau service avec un sous-ensemble de fonctionnalites. (3) Router par endpoint : `GET /orders` → nouveau, le reste → legacy. (4) Migrer les endpoints un par un, valider chaque migration. (5) Migrer les donnees progressivement (dual-write puis backfill). (6) Quand tout le trafic est sur le nouveau → supprimer le legacy. (7) Supprimer le proxy. Chaque etape = une PR deployable.
+
+### ADR (Architecture Decision Record)
+**Quand :** toute decision architecturale non triviale.
+**Comment :** document leger (1-2 pages) dans `docs/adrs/NNNN-title.md`. Format : Titre, Statut (proposed/accepted/deprecated), Contexte, Decision, Alternatives, Consequences.
+- **Mise en place :** (1) Creer `docs/adrs/`. (2) Template ADR. (3) Chaque decision significative → un ADR. (4) Les ADR sont revus en PR comme du code. (5) Les ADR obsoletes sont marques `deprecated` (pas supprimes — l'historique a de la valeur). Un nouveau membre lit les ADR dans l'ordre pour comprendre l'histoire de l'architecture.

package/assets/skills/backend/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: backend
+description: "Backend — graceful degradation, connection pooling, idempotency, error handling as contract, health checks. À charger quand on crée ou modifie des services backend."
+---
+
+# Backend
+
+**Principe premier :** Le backend n'est pas "la partie qui parle à la base de données" — c'est un composant dans un système distribué qui doit survivre à la défaillance de tout ce qui l'entoure. La DB tombe, le réseau coupe, le client timeout. Un backend bien conçu ne crash pas — il dégrade, il retry, il informe. La métrique n'est pas "uptime" mais "MTTR" — chaque seconde entre la panne et la récupération est du temps utilisateur perdu.
+
+## Checklist
+- [ ] Chaque endpoint a un timeout explicite — pas de requête pendante infinie
+- [ ] Graceful shutdown : SIGTERM → stop accepter → drainer les requêtes (max 30s) → close connexions → exit
+- [ ] Health check exposé : liveness (suis-je vivant ?) ≠ readiness (puis-je servir ?)
+- [ ] Connection pooling sur DB, Redis, et clients HTTP — pas de connexion unique
+- [ ] Les erreurs sont structurées : `{code, message, details}` — jamais de stack trace en prod
+- [ ] Rate limiting en place sur les endpoints publics — pas de "on verra plus tard"
+
+## Anti-patterns
+### Avaler les erreurs
+**Ce qu'on voit :** `try { await db.query() } catch (e) { console.log(e) }`. Pas de rethrow, pas de fallback. L'erreur est loguée et oubliée.
+**Pourquoi c'est dangereux :** l'appelant reçoit "success" mais rien n'a été fait. Le système continue dans un état incohérent. Les erreurs avalées sont impossibles à debugger — tu ne sais jamais quelles opérations ont réellement échoué.
+**Faire plutôt :** soit gérer l'erreur (retry, fallback, compensation), soit la laisser remonter à un error handler global qui la transforme en réponse structurée. Ne jamais avaler silencieusement.
+
+### Graceful shutdown = process.exit(0)
+**Ce qu'on voit :** `process.on('SIGTERM', () => process.exit(0))` — les 50 requêtes en cours sont coupées net. Le load balancer envoie encore du trafic vers une instance zombie.
+**Pourquoi c'est dangereux :** perte de données, transactions incomplètes, expérience utilisateur dégradée. Le load balancer détecte la panne 30 secondes plus tard — pendant ce temps, toutes les requêtes échouent.
+**Faire plutôt :** SIGTERM → le load balancer retire l'instance (health check fail) → l'instance arrête d'accepter les nouvelles requêtes → attend la fin des requêtes en cours (timeout 30s max) → close les connexions DB/Redis → exit. Kubernetes donne 30s par défaut (terminationGracePeriodSeconds).
+
+### Une connexion DB pour tout le monde
+**Ce qu'on voit :** `const db = new Database(DATABASE_URL)` — un singleton connexion pour toute l'application. 100 requêtes simultanées = 99 en file d'attente.
+**Pourquoi c'est dangereux :** la connexion unique est le bottleneck. Les requêtes s'empilent, la latence explose. Sous charge, l'app devient non-réactive. Une seule requête lente bloque tout le monde.
+**Faire plutôt :** connection pool. min/max configurés selon la charge attendue (min: 2, max: 20). Monitorer les métriques du pool : waiting, idle, active. Si `waiting > 0` régulièrement, augmenter le max ou optimiser les requêtes.
+
+## Patterns
+### Middleware chain
+**Quand :** logique transversale (auth, logging, rate limiting, CORS).
+**Comment :** chaque middleware fait UNE chose. Ordre canonique : CORS → rate limit → auth → validation → handler → error handler. La requête traverse la chaîne dans l'ordre, l'erreur remonte dans l'ordre inverse.
+
+### Idempotency token
+**Quand :** opérations mutantes (paiement, création de ressource) où le double-submit est dangereux.
+**Comment :** le client génère un `Idempotency-Key: uuid`. Le serveur stocke la clé + le résultat de l'opération dans une transaction. Si la clé est déjà vue → retourner le résultat stocké sans ré-exécuter.

package/assets/skills/backup-recovery/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: backup-recovery
+description: "Backup & Recovery — RPO/RTO, PITR, disaster recovery, multi-region, test de restore. A charger quand on configure les sauvegardes."
+---
+
+# Backup & Recovery
+
+**Principe premier :** Une sauvegarde n'est pas une copie de donnees — c'est une police d'assurance, et comme toute assurance, tu ne sais pas si elle marche tant que tu n'as pas fait de sinistre. La question n'est pas "est-ce qu'on a des backups ?" (oui, tout le monde en a) — c'est "a quelle date etait le dernier test de restore ?" Un backup jamais teste n'est pas un backup, c'est un vœu pieux. Les deux metriques qui definissent ta strategie sont le RPO (Recovery Point Objective : combien de donnees tu acceptes de perdre, en temps) et le RTO (Recovery Time Objective : combien de temps pour restaurer le service). Tout le reste — outils, frequence, retention — decoule de ces deux nombres.
+
+## Checklist
+- [ ] RPO (perte de donnees max acceptable) et RTO (temps de restore max acceptable) sont definis et documentes
+- [ ] Les backups sont automatises — pas de "je fais un pg_dump le vendredi soir"
+- [ ] Le restore est teste regulierement (minimum trimestriel) — sans test, pas de backup
+- [ ] Les backups sont stockes dans une region/separee differente de la production (pas dans le meme datacenter)
+- [ ] La retention est definie : journaux 30j, mensuels 12 mois, annuels 7 ans (selon conformite)
+- [ ] Les backups sont chiffres au repos et en transit — une fuite de backup = fuite de toutes les donnees
+- [ ] Le processus de restore est documente et testable par n'importe quel membre de l'equipe
+
+## Anti-patterns
+### Backup = dump periodique
+**Ce qu'on voit :** `pg_dump` tous les jours a 3h du matin. "On a une sauvegarde." RPO = 24h. Restore = manuel, non teste.
+**Pourquoi c'est dangereux :** un pg_dump quotidien = tu perds jusqu'a 24h de donnees. Le restore prend des heures (charger un dump complet). Pas de PITR (point-in-time recovery) — si la corruption est arrivee a 14h, tu ne peux pas restaurer a 13h59, seulement a 3h du matin.
+**Faire plutot :** WAL archiving continu (PostgreSQL) ou binlog (MySQL) → PITR possible a la seconde pres. Backups complets hebdomadaires + incrementaux quotidiens ou continus. Restore PITR teste automatiquement.
+
+### Backup dans la meme region
+**Ce qu'on voit :** backups dans le meme S3 bucket, meme region, meme compte. "C'est plus simple a gerer."
+**Pourquoi c'est dangereux :** la region tombe (panne AWS, coupure electrique, catastrophe naturelle) → tous les backups sont inaccessibles. Un attaquant compromet le compte → il supprime tout, backups inclus. Le backup co-localise n'est pas un backup — c'est une copie.
+**Faire plutot :** backups cross-region minimum. Idealement cross-cloud pour les donnees critiques. Les backups sont dans un compte separe avec acces minimal. Immutable backups (Object Lock, WORM) : meme l'admin ne peut pas supprimer avant la retention.
+
+### "Le restore a marche en staging il y a 6 mois"
+**Ce qu'on voit :** le test de restore a ete fait une fois, lors de la mise en place. Depuis, le schema a change, les volumes ont triple, l'equipe a tourne.
+**Pourquoi c'est dangereux :** un restore est un processus complexe : restaurer la DB, verifier l'integrite, re-configurer les connexions, re-chauffer les caches, valider les donnees. Chaque changement dans le schema, les dependances, ou l'infrastructure peut casser le restore. Un restore qui echoue le jour du sinistre = pas de restore du tout.
+**Faire plutot :** restore automatise hebdomadaire dans un environnement isole. Tests d'integrite automatiques apres restore. L'alerte part si le restore echoue. Le test de restore fait partie de la sante operationnelle, comme un health check.
+
+## Patterns
+### Strategie 3-2-1
+**Quand :** toute strategie de backup.
+**Comment :** 3 copies des donnees, sur 2 types de media differents, dont 1 copie hors site (offsite). Exemple : backup local (rapide a restaurer) + backup cloud (region A) + backup cloud (region B, immuable). Une panne ou corruption sur un seul media ne detruit pas tout.
+
+### Point-in-time recovery (PITR)
+**Quand :** base de donnees relationnelle (PostgreSQL, MySQL, SQL Server).
+**Comment :** WAL archiving continu vers un stockage objet. Backup complet hebdomadaire. Restore : charger le dernier backup complet → appliquer les WAL jusqu'au timestamp desire. RPO effectif = secondes (le delai de replication du WAL), pas heures.

package/assets/skills/caching/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: caching
+description: "Caching — cache-aside/write-through, cache stampede protection, TTL strategy, invalidation as the hard problem. À charger quand on parle de performance ou de mise en cache."
+---
+
+# Caching
+
+**Principe premier :** Il y a deux problèmes difficiles en informatique : nommer les choses, l'invalidation de cache, et les off-by-one. Le cache est un mensonge délibéré — tu sers une version potentiellement périmée de la donnée en échange de latence réduite. La seule question qui compte est : "quelle est la péremption acceptable pour CE cas d'usage ?" Si la réponse est 0ms, pas de cache. Si la réponse est "5 minutes, c'est acceptable", tu as un budget d'incohérence. Nommer ce budget explicitement est le design du cache.
+
+## Checklist
+- [ ] La stratégie est choisie selon le pattern d'accès : cache-aside (read-heavy), write-through (read-after-write), write-behind (write-heavy)
+- [ ] Chaque entrée de cache a un TTL explicite et justifié — jamais de cache infini
+- [ ] La protection anti-stampede est en place — 1000 miss simultanés ne déclenchent pas 1000 requêtes DB
+- [ ] Le cache est monitoré : hit rate, miss rate, eviction rate, mémoire utilisée
+- [ ] L'invalidation est événementielle ou par TTL — jamais "pense à vider le cache" en commentaire
+
+## Anti-patterns
+### Cache infini
+**Ce qu'on voit :** `cache.set('user:' + id, userData)` sans TTL. Le cache ne sera vidé que quand Redis sera plein et fera une éviction arbitraire.
+**Pourquoi c'est dangereux :** l'incohérence grandit avec le temps. L'utilisateur change son email dans la DB, le cache sert l'ancien pendant des jours. Le bug est intermittent (parfois cache hit, parfois miss) — le pire type de bug à debugger.
+**Faire plutôt :** toujours un TTL. Court pour les données dynamiques (1-5 min). Long pour le statique (1-24h). Le TTL est un compromis entre fraîcheur et performance — le choisir consciemment.
+
+### Cache stampede
+**Ce qu'on voit :** une clé chaude expire. 1000 requêtes simultanées arrivent. Toutes font un cache miss → toutes interrogent la DB. La DB reçoit 1000× la même requête.
+**Pourquoi c'est dangereux :** le stampede transforme un cache miss en attaque DDoS auto-infligée. La DB qui allait bien voit soudainement 1000× la charge normale. Pire : elle génère 1000× la même réponse, et 999 réponses sont jetées.
+**Faire plutôt :** probabilistic early recomputation (recalculer avec une probabilité croissante quand le TTL approche). Ou lock distribué temporaire — un seul worker recalcule, les autres attendent le résultat (SETNX).
+
+### Invalidation commentée
+**Ce qu'on voit :** `// PENSE À VIDER LE CACHE QUAND TU MODIFIES CETTE TABLE` — dans un commentaire. Qui n'est pas lu. Par un dev qui ne savait pas. Le cache et la DB divergent silencieusement.
+**Pourquoi c'est dangereux :** l'invalidation manuelle est une machine à bugs intermittents. Chaque écriture est une opportunité d'oubli. Le bug n'apparaît que dans le cas "cache hit après écriture" — difficile à reproduire.
+**Faire plutôt :** invalidation automatique. Événement DB → event bus → cache invalidation. Ou TTL assez court pour que l'incohérence maximale soit acceptable. Jamais de "penser à" dans la conception d'un système.
+
+## Patterns
+### Cache-aside
+**Quand :** lecture dominante, tolérance à la stale data.
+**Comment :** (1) lire le cache, (2) si hit → retourner, (3) si miss → lire la DB, (4) écrire dans le cache, (5) retourner. L'application est responsable de la cohérence. Simple, mais attention au stampede.
+
+### Write-through
+**Quand :** les données écrites sont presque toujours relues immédiatement.
+**Comment :** écrire dans le cache ET dans la DB dans la même opération. Le cache est toujours chaud pour les lectures récentes. Coût : chaque écriture touche le cache, même si personne ne relit.
+
+### Probabilistic early recomputation
+**Quand :** protéger une clé chaude du stampede.
+**Comment :** avant que le TTL n'expire, le worker vérifie si `random() < 1 / (TTL_remaining_seconds * request_rate)`. Si oui, il recalcule de manière anticipée et met à jour le cache. Statistiquement, un seul worker le fait.

package/assets/skills/cdn/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: cdn
+description: "CDN & Edge — cache geographique, TTL strategies, origin shield, edge computing, cache invalidation. A charger quand on configure un CDN ou optimise la livraison de contenu."
+---
+
+# CDN & Edge
+
+**Principe premier :** Un CDN n'est pas un "cache rapide" — c'est un reseau de distribution qui rapproche les donnees de l'utilisateur. La latence n'est pas une question de bande passante, c'est une question de distance (lumiere dans la fibre = ~5ms pour 1000km). Un CDN reduit la distance en placant les donnees dans 200+ points de presence. Mais un CDN est aussi un cache — et tout cache peut servir des donnees stale. La question centrale n'est pas "est-ce que le CDN est rapide ?" mais "quelle fraicheur est acceptable pour quel contenu ?"
+
+## Checklist
+- [ ] Les assets statiques sont servis via CDN (pas depuis le serveur d'origine) avec Cache-Control explicite
+- [ ] Les headers de cache sont differencies par type de contenu : immutable pour versionne, revalidation pour dynamique
+- [ ] L'origin shield est configure — pas de 50 POPs qui frappent l'origine simultanement
+- [ ] L'invalidation est ciblee (chemins specifiques, pas `/*`) et monitorisee
+- [ ] Le TTL est defini selon la fraicheur acceptable : html 5min, assets versionnes 1 an
+- [ ] Les tokens/query strings prives ne cassent pas le cache (strip, normalize, ou ignore)
+- [ ] Le CDN est devant l'application entiere, pas juste les assets (DDoS protection, SSL termination)
+
+## Anti-patterns
+### Tout en `max-age=0, no-cache`
+**Ce qu'on voit :** l'equipe a ete brulee par du contenu stale. Solution : tout revalider a chaque requete.
+**Pourquoi c'est dangereux :** chaque requete frappe l'origine. Le CDN devient un proxy transparent inutile (cout + latence sans benefice). Le serveur d'origine encaisse 100% du trafic. Le CDN coute de l'argent pour rien.
+**Faire plutot :** differencier par type de contenu. Assets versionnes → `max-age=31536000, immutable`. Pages HTML → `max-age=300, stale-while-revalidate=600`. API responses → `max-age=0, private` (pas de cache CDN pour les donnees privees).
+
+### Cache invalidation = `/*`
+**Ce qu'on voit :** un deployement → invalidation de tout le cache (`/*`). 50000 requetes simultanees vers l'origine.
+**Pourquoi c'est dangereux :** l'invalidation complete cree un "cache stampede" sur l'origine. Le serveur d'origine n'est pas dimensionne pour le trafic total. Chaque deployement = risque d'outage.
+**Faire plutot :** invalider uniquement les chemins modifies. Utiliser des noms de fichiers versionnes (`main.a3f2b1c.js`) → jamais besoin d'invalider. Pour les SPA : invalider `index.html` seulement, le reste est immutable.
+
+### CDN = juste pour les images
+**Ce qu'on voit :** seuls les assets statiques sont sur le CDN. L'API et les pages HTML passent directement au serveur.
+**Pourquoi c'est dangereux :** le CDN offre la terminaison SSL, la protection DDoS, le WAF, l'optimisation d'images, le edge computing. Le mettre uniquement devant `/static/` gaspille sa capacite principale : absorber le trafic malveillant avant qu'il n'atteigne l'origine.
+**Faire plutot :** CDN devant tout le domaine. L'origine est cachee derriere le CDN, pas exposee publiquement. Les regles de cache decident ce qui est servi depuis le edge vs l'origine.
+
+## Patterns
+### Cache hierarchies (origin shield)
+**Quand :** trafic global avec beaucoup de POPs (200+).
+**Comment :** un POP regional intermediaire (origin shield) consolide les requetes vers l'origine. Au lieu de 200 POPs qui frappent l'origine sur un cache miss, seul l'origin shield la contacte. Reduction de la charge origine de 100-200x.
+
+### Stale-while-revalidate
+**Quand :** contenu qui peut etre legerement stales (pages HTML, reponses API publiques).
+**Comment :** `Cache-Control: max-age=300, stale-while-revalidate=600`. Le CDN sert le contenu stales jusqu'a 15 minutes pendant qu'il revalide en arriere-plan. L'utilisateur ne voit jamais la latence de revalidation. Ideal pour les pages qui changent peu.

package/assets/skills/chaos/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: chaos
+description: "Chaos Engineering — injection de pannes, Game Day, Chaos Monkey, experimentation, hypotheses de resilience. A charger quand on teste la resilience d'un systeme."
+---
+
+# Chaos Engineering
+
+**Principe premier :** Le chaos engineering n'est pas "casser des choses en production pour voir ce qui se passe" — c'est une discipline scientifique appliquee aux systemes distribues. Tu formules une hypothese de resilience ("si le service B tombe, le fallback degrade le mode"), tu injectes la panne de maniere controlee, et tu compares le comportement observe a l'hypothese. La valeur n'est pas dans le chaos — elle est dans la decouverte des comportements emergents que personne n'avait prevus. Un systeme sans chaos engineering n'est pas stable — il est non teste. La stabilite reelle se mesure en production, pas en staging.
+
+## Checklist
+- [ ] Une hypothese de resilience est formulee avant chaque experience (pas "on va eteindre cette DB et voir")
+- [ ] Le blast radius est controle : un petit pourcentage de trafic, un seul AZ/service
+- [ ] L'experience a un arret d'urgence (kill switch) actionnable en < 10 secondes
+- [ ] Les metriques sont en place AVANT l'experience (baseline + deviation en temps reel)
+- [ ] Le Game Day est planifie avec un scenario et un runbook
+- [ ] Les decouvertes sont documentees et transforment le systeme (pas "c'etait interessant, on fera mieux")
+
+## Anti-patterns
+### Chaos en production sans filet
+**Ce qu'on voit :** "on va tester en production vendredi soir." Pas d'hypothese, pas de kill switch, pas de monitoring.
+**Pourquoi c'est dangereux :** le chaos sans controle n'est pas une experience — c'est un incident provoque. Sans hypothese, tu ne sais pas si le comportement est normal ou anormal. Sans kill switch, tu ne peux pas arreter l'hemorragie.
+**Faire plutot :** commencer en staging avec des pannes simples (kill un process, saturer un disque). Monter en puissance progressivement. En production : commencer par 1% de trafic, puis 5%, puis 10%. Toujours avec un kill switch.
+
+### Chaos = Chaos Monkey uniquement
+**Ce qu'on voit :** l'equipe installe Chaos Monkey, kill des instances au hasard, et considere que le chaos engineering est fait.
+**Pourquoi c'est dangereux :** Chaos Monkey teste UNE chose : que ton application survit a la mort d'une instance. Ca ne teste pas la latence reseau, la corruption de donnees, la saturation disque, les pannes DNS, les timeouts de circuit breaker. Le chaos engineering est une discipline large — Chaos Monkey en est un tout petit sous-ensemble.
+**Faire plutot :** varier les injections : latence reseau, perte de paquets, defaillance DNS, saturation CPU/disque, coupure de dependance, corruption de reponse, expiration de certificat. Chaque type de panne revele une classe de vulnerabilites differente.
+
+### Pas de suivi des decouvertes
+**Ce qu'on voit :** le Game Day est fun. Les decouvertes sont notees sur un post-it. Rien n'est corrige.
+**Pourquoi c'est dangereux :** le chaos engineering sans correction est du theatre. Les memes vulnerabilites survivent au Game Day suivant. L'equipe apprend mais le systeme n'apprend pas.
+**Faire plutot :** chaque decouverte = un ticket. Prioriser les corrections avant le prochain Game Day. Re-tester les memes pannes pour verifier que la correction fonctionne. Le chaos engineering est une boucle : injecter → mesurer → corriger → re-tester.
+
+## Patterns
+### Game Day
+**Quand :** equipe qui n'a jamais teste son systeme en conditions de panne.
+**Comment :** 2h-4h planifiees. 1 scenario defini a l'avance ("la DB primaire est inaccessible"). Roles : un orchestrateur, un observateur, un intervenant. Monitoring temps reel. Debrief immediat apres : qu'est-ce qui a casse ? qu'est-ce qui a tenu ? qu'est-ce qu'on corrige ?
+
+### Steady-state hypothesis
+**Quand :** toute experience de chaos.
+**Comment :** definir l'etat normal AVANT l'injection ("P95 latence < 500ms, taux d'erreur < 1%, pas d'alerte critique"). Injecter la panne. Comparer a l'etat normal. Si l'ecart est inattendu → vulnerabilite. Cette methode donne une definition objective de "le systeme a tenu".

package/assets/skills/cicd-pipeline/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: cicd-pipeline
+description: "CI/CD — feedback loops, DORA metrics, trunk-based dev, pipeline as constraint theory, matrix builds, OIDC, ephemeral runners. À charger quand on conçoit ou optimise un pipeline CI/CD."
+---
+
+# CI/CD Pipeline
+
+**Principe premier :** La CI/CD n'est pas "automatiser les builds". C'est réduire le temps entre un commit et le feedback de production. Chaque minute perdue entre "j'écris" et "je sais si ça marche" est du gaspillage. Les 4 métriques DORA (Lead Time, Deploy Frequency, MTTR, Change Failure Rate) mesurent cette performance. Tout le reste — caching, parallel builds, OIDC — est un moyen, pas une fin.
+
+## Checklist
+- [ ] La pipeline donne du feedback en < 5 min (sinon les devs arrêtent de l'attendre)
+- [ ] Le trunk-based development est la norme — branches ≤ 1 jour, pas de long-lived branches
+- [ ] Les 4 DORA metrics sont mesurées et visibles (dashboard, pas dans un coin)
+- [ ] Les secrets utilisent OIDC — zéro credential long-lived
+- [ ] Les runners sont éphémères — rien ne survit entre deux builds
+- [ ] Concurrency groups — pas deux pipelines en parallèle sur la même branche
+- [ ] Le pipeline bloque sur flaky test detection (> 2% de flaky rate = quarantaine automatique)
+- [ ] L'artefact de build est immutable et signé (hash + signature vérifiés au déploiement)
+
+## Anti-patterns
+### Branches longue durée
+**Ce qu'on voit :** un dev travaille 2 semaines sur `feature/big-refactor`. Merge conflict de 200 fichiers. Tests jamais lancés ensemble.
+**Pourquoi c'est dangereux :** le "I" de CI, c'est l'intégration. Si le code n'est pas intégré au trunk au moins 1×/jour, ce n'est pas de la CI. Le merge final est un événement traumatique — les bugs apparaissent tous en même temps, impossible de bisecter proprement.
+**Faire plutôt :** trunk-based development. Branches ≤ 1 jour. Feature flags pour cacher le code incomplet. Petits commits fréquents — le diff est la meilleure défense contre les bugs.
+
+### Pipeline vu comme un checklist et non une contrainte
+**Ce qu'on voit :** lint → test → build → deploy, séquentiel. Le pipeline met 20 min et personne ne se demande pourquoi c'est lent.
+**Pourquoi c'est dangereux :** un pipeline lent n'est pas juste chiant — il tue la boucle de feedback. Les devs ne poussent plus, ils accumulent, les PRs grossissent, la CI devient un bottleneck systémique. C'est la théorie des contraintes : le pipeline EST la contrainte.
+**Faire plutôt :** traiter le pipeline comme un système à optimiser. Paralléliser tout ce qui peut l'être. Investir dans le cache. Splitter les tests lents. CI < 5 min — si c'est pas possible, c'est que l'architecture de test a un problème.
+
+### Pipeline non versionné
+**Ce qu'on voit :** le pipeline est configuré dans l'UI GitHub Actions, pas dans `.github/workflows/`. Ou pire : un Jenkins configuré à la main.
+**Pourquoi c'est dangereux :** le pipeline n'est pas reproductible. Si le runner crashe, personne ne sait le reconstruire. Pas de code review sur les changements de pipeline. Le pipeline devient un snowflake.
+**Faire plutôt :** pipeline as code — dans le repo, revu comme du code. Tout changement de pipeline passe par une PR. Le pipeline se teste lui-même (les changements de CI s'exécutent sur la PR qui les propose).
+
+### Flaky tests ignorés
+**Ce qu'on voit :** "ah ce test faille parfois, relance le job". Le pipeline a un taux de succès de 70% et tout le monde rerun jusqu'à ce que ça passe.
+**Pourquoi c'est dangereux :** un test flaky tue la confiance dans le pipeline. Quand le rouge ne veut plus dire "bug", les vrais bugs passent au travers. Les devs développent une tolérance à l'échec — c'est la mort lente de la CI.
+**Faire plutôt :** quarantaine automatique. Un test qui faille > 2% du temps est isolé dans une suite "quarantaine". Le pipeline principal bloque sur vrai rouge. La quarantaine est traitée comme dette technique prioritaire.
+
+## Patterns
+### OIDC
+**Quand :** tout pipeline qui parle à un cloud provider.
+**Comment :** GitHub Actions → OIDC token → AWS IAM / GCP WIF → credentials temporaires (< 1h). Zéro secret stocké. Rotation automatique. Si le token fuit, il expire avant d'être utilisable.
+
+### Matrix build
+**Quand :** bibliothèque ou outil utilisé sur plusieurs versions/OS.
+**Comment :** `matrix: { node: [18, 20, 22], os: [ubuntu, macos] }`. Chaque combinaison est un job indépendant. Pas de "ça marche sur ma machine" quand la CI couvre 3 OS.
+
+### Concurrency groups
+**Quand :** éviter les interférences entre runs.
+**Comment :** `concurrency: { group: deploy-${{ github.ref }}, cancel-in-progress: true }`. Un seul déploiement à la fois par branche. Le nouveau run annule le précédent. Évite les race conditions de déploiement.
+
+### Flaky test quarantine
+**Quand :** suite de tests avec > 100 tests.
+**Comment :** chaque test a un compteur de flaky (fail suivi de pass sans changement de code). Si > 2% sur 100 runs → déplacé en `quarantine/`. Le pipeline principal ignore cette suite. La quarantaine est revue chaque sprint — chaque test est soit fixé, soit réécrit, soit supprimé.

package/assets/skills/cloud/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: cloud
+description: "Cloud — IAM least privilege comme principe zero, multi-account, cost optimization, auto-scaling, managed services vs DIY. À charger quand on conçoit une architecture cloud."
+---
+
+# Cloud
+
+**Principe premier :** Le cloud n'est pas "des serveurs chez Amazon" — c'est un modèle de responsabilité partagée où la sécurité est programmatique. La console AWS/GCP n'est PAS ton interface de gestion — c'est une porte dérobée pour le debugging. Tout doit être Infrastructure as Code. Le principe zéro est IAM least privilege : chaque service, chaque humain, chaque pipeline a EXACTEMENT les permissions nécessaires et rien de plus. Une permission de trop = une surface d'attaque inutile. Le second principe est que le cloud est un abonnement, pas un achat — chaque ressource qui tourne coûte de l'argent, 24/7.
+
+## Checklist
+- [ ] IAM least privilege : chaque rôle/service a les permissions minimales — revu trimestriellement
+- [ ] Infrastructure as Code (Terraform/Pulumi/CloudFormation) — zéro ressource créée à la main
+- [ ] Environnements séparés (comptes/projects différents) — la dev ne touche pas la prod
+- [ ] Données chiffrées au repos (S3 SSE, RDS encryption, EBS encryption) et en transit (TLS)
+- [ ] Auto-scaling configuré avec min/max et métriques pertinentes
+- [ ] Budget alerts à 80% et 100% + cost anomaly detection
+- [ ] Multi-AZ sur toute charge de production — une AZ peut tomber
+
+## Anti-patterns
+### IAM AdministratorAccess partout
+**Ce qu'on voit :** chaque service, chaque dev, chaque pipeline a `AdministratorAccess` "pour pas être bloqué". Une clé IAM qui fuit = accès root au compte.
+**Pourquoi c'est dangereux :** IAM n'est pas un obstacle — c'est la SEULE chose qui empêche un attaquant (ou un bug) de supprimer toute ton infrastructure. Un `terraform destroy` accidentel avec des droits admin = tout est perdu. Sans IAM strict, le blast radius d'une fuite de credentials est le compte entier.
+**Faire plutôt :** politiques IAM minimales. `s3:GetObject` sur CE bucket, pas `s3:*`. `ec2:Describe*` pour le monitoring, pas `ec2:TerminateInstances`. Policies gérées en Terraform, pas dans la console. Revue trimestrielle avec IAM Access Analyzer.
+
+### Tout dans le même compte
+**Ce qu'on voit :** dev, staging, prod dans le même compte AWS. Le stagiaire teste un script qui supprime toutes les instances.
+**Pourquoi c'est dangereux :** sans isolation de blast radius, un incident en dev peut détruire la production. Les limites de service (1000 instances, 100 DBs) sont partagées. Les coûts sont mélangés — impossible de savoir ce que coûte la prod vs la dev.
+**Faire plutôt :** comptes séparés par environnement. AWS Organizations ou GCP Folders. Accès cross-account pour les besoins légitimes, jamais l'inverse.
+
+### Facture = surprise de fin de mois
+**Ce qu'on voit :** personne ne regarde les coûts cloud. Un dev lance une instance GPU p3.16xlarge pour tester. Facture x10 à la fin du mois.
+**Pourquoi c'est dangereux :** le cloud facture à l'usage, 24/7. Chaque ressource oubliée coûte. Sans monitoring des coûts, tu découvres les problèmes quand la facture arrive — 30 jours trop tard.
+**Faire plutôt :** budget alerts à 80% et 100%. Tags de coût obligatoires (project, team, environment). Revue mensuelle. Instances non utilisées automatiquement arrêtées (Dev/Staging la nuit, week-end).
+
+## Patterns
+### IAM least privilege
+**Quand :** toute ressource cloud.
+**Comment :** chaque rôle a `Effect: Allow` uniquement sur les actions et ressources nécessaires. Pas de wildcard `Resource: "*"`. Pas de `Action: "*"`. Utiliser des conditions (IP source, MFA, tags). Partir de zéro et ajouter ce qui est nécessaire, pas l'inverse.
+
+### Multi-AZ
+**Quand :** toute charge de production.
+**Comment :** déployer sur au moins 2 zones de disponibilité. Load balancer répartit. RDS Multi-AZ (standby dans une autre AZ, failover automatique). Si une AZ tombe, le service continue. Coût : ~2× l'infra, mais l'alternative c'est le downtime.

package/assets/skills/code-quality/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: code-quality
+description: "Code Quality — linting, formatage, analyse statique, dette technique, conventions, complexite cyclomatique. A charger quand on parle de qualite ou standards de code."
+---
+
+# Code Quality
+
+**Principe premier :** La qualite du code ne se mesure pas en "proprete" esthetique — elle se mesure en temps de comprehension pour le prochain developpeur. Un code "sale" mais compris en 30 secondes est meilleur qu'un code "propre" qui prend 10 minutes a decoder. Le linter et le formatter existent pour ELIMINER les debats de style, pas pour les multiplier. Si une regle de linting genere des discussions en code review, elle est contre-productive — desactive-la. Le standard de qualite n'est pas la perfection, c'est la consistance : le code doit avoir l'air ecrit par une seule personne, meme si l'equipe a 10 developpeurs.
+
+## Checklist
+- [ ] Le projet a un linter (ESLint, Biome, Ruff, Clippy) avec des regles strictes mais non controversees
+- [ ] Le formatage est automatise (Prettier, dprint, gofmt) — zero debat de style en code review
+- [ ] La complexite cyclomatique est limitee (max 15-20 par fonction) et mesuree dans la CI
+- [ ] Les fichiers sont limits en taille (max 300-500 lignes) — au-dela, splitter
+- [ ] Les commentaires expliquent le POURQUOI, pas le QUOI (le code dit deja QUOI)
+- [ ] Le code mort est supprime, pas commente — git garde l'historique
+- [ ] La duplication est toleree jusqu'a 3 occurrences — abstraire au 4e usage, pas au 2e (Rule of Three)
+
+## Anti-patterns
+### Linting maximaliste
+**Ce qu'on voit :** 200 regles ESLint activees. `no-console`, `no-param-reassign`, `max-lines-per-function: 20`, `no-else-return`. Chaque commit declenche 15 erreurs qui ne sont PAS des bugs.
+**Pourquoi c'est dangereux :** le linter n'est plus un outil — c'est un obstacle. Les devs le contournent (`eslint-disable` partout), le resultat est pire que pas de linter du tout. La fatigue du linter cree une culture ou les avertissements sont ignores.
+**Faire plutot :** regles qui attrapent des BUGS, pas des preferences : `no-undef`, `no-unused-vars` (erreur, pas warning), `no-unsafe-*`. Formatage automatique, pas manuel. Tout le reste : warning ou off. L'objectif est zero faux positifs, pas un score de linting eleve.
+
+### Refactoring sans filet
+**Ce qu'on voit :** "je refactore cette classe pour la rendre plus propre." 2 semaines plus tard, 40 fichiers modifies, fonctionnalites cassees, aucun test ajoute.
+**Pourquoi c'est dangereux :** le refactoring sans tests n'est pas du refactoring — c'est de la reecriture. Sans filet, chaque changement est un risque. Le "clean code" qui casse la production n'est pas propre — il est dangereux.
+**Faire plutot :** tests AVANT refactoring. Si le code n'a pas de tests, en ecrire (characterization tests). Refactoring en petits pas, commit par commit. Si un test casse, revert immediatement.
+
+### Abstraction prematuree (DRY abuse)
+**Ce qu'on voit :** deux fonctions de 3 lignes qui se ressemblent → abstraction dans une classe mere. La 3e utilisation arrive, difference subtile → `if (specialCase)`. 4e utilisation → 4 parametres de configuration. L'abstraction est devenue plus complexe que le code duplique.
+**Pourquoi c'est dangereux :** le mauvais DRY crée du couplage. Une abstraction prematuree lie ensemble des concepts qui evoluent differemment. Le cout de changer l'abstraction (tous les appels) depasse le cout de la duplication (2-3 endroits).
+**Faire plutot :** Rule of Three : dupliquer jusqu'a 3 fois. A la 3e occurrence, abstraire. L'abstraction a maintenant 3 cas reels pour etre testee. Si la 4e occurrence ne rentre pas, l'abstraction etait prematuree — splitter.
+
+## Patterns
+### Boy Scout Rule
+**Quand :** maintenance quotidienne.
+**Comment :** "laisse le code plus propre que tu ne l'as trouve." Un petit nettoyage a chaque commit : renommer une variable, extraire une fonction, supprimer du code mort. Pas de refactoring massif — des micro-ameliorations continues.
+
+### Static analysis in CI
+**Quand :** toute PR.
+**Comment :** le linter + l'analyse statique tournent dans la CI. Bloquant sur les regles de securite et de bug. Non-bloquant (annotation dans la PR) pour les suggestions de style. Exemple : `eslint --max-warnings 0` pour les regles d'erreur, `--quiet` pour le reste.

package/assets/skills/code-review/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: code-review
+description: "Code Review — PR hygiene, review checklist, constructive feedback, security review, Boy Scout Rule. À charger quand on fait ou reçoit une revue de code."
+---
+
+# Code Review
+
+**Principe premier :** La code review n'est pas un gate de qualité — c'est un outil de partage de connaissance. Le but #1 n'est pas de trouver des bugs (les tests et la CI font ça), c'est de s'assurer que le code est compréhensible par quelqu'un qui ne l'a pas écrit. Un bug trouvé en review est un échec des tests. Une incompréhension en review est un échec du code. La métrique n'est pas "nombre de commentaires" mais "est-ce que je pourrais maintenir ce code sans parler à l'auteur ?"
+
+## Checklist
+- [ ] La PR fait < 400 lignes — sinon, découper
+- [ ] Les tests existent, passent, et couvrent les cas limites
+- [ ] La description explique le POURQUOI, pas le QUOI (le diff montre le quoi)
+- [ ] Les noms sont explicites — pas de `x`, `data`, `tmp`, `result`, `handle()`
+- [ ] Pas de code mort, pas de TODO sans ticket, pas de commentaire qui ment
+- [ ] La sécurité est vérifiée : injection, auth, PII exposé
+
+## Anti-patterns
+### PR de 2000 lignes
+**Ce qu'on voit :** une PR avec 15 fichiers, 3 fonctionnalités, et une description "Refactoring + nouvelle feature + fix bug".
+**Pourquoi c'est dangereux :** impossible à review correctement. Le cerveau humain ne peut pas traiter 2000 lignes de diff. Les bugs passent. La review dure 2h et personne ne la fait sérieusement. Les grosses PRs sont le symptôme d'un découpage du travail mal fait.
+**Faire plutôt :** PR < 400 lignes. Une fonctionnalité, un fix, un refactoring par PR. Petits merges fréquents. Si le changement est gros → feature flag + PRs incrémentales.
+
+### Feedback sur la personne
+**Ce qu'on voit :** "c'est nul", "refais tout", "pourquoi t'as fait comme ça ?" — ton condescendant.
+**Pourquoi c'est dangereux :** ça ne tue pas que l'humeur — ça tue les futures PRs. L'auteur évite de soumettre, ou soumet en cachette. La qualité baisse par peur du feedback. Le coût est à long terme.
+**Faire plutôt :** "Cette approche a le risque X" (pas "tu as mal fait"). Suggestion, pas ordre : "Est-ce qu'on pourrait... ?". Le feedback cible le code, jamais la personne.
+
+### LGTM reflex
+**Ce qu'on voit :** "LGTM" sur une PR de 500 lignes, 2 minutes après l'ouverture.
+**Pourquoi c'est dangereux :** c'est un non-review. Le reviewer n'a pas lu le code. L'auteur n'apprend rien. Les bugs passent. Pire : ça donne une fausse confiance ("c'est reviewé").
+**Faire plutôt :** si tu n'as pas le temps, ne review pas. Si tu review, passe au moins 15 min et trouve au moins UNE chose (positive ou à améliorer). Une review qui ne produit aucun commentaire n'est pas une review.
+
+## Patterns
+### PR template
+**Quand :** toute PR.
+**Comment :** template concis : contexte, changements, captures/évidence, points d'attention pour le reviewer. L'auteur remplit. Le reviewer a tout le contexte. 2 minutes de remplissage = 15 minutes gagnées en review.
+
+### Boy Scout Rule
+**Quand :** tout fichier touché.
+**Comment :** laisser le code plus propre qu'on ne l'a trouvé. Renommer une variable confuse. Extraire une fonction de 30 lignes. Ajouter un test manquant. Pas de refactoring massif — juste le petit coup de balai.

package/assets/skills/communication/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: communication
+description: "Communication Technique — documentation, diagrammes C4, RFC, post-mortem, presentation, spec writing. A charger quand on communique sur un sujet technique."
+---
+
+# Communication Technique
+
+**Principe premier :** La communication technique n'est pas "ecrire ce qu'on sait" — c'est faire comprendre ce que l'autre a besoin de savoir. Le plus grand piege de la communication d'expert : la malediction du savoir. Tu sais tellement bien ton sujet que tu ne peux plus imaginer ce que c'est de ne pas le savoir. Resultat : tu sautes des etapes, utilises du jargon, assumes des prerequis — et ton interlocuteur est perdu. La regle d'or : si tu ne peux pas expliquer ton design a un dev qui vient d'arriver, ton design n'est pas pret. Pas parce que le dev est novice — parce que la clarte est un test de comprehension. Si c'est flou dans ta tete, c'est flou sur le papier.
+
+## Checklist
+- [ ] La documentation est dans le repo, versionnee avec le code — pas dans Confluence/Notion qui se perime
+- [ ] Les decisions techniques sont communiquees avec le POURQUOI (contexte, alternatives) — pas juste la solution
+- [ ] Les diagrammes utilisent un standard reconnu (C4, UML sequence, Mermaid) — pas un outil proprietaire
+- [ ] Les specs sont ecrites avant le code, lues par l'equipe, et amendees — pas "le code est la spec"
+- [ ] Les post-mortems sont blameless : ce qui s'est passe, pourquoi, comment eviter que ca se reproduise
+- [ ] La communication est adaptee au public : C4 level 1 pour stakeholders, level 3 pour devs
+- [ ] Les PR descriptions expliquent le contexte et les trade-offs — pas juste "fixes bug"
+
+## Anti-patterns
+### Documentation dans un outil separe
+**Ce qu'on voit :** specs dans Confluence, designs dans Notion, decisions dans Trello, code dans GitHub. Rien n'est a jour. Personne ne trouve rien.
+**Pourquoi c'est dangereux :** la documentation eloignee du code est de la documentation morte. Elle n'est pas versionnee avec le code qu'elle decrit. Elle n'est pas revue en PR. Elle pourrit independamment. Le nouveau dev lit la spec Confluence de 2023 et code un feature deja deprecie.
+**Faire plutot :** documentation dans le repo, en markdown, a cote du code qu'elle documente. `docs/architecture.md`, `docs/adrs/`, `services/orders/README.md`. La doc se review en PR comme le code. Si le code change, la doc change dans le meme commit.
+
+### Diagramme = oeuvre d'art
+**Ce qu'on voit :** 3 jours passes a faire un diagramme UML parfait dans un outil proprietaire. Le diagramme est beau. Le code change 2 semaines plus tard. Le diagramme n'est plus a jour et ne peut pas etre modifie (outil perdu, licence expiree).
+**Pourquoi c'est dangereux :** un diagramme est un outil de communication, pas un livrable. Passer 3 jours sur un diagramme qui sera obsolet dans 2 semaines est du gaspillage. L'outil proprietaire cree un barrier a la modification → le diagramme pourrit.
+**Faire plutot :** diagrammes en texte (Mermaid, PlantUML, Graphviz). Versionnes dans le repo. Render automatiquement dans la CI. Assez bons pour communiquer, pas parfaits. Si le diagramme prend plus d'1h, c'est qu'il est trop detaille.
+
+### Post-mortem = blame game
+**Ce qu'on voit :** incident → "qui a deploye ca ?" → recherche de coupable → le dev qui a deploye est blame. Prochaine fois, personne n'osera deployer.
+**Pourquoi c'est dangereux :** chercher un coupable garantit que les incidents futurs seront caches, pas corriges. Les gens ne signalent pas les quasi-incidents. La peur remplace l'apprentissage. L'organisation devient fragile parce qu'elle ne corrige pas ses processus.
+**Faire plutot :** post-mortem blameless. L'incident est cause par le SYSTEME, pas par l'individu. "Qu'est-ce qui dans notre processus a permis cette erreur ?" Action concrete sur le processus pour que ca ne se reproduise pas. L'auteur du deploiement participe au post-mortem sans crainte.
+
+## Patterns
+### C4 Model
+**Quand :** expliquer l'architecture a differents publics.
+**Comment :** 4 niveaux. Level 1 (Context) : le systeme dans son environnement — pour les stakeholders. Level 2 (Containers) : les briques majeures (app, DB, file system) — pour l'equipe tech elargie. Level 3 (Components) : l'interieur de chaque container — pour les devs. Level 4 (Code) : diagramme de classes — seulement si necessaire. Toujours commencer par le niveau 1, toujours avoir un titre et une legende.
+
+### Spec writing
+**Quand :** feature de > 1 semaine.
+**Comment :** ecrire la spec AVANT de coder. Sections : Problema (quoi et pourquoi), Solution proposee (comment), Alternatives considerees, Impact (migration, cout, risques), Plan de test. Review d'equipe avant implementation. La spec peut etre courte (1-2 pages) — le but est l'alignement, pas la perfection.