@neikyun/ciel 6.11.2 → 6.13.0

package/assets/skills/meta/skill-variant-evaluator/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: skill-variant-evaluator
+description: AutoResearch eval runner that generates 2-3 variants of a skill, executes them headlessly against binary eval datasets, compares aggregate scores, and proposes the winner with tiebreak on token usage. Use when /ciel-eval is invoked or when ciel-improve needs to pick between candidate rewrites.
+allowed-tools: Read, Bash, Glob
+---
+
+# skill-variant-evaluator — AutoResearch eval harness
+
+## What this covers
+Implements Karpathy-style AutoResearch for Ciel skills: define binary evals, run variants, compare scores, keep the winner.
+
+## Core principle
+**Binary evals, not vibes.** Every skill improvement is measured against concrete pass/fail criteria. The variant with the highest score wins.
+
+## Inputs
+
+- **skill-path**: path to `SKILL.md`
+- **variants** (optional): 2-3 candidate SKILL.md contents
+- **dataset**: eval dataset in `evals/datasets/<name>.jsonl`
+- **baseline-only**: boolean — only score current skill, no variants
+
+## Process
+
+### 1. Locate eval dataset
+
+Look for `evals/datasets/<skill-name>.jsonl`. If missing, warn and exit.
+
+### 2. Load variants
+
+- Variant A: current SKILL.md (baseline)
+- Variants B, C: alternatives provided or from `variants/`
+
+### 3. Execute each variant headlessly
+
+For each variant:
+1. Write to `SKILL.md.eval.<letter>`
+2. For each eval entry, run `claude --print` with the eval prompt
+3. Capture output + token usage + duration
+4. Score against `expected_behavior` criteria (binary per criterion)
+
+### 4. Aggregate scores
+
+`aggregate = sum(criteria_passed) / total_criteria`
+
+Winner = highest aggregate. Tiebreak: lowest total token usage.
+
+### 5. Persist results
+
+Write to `evals/results/<skill-name>-<timestamp>.json`.
+
+## Common patterns
+
+### Good eval result
+
+```
+# Skill variant evaluation — flux-narrator
+
+Dataset: evals/datasets/flux-narration.jsonl (8 entries)
+
+| Variant | Score | Tokens | Duration |
+|---------|-------|--------|----------|
+| A (baseline) | 0.72 | 14.5k | 12.5s |
+| B (tightened) | 0.89 | 15.1k | 13.2s ← WINNER |
+| C (reduced) | 0.81 | 12.8k | 11.7s |
+
+Winner: **Variant B** (+0.17 over baseline)
+Recommendation: adopt Variant B.
+```
+
+### Bad eval result
+
+```
+Variant B seems better. Use it.
+```
+
+Problems: no scores, no comparison table, no dataset reference.
+
+## Anti-patterns
+
+- **Dataset > 20 entries** — cap to prevent runaway costs
+- **> 3 variants** — no clear winner possible
+- **Token cost > 500k without confirmation** — estimate first
+- **Overwriting SKILL.md** — variants go to `.eval.<letter>` files
+- **Not cleaning up** — delete `.eval.<letter>` temp files after results persisted
+
+## How to verify
+
+- [ ] Dataset exists and loaded?
+- [ ] All variants executed?
+- [ ] Scores aggregated correctly?
+- [ ] Winner identified with tiebreak if needed?
+- [ ] Results persisted to `evals/results/`?
+- [ ] Temp files cleaned up?
+- [ ] Token cost within budget?
+
+## When triggered
+
+- User runs `/ciel-eval [skill-name]`
+- `ciel-improve` calls this for each proposed patch
+- `improver` agent invokes this as part of its loop

package/assets/skills/meta/skills-first-design-auditor/SKILL.md

@@ -0,0 +1,192 @@
+---
+name: skills-first-design-auditor
+description: Lints and audits Agent Skills (Anthropic format) for design quality — frontmatter completeness, body length ≤500 lines, presence of 2-3 concrete examples, verification scripts for critical checks, clear WHEN-triggered section, and alignment with the 6 principles from Anthropic's April 2026 skills guide. Used by @ciel-improver when creating or reviewing a skill.
+allowed-tools: Read, Grep, Glob, Bash
+context: fork
+agent: improver
+---
+
+# skills-first-design-auditor — Good skills discover themselves
+
+A skill that doesn't auto-activate is just a document. Anthropic's April 2026 guide ("Equipping Agents for the Real World with Agent Skills") codifies what makes a skill actually useful to an agent. This skill audits against those principles.
+
+---
+
+## Inputs
+
+```
+SKILL_PATH: [absolute path to a SKILL.md file OR a directory containing SKILL.md + companions]
+```
+
+---
+
+## The 6 principles (Anthropic April 2026)
+
+### 1. Evaluation-driven design
+
+The skill must encode a capability the agent ACTUALLY lacks. Don't add skills that duplicate what the base model does well.
+
+**Audit**: is there evidence (a failing eval, a user complaint, a prior incident) that motivated this skill? → Check git history / CHANGELOG entry.
+
+### 2. Searchable frontmatter
+
+`description` must be specific enough that agents invoke it via semantic search. "Helps with code" is USELESS; "Validates that each proposed external API call exists in the pinned version's official documentation" is GOOD.
+
+**Audit**:
+- `name`: kebab-case, < 40 chars
+- `description`: 1-3 sentences, names the trigger condition AND the output
+- `allowed-tools`: present, minimal (`Read, Grep` not `*`)
+- Agent field if applicable (`agent: critic` / `agent: researcher` / ...)
+
+### 3. Body ≤ 500 lines
+
+Skills are loaded into agent context. A 2000-line skill burns 5k tokens just to be available. If the body exceeds 500 lines:
+
+- Split into a core SKILL.md + reference docs in the same folder
+- Link from SKILL.md to the references; agent fetches them on demand
+
+**Audit**: `wc -l SKILL.md`. Frontmatter doesn't count. 500-700 lines = WARN. >700 = BLOCK.
+
+### 4. Concrete examples, not abstract prose
+
+Each skill body must contain 2-3 examples showing input → reasoning → output. Not "the skill handles X" — an actual trace.
+
+**Audit**: grep for `### Example` or `#### Example` or ```` ```<lang> `` code blocks with realistic values. 0 examples = BLOCK. 1 example = WARN. 2+ = PASS.
+
+### 5. Verification scripts for critical checks
+
+If the skill includes a "is this condition met?" check, that check should be executable (bash, python, grep), not a prose instruction telling the agent to "verify visually". Executable checks are reliable; prose checks degrade.
+
+**Audit**: does the PROCESS section contain at least one runnable command per check? If all checks are prose ("verify the input is valid") → WARN.
+
+### 6. Clear WHEN-triggered section
+
+The skill must state explicitly when it activates: which step of the pipeline, which agent dispatches it, which user command. Without this, auto-activation via description-matching misfires.
+
+**Audit**: presence of a `## When triggered` section (or equivalent) with at least 2 concrete triggers.
+
+---
+
+## Ciel-specific additions
+
+### A. Consistency with existing skills
+
+- Same section order as peer skills in the same category (workflow/ research/ domain/ utility/ meta)
+- Same frontmatter field ordering (`name`, `description`, `allowed-tools`, `context`, `agent`)
+- Output format uses `##` + `###` hierarchy consistent with `relire-critic` style
+
+### B. No duplication
+
+Before approving a new skill, grep the existing 36 skills for overlap. If the new skill covers ≥70% of an existing skill's scope → reject or merge.
+
+### C. Dispatch target aligned
+
+`agent: <role>` must match where the skill logically fits:
+- **researcher** — external investigation, doc fetching, source validation
+- **explorer** — codebase reading, pattern detection, domain knowledge
+- **critic** — post-write review, hostile analysis, correctness checking
+- **improver** — meta-level, auditing other skills or the system itself
+
+Wrong `agent:` = skill won't be dispatched via the right fork context.
+
+---
+
+## Audit output format
+
+```
+## SKILL AUDIT: <name>
+
+### Frontmatter
+[✓] name: kebab-case, 22 chars
+[✓] description: specific, names trigger + output
+[✓] allowed-tools: minimal (Read, Grep, Glob, Bash)
+[✓] agent: explorer (aligned with body content)
+
+### Body
+[✓] Length: 342 lines (under 500)
+[✓] Examples: 3 (passes minimum 2)
+[✓] Executable checks: 4 (grep commands, wc -l, etc.)
+[✓] "When triggered" section: present, 4 triggers listed
+
+### Principles
+[✓] 1. Evaluation-driven — CHANGELOG v2.1.0 references ISSTA 2025 gap
+[✓] 2. Searchable frontmatter
+[✓] 3. Body ≤500 lines
+[✓] 4. Concrete examples
+[✓] 5. Verification scripts
+[✓] 6. WHEN-triggered clarity
+
+### Ciel-specific
+[✓] Consistent section order with peer skills in workflow/
+[✓] No overlap with existing skills (checked: pattern-fitness-check, flux-narrator)
+[✓] agent field matches skill content (explorer for codebase-reading)
+
+### Findings
+(none — skill passes audit)
+
+### Verdict
+PASS — ready to ship
+```
+
+---
+
+## Typical issues found (with fixes)
+
+### Issue: vague description
+```yaml
+# BAD
+description: Helps with code review.
+# GOOD
+description: Generates 3 hostile critiques per changed file (1 functional, 1 import, 1 data-assumption) and resolves each with FIX/ACCEPT/DEFER. Invoked by the PostToolUse hook on Write/Edit for Standard/Critical tasks with 3+ changed files.
+```
+
+### Issue: no examples
+Add at least 2 concrete `### Example` blocks showing input → skill output. Prose-only skills don't transfer knowledge well; examples anchor behavior.
+
+### Issue: missing WHEN section
+Add section listing: (a) pipeline step, (b) dispatching agent, (c) user command triggers. 4-6 bullets is plenty.
+
+### Issue: overbroad allowed-tools
+```yaml
+# BAD
+allowed-tools: "*"
+# GOOD
+allowed-tools: Read, Grep, Glob, Bash
+```
+
+---
+
+## How to verify
+
+- [ ] All 6 Anthropic principles checked?
+- [ ] Frontmatter audit complete (name, description, allowed-tools, agent)?
+- [ ] Body length measured (wc -l)?
+- [ ] Examples counted (grep for Example blocks)?
+- [ ] Verification scripts checked (executable vs prose)?
+- [ ] WHEN-triggered section present?
+- [ ] Ciel-specific checks (consistency, no duplication, dispatch target)?
+
+## Guardrails
+
+- **Don't auto-fix, just audit** — propose changes in the report; let the human/improver decide.
+- **Don't re-audit on every commit** — this is a "when a skill is added or significantly edited" task.
+- **Prior-session skills** count under principle 1 — if the skill came from a past Ciel iteration and was never re-validated, flag for re-evaluation.
+- **Skills in `skills/meta/`** should be extra strict — they shape how the system grows.
+- **Exceptions allowed** — a meta skill legitimately exceeds 500 lines if it encodes a taxonomy; document the rationale in a comment at the top of the file.
+
+---
+
+## When triggered
+
+- `@ciel-improver` on `/ciel-create-skill`
+- PR touching `skills/**/SKILL.md`
+- Before merging a skill from a research branch
+- Quarterly sweep across all skills (release gate)
+
+---
+
+## References
+
+- Anthropic April 2026 — "Equipping Agents for the Real World with Agent Skills" — anthropic.com/engineering
+- Anthropic Skills intro — anthropic.skilljar.com/introduction-to-agent-skills
+- Claude API docs — platform.claude.com/docs/en/agents-and-tools/agent-skills/overview

package/assets/skills/ml-engineering/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: ml-engineering
+description: "ML Engineering — pipelines ML, feature stores, model serving, drift detection, MLOps, experiment tracking. A charger quand on met en production des modeles ML."
+---
+
+# ML Engineering
+
+**Principe premier :** Le ML engineering n'est pas "entrainer un modele avec le meilleur score" — c'est mettre un modele en production et garantir qu'il reste performant dans le temps. La metrique qui compte n'est pas l'accuracy sur le dataset de test (qui est un instantane du passe) — c'est la performance en production sur les donnees de demain. Un modele est un programme qui se degrade passivement : le monde change, les distributions derivent, et un modele a 98% de precision aujourd'hui peut tomber a 72% dans 6 mois sans que personne ne le sache. La difference entre un notebook Jupyter et un systeme ML de production, c'est le monitoring, le versioning, et la capacite a re-entrainer.
+
+## Checklist
+- [ ] Les donnees sont versionnees (DVC, LakeFS, Delta Lake) — pas de `dataset_v3_final_FINAL.csv`
+- [ ] Les experiences sont trackees (MLflow, W&B, ClearML) avec hyperparametres, code version, dataset version
+- [ ] Le feature store est la source unique de verite pour les features — pas de features calculees differemment en train et en inference
+- [ ] Le serving est monitorise : latence P95, taux d'erreur, distribution des predictions
+- [ ] Le data drift ET le concept drift sont monitorises — alerter quand la distribution change
+- [ ] Le pipeline d'entrainement est reproductible (DAG, conteneurise, versionne)
+- [ ] Le rollback de modele est aussi simple que le rollback de code (model registry avec versioning)
+
+## Anti-patterns
+### Notebook → production
+**Ce qu'on voit :** le data scientist donne son notebook "il marche sur mon laptop". L'ingenieur le copie-colle dans un endpoint. 2000 lignes de code non structure.
+**Pourquoi c'est dangereux :** un notebook n'est pas un programme — c'est un journal d'exploration. Pas de gestion d'erreur, pas de typage, pas de tests, pas de reproductibilite (execution ordonnee non garantie). Les imports sont eparpilles, les variables persistent entre cellules, le code est impossible a maintenir.
+**Faire plutot :** le notebook est un outil d'exploration. Le code de production est dans des modules Python standards, versionnes, testes. Le data scientist et le ML engineer travaillent ensemble sur la transition notebook → module. Le notebook documente l'intention, le module implemente la production.
+
+### Features train/serve inconsistantes
+**Ce qu'on voit :** les features sont calculees en Python (pandas) pour l'entrainement, et en Go/Java dans le serving. Implementation differente → comportement different → modele qui performe mal en production sans raison apparente.
+**Pourquoi c'est dangereux :** c'est le bug le plus pernicieux en ML. Les metriques d'entrainement sont bonnes, les tests passent, mais le modele est mauvais en production. La cause est quasi impossible a debugger sans comparer les implementations feature par feature.
+**Faire plutot :** feature store central. Les memes features, calculees par le meme code, servent l'entrainement ET l'inference. Si le calcul change, le feature store versionne. Zero implementation divergente.
+
+### Drift = surprise
+**Ce qu'on voit :** pas de monitoring du drift. Le modele se degrade lentement. 6 mois plus tard, un utilisateur remarque que les predictions sont mauvaises.
+**Pourquoi c'est dangereux :** la degradation est silencieuse et graduelle. Le modele ne crash pas — il devient juste de plus en plus mauvais. Les decisions basees sur ces predictions deviennent de plus en plus mauvaises. Le MTTD (mean time to detect) est de 6 mois.
+**Faire plutot :** monitoring continu de la distribution des features en production vs distribution d'entrainement (data drift). Monitoring des predictions (concept drift : relation feature → cible qui change). Alerter quand la divergence depasse un seuil. Re-entrainement automatise ou manuel selon la criticite.
+
+## Patterns
+### Model registry
+**Quand :** plusieurs modeles en production ou re-entrainements frequents.
+**Comment :** MLflow Model Registry, Seldon, ou Sagemaker Model Registry. Chaque modele a : version, metriques, dataset d'origine, artefact, statut (staging/production/archived). Promotion staging → production via CI/CD. Rollback = pointer vers la version precedente en un clic.
+
+### Feature store
+**Quand :** features reutilisees entre plusieurs modeles ou entre train/serving.
+**Comment :** Feast, Tecton, ou solution interne. Les features sont definies une fois, calculees offline (batch) et servies online (low latency). Le feature store garantit la consistance entre train et serve. Chaque feature est versionnee et documentee.

package/assets/skills/mobile/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: mobile
+description: "Mobile — iOS/Android/React Native/Flutter, offline-first, batterie, store review, push notifications. A charger quand on developpe une application mobile."
+---
+
+# Mobile
+
+**Principe premier :** Le mobile n'est pas "un petit ecran" — c'est un environnement hostile. Reseau instable (tunnel → metro → edge → 3G), batterie limitee, stockage restreint, OS qui peut killer l'app a tout moment. Si ton app ne fonctionne pas dans un tunnel avec 1 barre de 3G et 10% de batterie, elle ne fonctionne pas. Le store (App Store, Play Store) est ton canal de distribution mais aussi ton gatekeeper — chaque release est une revue humaine qui peut etre rejetee. Le mobile recompense l'optimisme offline et le pessimisme reseau : suppose toujours que le reseau est lent, cher, et hostile.
+
+## Checklist
+- [ ] Offline-first : l'app fonctionne sans reseau — donnees en cache local, actions en file d'attente
+- [ ] Les images sont lazy-loadees et resizees (pas de 4K telecharge sur un ecran 400px de large)
+- [ ] La batterie est respectee : pas de polling every 5s, pas de wake lock permanent, pas de GPS continu
+- [ ] Le state est preserve a travers les kills d'OS (serialisation automatique du state critique)
+- [ ] Les crashs sont reportes (Crashlytics, Sentry) — pas de "ca crash sur le telephone de Julie"
+- [ ] Les updates sont gerees : forced update si API incompatible, optional update sinon
+- [ ] Le stockage local a un TTL et une limite de taille — pas de cache infini qui remplit le telephone
+
+## Anti-patterns
+### Mobile = site web en webview
+**Ce qu'on voit :** une webview qui charge le site responsive. Publie sur les stores. "Ca marche sur mobile."
+**Pourquoi c'est dangereux :** zero integration native. Pas de push notifications, pas de stockage offline, pas de gestures natives, pas de transition fluide. Les utilisateurs le sentent immediatement et desinstallent. Les stores peuvent rejeter si l'app n'apporte rien par rapport au site.
+**Faire plutot :** si le contenu est statique → PWA (plus leger, pas besoin de store). Si besoin natif (push, camera, offline) → app native ou React Native/Flutter avec vrais composants natifs.
+
+### Optimiste sur le reseau
+**Ce qu'on voit :** l'app suppose que le reseau est disponible et rapide. Pas de cache, pas de queue offline, pas de gestion d'erreur reseau. L'app affiche un spinner blanc des que le reseau est lent.
+**Pourquoi c'est dangereux :** le reseau mobile est le pire reseau de tous les clients. L'utilisateur est dans un ascenseur, un metro, une cave, une campagne. Si l'app ne fonctionne pas offline, elle est inutilisable 30% du temps. L'utilisateur ouvre l'app concurrente.
+**Faire plutot :** cache local (SQLite, Realm, WatermelonDB). Sync en arriere-plan quand le reseau est disponible. UI qui montre les donnees en cache immediatement, puis rafraichit. Indicateur "donnees de X minutes" plutot qu'un spinner.
+
+### Release = pari
+**Ce qu'on voit :** soumission sur le store sans test de recette. Rejet pour violation de guideline. 3 jours de delai. Corrections en catastrophe.
+**Pourquoi c'est dangereux :** le store review est un processus humain, lent, et imprevisible. Un rejet decale la release de 3-7 jours. Les utilisateurs attendent, les bugs critiques restent en production.
+**Faire plutot :** pre-release checklist (guidelines store, screenshots, permissions documentees). TestFlight/Internal Testing pour valider le binaire avant soumission. Soumission en debut de semaine pour maximiser les chances de review rapide.
+
+## Patterns
+### Offline-first avec sync queue
+**Quand :** app qui modifie des donnees (notes, taches, commandes).
+**Comment :** ecriture locale immediate → queue de synchronisation → synchro background quand online. Resolution de conflits : last-write-wins pour donnees simples, merge pour donnees complexes. UI qui montre l'etat de synchro (sync, synced, error).
+
+### Gradual rollout sur stores
+**Quand :** release avec risque (refonte, nouvelle fonctionnalite).
+**Comment :** Play Store : staged rollout (10% → 50% → 100% avec possibilite de halt). App Store : phased release sur 7 jours. Monitoring des crashs et des ratings par version. Rollback en arretant le rollout (pas besoin de nouvelle soumission).

package/assets/skills/monitoring/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: monitoring
+description: "Monitoring — RED/USE metrics, SLI/SLO/SLA comme contrats, dashboards comme outils de debugging, alerting fatigue. À charger quand on met en place du monitoring."
+---
+
+# Monitoring
+
+**Principe premier :** Le monitoring n'est pas "avoir des dashboards" — c'est pouvoir répondre à deux questions en < 30 secondes : "est-ce que le système fonctionne ?" et "si non, qu'est-ce qui a changé ?". Si tes dashboards ne répondent pas à ça, ils sont du bruit visuel. La métrique fondamentale n'est pas le nombre de graphiques — c'est le Mean Time To Detect (MTTD). Combien de temps entre le début de l'incident et la première alerte ? Si la réponse est "quand un client ouvre un ticket", ton monitoring a échoué.
+
+## Checklist
+- [ ] RED metrics par service : Rate, Errors, Duration (P50/P95/P99) — collectées via Prometheus, exposées sur `/metrics`
+- [ ] USE metrics par ressource : Utilization, Saturation, Errors — node_exporter/cAdvisor → Prometheus → Grafana
+- [ ] Dashboards, règles Prometheus, et config AlertManager sont dans le repo (monitoring as code) — pas créés à la main dans l'UI Grafana
+- [ ] Dashboards Grafana avec seuils visuels (vert/jaune/rouge) — pas juste des lignes sur un graphique
+- [ ] SLI définis (ce qu'on mesure), SLO documentés (l'objectif), SLA communiqués (la promesse)
+- [ ] Alertes sur les signaux critiques uniquement — pas d'alerte sur "CPU > 70% pendant 30s à 3h du matin"
+- [ ] Runbook associé à chaque alerte — "si cette alerte sonne, voici quoi faire"
+
+## Anti-patterns
+### Dashboard = décoration
+**Ce qu'on voit :** un écran mural avec 50 graphiques, pas de titre, pas d'échelle, pas de seuil. Personne ne le regarde. Les incidents sont découverts par les utilisateurs.
+**Pourquoi c'est dangereux :** un dashboard sans contexte n'est pas un outil — c'est du bruit. Les anomalies sont noyées dans la masse de données non interprétables. Le MTTD est infini.
+**Faire plutôt :** un dashboard par service. Titre explicite. Description : "Ce dashboard montre la santé du service X. Si ce graphique est rouge, regarder Y." Seuils visuels. Maximum 10 métriques par dashboard. Le dashboard doit permettre de répondre "est-ce que c'est normal ?" en un coup d'œil.
+
+### Alerte sur tout
+**Ce qu'on voit :** 200 alertes configurées. "CPU > 50%", "mémoire > 60%", "disque > 70%". 15 alertes par nuit. L'équipe a muté le canal. Les vraies urgences sont ignorées.
+**Pourquoi c'est dangereux :** l'alert fatigue est réelle. Chaque fausse alerte entraîne la suivante vers l'ignorance. Quand une vraie alerte critique arrive, personne ne la voit parce que tout le monde a appris que "les alertes = du bruit".
+**Faire plutôt :** alerter sur les SYMPTÔMES, pas sur les causes potentielles. "P95 latency > 1s pendant 5 min" (symptôme utilisateur), pas "CPU > 70%" (cause possible). Chaque alerte doit être actionable — si tu ne peux pas écrire le runbook en 3 étapes, ne crée pas l'alerte.
+
+### Monitoring = dashboards Grafana
+**Ce qu'on voit :** tout est dans Grafana. Pas de logs structurés, pas de tracing, pas d'alerting. "On regardera le dashboard si quelqu'un se plaint."
+**Pourquoi c'est dangereux :** le monitoring sans observabilité, c'est regarder le tableau de bord de ta voiture. Tu vois que la vitesse est à 0, mais tu ne sais pas POURQUOI. Les dashboards montrent les symptômes, les logs et traces montrent les causes. L'un sans l'autre = tu sais que c'est cassé, pas pourquoi.
+**Faire plutôt :** monitoring (métriques + dashboards + alertes) + logging (logs structurés JSON + correlation ID) + tracing (OpenTelemetry, traces distribuées). Les trois piliers de l'observabilité.
+
+## Patterns
+### Prometheus + Grafana (stack standard)
+**Quand :** toute application en production.
+**Comment :** Prometheus scrape les métriques exposées par l'app (`/metrics`). Grafana interroge Prometheus (PromQL) et affiche les dashboards. Pas de solution propriétaire — cette stack est le standard ouvert, toutes les bibliothèques l'implémentent. Chaque service expose ses propres métriques RED, l'infrastructure expose les USE via node_exporter / cAdvisor.
+
+### RED method (services)
+**Quand :** monitoring de tout service (API, worker, etc.).
+**Comment :** Rate (requêtes/s), Errors (taux d'erreur), Duration (P50/P95/P99) via histogram Prometheus. 3 métriques par endpoint. Couvre l'expérience utilisateur. PromQL : `rate(http_requests_total[5m])`, `rate(http_errors_total[5m])`, `histogram_quantile(0.95, rate(http_duration_bucket[5m]))`.
+
+### USE method (ressources)
+**Quand :** monitoring de toute ressource (CPU, RAM, disque, réseau, DB pool).
+**Comment :** Utilization (% utilisé), Saturation (file d'attente), Errors (compteur d'erreurs) via node_exporter. 3 métriques par ressource. Dashboard Grafana avec seuils vert/jaune/rouge. Si Utilization > 80%, si Saturation > 0, si Errors > 0 — investiguer.
+
+### SLO-based alerting
+**Quand :** définir les alertes sans tomber dans l'alert fatigue.
+**Comment :** définir un SLO (ex: "99.9% des requêtes < 500ms sur 30 jours"). L'alerte se déclenche quand le error budget est consommé trop vite (ex: 5% du budget mensuel en 1h). Configurer dans AlertManager via Prometheus rules : `alert: HighErrorBurnRate`, `expr: rate(http_errors_total[1h]) / rate(http_requests_total[1h]) > 0.05`.
+
+### Monitoring as Code (dashboards + rules dans le repo)
+**Quand :** toute équipe de plus d'une personne.
+**Comment :** dashboards Grafana en JSON (Grafonnet pour les générer), règles Prometheus en YAML, config AlertManager en YAML — tout dans `monitoring/` du repo. Déploiement via CI/CD (Terraform, Grafana provisioning API). PR pour chaque changement de dashboard ou alerte. Le monitoring est de l'infrastructure — le même niveau de rigueur que le Terraform de prod.

package/assets/skills/networking/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: networking
+description: "Networking — le reseau comme fondation invisible. DNS, TLS, HTTP/2/3, VPC, firewall, load balancing. A charger quand on configure des connexions ou debug la connectivite."
+---
+
+# Networking
+
+**Principe premier :** Le reseau n'est pas "ce qui connecte les machines" — c'est la couche de securite zero. Avant que ton application ne recoive un octet, le reseau a deja pris 100 decisions : routage, filtrage, terminaison TLS, rate limiting. Un reseau bien configure rend 80% des attaques impossibles avant meme qu'elles n'atteignent l'application. Le probleme inverse : un reseau mal configure est invisible jusqu'a l'incident — "pourquoi le service B ne peut pas parler au service C en prod ?" La connectivite n'est jamais acquise — elle est configuree, testee, monitorisee.
+
+## Checklist
+- [ ] DNS est configure avec TTL raisonnable (300s pour APEX, 60s pour failover) — pas de TTL de 86400s
+- [ ] TLS >= 1.2 partout, TLS 1.3 pour les services internes — pas de TLS 1.0/1.1, pas de SSL
+- [ ] Les certificats sont auto-renouveles (LetsEncrypt, cert-manager, ACM) — pas d'expiration surprise
+- [ ] Firewall : seuls les ports necessaires sont ouverts. SSH (22) restreint par IP source
+- [ ] Les VPC/VNET sont isoles par environnement (dev/staging/prod) avec peering explicite
+- [ ] HTTP/2 ou HTTP/3 active — multiplexing, header compression, 0-RTT
+- [ ] Le load balancer a un health check actif (pas juste TCP connect — verifier le endpoint)
+
+## Anti-patterns
+### "C'est un probleme reseau"
+**Ce qu'on voit :** chaque bug de connexion est blame sur "le reseau". Personne ne debug. Le probleme persiste 3 semaines.
+**Pourquoi c'est dangereux :** le reseau est un bouc emissaire facile parce qu'il est invisible. En realite, la plupart des problemes "reseau" sont des problemes d'application : timeout trop court, DNS cache, certificat expire, mauvais endpoint. Dire "c'est le reseau" sans preuve = arreter de chercher.
+**Faire plutot :** debug methodique : `dig` (DNS), `curl -v` (TLS + HTTP), `traceroute` (routage), `telnet host port` (connectivite brute). Chaque couche se teste independamment. Le probleme est toujours sur UNE couche specifique.
+
+### Firewall = apres coup
+**Ce qu'on voit :** le firewall est configure "quand tout marche" (jamais). Tous les ports sont ouverts "pour pas etre bloque".
+**Pourquoi c'est dangereux :** le firewall est la premiere ligne de defense. Sans regles strictes, une application vulnerable sur un port oublie = acces non autorise. Le firewall interne (entre services) est aussi important que l'externe.
+**Faire plutot :** deny-all par defaut. Ouvrir uniquement les flux documentes. Chaque regle a un commentaire (pourquoi ce port, pour quel service). Revue trimestrielle des regles.
+
+### DNS comme apres-pensee
+**Ce qu'on voit :** TTL = 86400 (24h). Changement de serveur → 24h de propagation. Les utilisateurs voient l'ancienne IP. Ou pire : `CNAME` court-circuite avec un `A` record parce que "c'est plus simple".
+**Pourquoi c'est dangereux :** DNS est le premier maillon de toute connexion. Un TTL trop long empeche le failover rapide. Un mauvais enregistrement = outage total. Le DNS est la fondation — tout repose dessus.
+**Faire plutot :** TTL courts pour les endpoints critiques (60-300s). Records A/AAAA pour la racine, CNAME pour les sous-domaines. Monitoring de resolution DNS depuis plusieurs points geographiques.
+
+## Patterns
+### Defense en profondeur reseau
+**Quand :** architecture multi-services.
+**Comment :** WAF/CDN (couche 1) → Load Balancer + TLS termination (couche 2) → Network ACL/VPC firewall (couche 3) → Security Group par service (couche 4). Chaque couche suppose que la precedente a echoue. Aucune couche ne fait confiance a la precedente.
+
+### Zero Trust networking
+**Quand :** services distribues, multi-cloud, ou travailleurs distants.
+**Comment :** pas de "reseau interne de confiance". Chaque appel est authentifie (mTLS, JWT, SPIFFE). Le reseau est hostile par defaut — les services ne se font pas plus confiance entre eux qu'a Internet. C'est le principe inverse du "perimetre de securite".

package/assets/skills/nosql/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: nosql
+description: "NoSQL — MongoDB/DynamoDB/Redis, modeling around access patterns, single-table design, hot partition avoidance. À charger quand on choisit ou utilise du NoSQL."
+---
+
+# NoSQL
+
+**Principe premier :** NoSQL n'est pas "SQL sans schéma" — c'est un trade-off fondamental : tu échanges la flexibilité des requêtes (tu ne peux pas tout JOINer) contre la scalabilité horizontale (tu peux sharder). Ce trade-off est le SEUL critère valide pour choisir NoSQL. Si tu n'as pas de problème de scale horizontal que SQL ne résout pas, NoSQL est un downgrade, pas une modernisation. Le modeling NoSQL se fait à l'envers du relationnel : tu pars des requêtes (qu'est-ce que je dois lire en une opération ?) et tu construis le modèle autour.
+
+## Checklist
+- [ ] Le choix NoSQL est justifié par le scale horizontal, pas par "c'est plus simple"
+- [ ] Le modèle de données est conçu autour des access patterns (et pas l'inverse)
+- [ ] La partition key a une haute cardinalité et une distribution uniforme
+- [ ] Les index secondaires (GSI) sont justifiés — chaque GSI coûte de l'argent et de la latence
+- [ ] La stratégie de dénormalisation est documentée : quelle donnée est dupliquée, où, pourquoi
+- [ ] Les TTL sont configurés pour les données temporaires — pas de job de nettoyage manuel
+
+## Anti-patterns
+### Modélisation relationnelle dans NoSQL
+**Ce qu'on voit :** 12 `$lookup` (MongoDB) pour reproduire un JOIN. 50 `GetItem` séquentiels (DynamoDB) parce que les données sont dans des items séparés.
+**Pourquoi c'est dangereux :** NoSQL n'est pas optimisé pour les JOINs. Chaque `$lookup` est un scan coûteux. Chaque `GetItem` est une requête réseau. 50 requêtes séquentielles DynamoDB = 500ms de latence minimum contre 10ms pour un JOIN SQL. Tu paies le prix du NoSQL sans le bénéfice.
+**Faire plutôt :** pre-joindre. Si les données sont lues ensemble, elles sont stockées ensemble (single document/item). Le modèle reflète les patterns d'accès — une requête = un read.
+
+### Hot partition / hot key
+**Ce qu'on voit :** partition key = `status` avec 90% des items à `status = "active"`. Ou pire, partition key = `tenant_id` et un tenant fait 80% du trafic.
+**Pourquoi c'est dangereux :** en NoSQL, les partitions sont l'unité de scale. Une partition chaude = tout le trafic sur un seul shard = throttling (DynamoDB) ou performance dégradée (MongoDB). Le scale horizontal est neutralisé par une mauvaise clé.
+**Faire plutôt :** partition key à haute cardinalité et distribution uniforme. `user_id`, `order_id`, pas de `status` ou `type`. Si un tenant est plus gros, sharder par `tenant_id#entity_id` (composite key).
+
+### Redis comme source de vérité
+**Ce qu'on voit :** toutes les données métier dans Redis. `FLUSHALL` ou reboot = toutes les données perdues. "Mais j'ai configuré la persistence" — qui n'a jamais été testée.
+**Pourquoi c'est dangereux :** Redis est conçu comme un cache/queue/session store en mémoire. La persistence Redis (RDB/AOF) est asynchrone et non garantie. Même avec AOF everysec, tu peux perdre les 2 dernières secondes d'écritures.
+**Faire plutôt :** PostgreSQL/MySQL/DynamoDB pour la source de vérité. Redis pour cache, sessions, rate limiting, queues temporaires. Si Redis est flush, l'app dégrade mais ne perd pas de données métier.
+
+## Patterns
+### Single-table design (DynamoDB)
+**Quand :** plusieurs types d'entités avec des access patterns différents.
+**Comment :** une table. PK = `TYPE#id`, SK = `RELATION#id`. Les GSI inversent PK/SK pour les autres patterns. Un user et ses orders sont dans la même table, lus en une query. Pas de JOIN.
+
+### TTL index
+**Quand :** données temporaires (sessions, cache, logs éphémères).
+**Comment :** champ `expires_at` en epoch seconds + TTL index. La DB supprime automatiquement. Pas de cron job. Pas de nettoyage manuel. Gratuit (DynamoDB) ou quasi-gratuit.

package/assets/skills/oop-solid/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: oop-solid
+description: "OOP & SOLID — classes, objets, heritage, composition, encapsulation, principes SOLID comme garde-fous. A charger quand on travaille avec des classes."
+---
+
+# OOP & SOLID
+
+**Principe premier :** SOLID n'est pas un dogme — c'est un systeme d'alerte precoce. Chaque principe ne te dit pas quoi faire, il te dit QUAND le design est en train de pourrir. Single Responsibility = ta classe a plus d'une raison de changer. Open/Closed = tu modifies du code existant au lieu d'etendre. Liskov = ta sous-classe ne peut pas remplacer la classe mere. Interface Segregation = tes clients dependent d'interfaces qu'ils n'utilisent pas. Dependency Inversion = tes modules de haut niveau dependent des bas niveau. Le but n'est pas un score SOLID parfait — c'est un code qui accepte le changement sans se briser. La composition est par defaut, l'heritage est l'exception.
+
+## Checklist
+- [ ] Chaque classe a une responsabilite unique (SRP) — decrire son job en une phrase sans "et"
+- [ ] Les classes sont ouvertes a l'extension, fermees a la modification (OCP) — nouveau comportement = nouveau code, pas modification
+- [ ] Les sous-classes sont substituables a leur classe mere (LSP) — pas de `if (obj instanceof SpecialCase)`
+- [ ] Les interfaces sont minimales (ISP) — pas d'interface de 15 methodes dont 10 jettent `NotImplementedException`
+- [ ] Les modules haut niveau ne dependent pas des bas niveau (DIP) — les deux dependent d'abstractions
+- [ ] L'heritage est utilise pour "est-un", pas pour reutiliser du code — composition > heritage
+- [ ] Le couplage est reduit : un changement dans une classe ne force pas une cascade de changements
+
+## Anti-patterns
+### SOLID comme religion
+**Ce qu'on voit :** chaque classe est precedee de `interface IFoo`. Chaque `new` est remplace par une factory + DI container. 50 classes pour afficher "Hello World".
+**Pourquoi c'est dangereux :** SOLID utilise en dogme produit l'inverse de son intention : code rigide, difficile a changer, difficile a comprendre. Une interface pour chaque classe = explosion du nombre de fichiers. DI partout = perdu dans les couches d'indirection.
+**Faire plutot :** appliquer SOLID la ou le changement est PROBABLE. Un composant stable peut violer SOLID — c'est acceptable. Introduire une abstraction quand un deuxieme cas concret apparait (pas avant). SOLID est un outil de diagnostic, pas un objectif de design.
+
+### Heritage deep chain
+**Ce qu'on voit :** `Animal → Mammal → Canine → Dog → Labrador → GoldenLabrador`. Chaque classe ajoute un comportement. Pour comprendre `GoldenLabrador`, il faut lire 6 classes.
+**Pourquoi c'est dangereux :** l'heritage profond cree un couplage vertical. Changer `Animal` affecte toutes les 200 sous-classes. Impossible de comprendre une classe isolement. Le YAGNI frappe fort : la plupart des classes intermediaires ne sont jamais utilisees directement.
+**Faire plutot :** limiter a 1-2 niveaux d'heritage maximum. Composer les comportements (Strategy, Decorator) plutot qu'heriter. Si une classe a plus de 2 ancetres concrets, repenser le design.
+
+### Classe "Manager" / "Utils" / "Helper"
+**Ce qu'on voit :** `UserManager` (3000 lignes), `DateUtils` (150 fonctions statiques), `StringHelper` (tout le monde ajoute des trucs).
+**Pourquoi c'est dangereux :** les noms en -Manager, -Utils, -Helper sont des aveux d'echec de design. Ils ne disent rien sur ce que fait la classe. Ils attirent le code non relie comme un aimant. Une classe qui s'appelle `Manager` n'a pas de responsabilite — elle en a 50.
+**Faire plutot :** nommer les classes par leur responsabilite reelle. `UserRepository`, `UserAuthenticator`, `UserNotificationSender`. Si une classe a plus de 10 methodes publiques, la splitter par responsabilite. Les "utils" sont un signe qu'un concept manque dans le domaine.
+
+## Patterns
+### Composition over inheritance
+**Quand :** quasi tout le temps.
+**Comment :** au lieu de `class Duck extends Bird extends Animal`, injecter les comportements : `class Duck { constructor(flyBehavior, quackBehavior, swimBehavior) }`. Chaque comportement est interchangeable. Testable independamment. Le duck peut changer de FlyBehavior au runtime.
+
+### Dependency injection par constructeur
+**Quand :** toute classe qui depend d'un service externe (DB, API, file system).
+**Comment :** `constructor(db: Database, logger: Logger)` — les dependances sont explicites. Pas de `new Database()` dans la classe. Pas de singleton global (`Database.getInstance()`). Le test peut injecter un mock/adaptateur. La classe ne sait pas CREER ses dependances, elle les RECOIT.

package/assets/skills/performance/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: performance
+description: "Performance — mesurer avant d'optimiser, P95 > moyenne, performance budgets, profiling, N+1, slow queries. À charger quand on parle d'optimisation."
+---
+
+# Performance
+
+**Principe premier :** "Make it work, make it right, make it fast" — dans cet ordre. La performance est une feature, pas une propriété magique. Comme toute feature, elle a un coût et doit être mesurée. Le piège classique est l'optimisation prématurée : du code complexe et illisible pour gagner 5ms sur un endpoint appelé 10×/jour. La règle d'or : ne jamais optimiser sans avoir mesuré. Le bottleneck réel n'est presque jamais là où on pense. Et la métrique qui compte n'est pas la moyenne — c'est le P95 (ou P99). La moyenne ment parce qu'elle cache les outliers, et ce sont les outliers qui pourrissent l'expérience utilisateur.
+
+## Checklist
+- [ ] Profiling AVANT optimisation — jamais d'optimisation sur une intuition
+- [ ] Métriques RED par endpoint : Rate, Errors, Duration (P50, P95, P99)
+- [ ] Les requêtes N+1 sont identifiées et résolues (eager loading, batch, JOIN)
+- [ ] Performance budget dans la CI : JS < 200KB, LCP < 2.5s, P95 < 500ms
+- [ ] Les requêtes lentes sont loguées (> 100ms) avec EXPLAIN automatique
+- [ ] Cache en place avec TTL explicite — pas de calcul redondant sur la hot path
+
+## Anti-patterns
+### Optimisation prématurée
+**Ce qu'on voit :** micro-optimisations de boucles, bit-shifting, allocation pooling — sur un endpoint appelé 100×/jour. Le code est devenu illisible pour gagner 2ms.
+**Pourquoi c'est dangereux :** l'optimisation prématurée a un double coût : le code devient plus dur à maintenir, et le temps passé à optimiser n'est pas passé sur des vrais problèmes. Pire : l'optimisation cible souvent le mauvais endroit parce qu'elle est basée sur l'intuition, pas sur la mesure.
+**Faire plutôt :** "Make it work, make it right, make it fast." Mesurer. Profiler. Identifier le vrai bottleneck (souvent une requête DB, pas une boucle). Optimiser là où le profiling montre un gain. Si le gain est < 10%, se demander si la complexité ajoutée le justifie.
+
+### Optimiser la moyenne
+**Ce qu'on voit :** "la latence moyenne est de 200ms, c'est bon." Le P95 est à 8 secondes — 5% des utilisateurs attendent 8 secondes. Mais la moyenne est belle.
+**Pourquoi c'est dangereux :** la moyenne est insensible aux outliers. 95% des requêtes à 50ms + 5% à 10s = moyenne de ~550ms. Tu regardes 550ms et tu penses "acceptable". Mais 5% de tes utilisateurs ont une expérience exécrable. Les percentiles existent pour cette raison précise.
+**Faire plutôt :** P50 (médiane), P95, P99. Le P95 est l'expérience "normale dans le pire cas". Le P99 est l'expérience "vraiment mauvaise". Alerter et optimiser sur les percentiles, pas sur la moyenne.
+
+### Cache sans stratégie
+**Ce qu'on voit :** `cache.set(key, data)` sans TTL. Le cache garde des données stales indéfiniment. Ou pire : le cache est invalidé à chaque écriture mais jamais rechargé (cache toujours vide).
+**Pourquoi c'est dangereux :** un cache mal conçu est pire que pas de cache — il ajoute de la latence (aller-retour Redis) pour servir des données périmées ou pour ne jamais avoir de hit. Le hit rate est la métrique qui dit si ton cache sert à quelque chose.
+**Faire plutôt :** TTL explicite basé sur la fraîcheur acceptable. Surveiller le hit rate — si < 50%, le cache est probablement mal configuré. Cache-aside pour les lectures, write-through pour les lectures après écriture.
+
+## Patterns
+### Performance budget
+**Quand :** application web ou mobile.
+**Comment :** définir des seuils dans la CI. JS bundle < 200KB, page weight < 1MB, LCP < 2.5s, TTI < 3s, P95 API < 500ms. Si la PR dépasse, bloquer. Le budget force la discipline — comme un budget financier, tu ne peux pas ajouter sans enlever ailleurs.
+
+### Slow query monitoring
+**Quand :** toute application avec une base de données.
+**Comment :** loguer toute requête > 100ms avec son EXPLAIN ANALYZE. Dashboard des slow queries. Alerte si une nouvelle slow query apparaît (requête qui était rapide avant, lente maintenant = probablement un index ou un volume de données). Chaque slow query est un ticket.