@neikyun/ciel 6.11.2 → 6.13.0

package/assets/platforms/opencode/.opencode/commands/ciel-init.md

@@ -1,27 +1,20 @@
 ---
-description: ---
-subtask: false
----
-
----
-description: Bootstrap or repair Ciel wiring. Auto-detects platform (Claude Code, OpenCode, Cursor, etc.) and configures hooks. Preserves existing config, creates backups.
+description: Bootstrap or repair Ciel v7 wiring. Auto-detects platform (Claude Code or OpenCode) and configures hooks, agents, and commands. Preserves existing config, creates backups.
 ---
 
 # /ciel-init — Wire Ciel into Current Project
 
-**Purpose:** Fix the #1 Ciel failure mode — hooks not firing because config is missing, has wrong paths, or platform not detected.
+**Purpose:** Fix the #1 failure mode — hooks not firing because config is missing or has wrong paths.
 
-**Usage:** `/ciel-init [--check] [--user] [--platform=NAME]`
+**Usage:** `/ciel-init [--check] [--user] [--platform=claude|opencode]`
 
 - `--check` — Dry-run: show what would change without writing
 - `--user` — Install to user scope (~/.claude/settings.json) instead of project
-- `--platform=NAME` — Force platform (claude, opencode, cursor, windsurf, codex, kilocode, ollama, lmstudio)
-
----
+- `--platform=NAME` — Force platform (default: auto-detect)
 
 ## Instructions
 
-You are repairing Ciel wiring. This is deterministic — NO agent dispatch, NO research, NO pipeline.
+This is deterministic — NO agent dispatch, NO research, NO pipeline.
 
 ### Step 1: Detect Platform
 
@@ -30,144 +23,56 @@ Run detection in order (pick FIRST match):
 1. **Project files:**
    - `./opencode.json` or `./.opencode/` → **opencode**
    - `./.claude/settings.json` or `./.claude/` → **claude**
-   - `./.cursor/` → **cursor**
-   - `./.windsurf/` → **windsurf**
-   - `./.codex/` → **codex**
-   - `./.kilocode/` or `./.kilo/` → **kilocode**
 
 2. **CLI availability:**
    - `command -v claude` → **claude**
    - `command -v opencode` → **opencode**
-   - `command -v ollama` → **ollama**
 
 3. **If ambiguous:** Ask user to specify with `--platform=NAME`
 
-### Step 2: Find Ciel Directory
+### Step 2: Find Ciel Source
 
 Check in order:
-1. `$CLAUDE_PLUGIN_DIR/ciel` (if env var set)
-2. `$HOME/.claude/plugins/ciel`
-3. `$HOME/.ciel`
-4. `find "$HOME" -maxdepth 5 -path '*/ciel/hooks/session-start.sh' 2>/dev/null | head -1`
-
-If not found → Tell user to run install first:
-```bash
-bash <(curl -fsSL https://raw.githubusercontent.com/KaosKyun/Ciel/main/scripts/install.sh)
-```
-
-### Step 3: Verify Hooks Exist
-
-Check for 8 required hooks in `$CIEL_DIR/hooks/`:
-```
-session-start.sh, user-prompt-submit.sh, pre-tool-write.sh, post-tool-write.sh,
-stop.sh, subagent-stop.sh, pre-compact.sh, pre-agent-gate.sh
-```
-
-If missing → Copy from nearest Ciel source or tell user to reinstall.
-
-### Step 4: Configure Platform
-
-#### Claude Code Branch
-
-**Config file:** `./.claude/settings.json` (project) or `$HOME/.claude/settings.json` (user)
-
-**Before writing:**
-1. Check CWD sanity — warn if running Claude from different directory
-2. Backup existing config: `cp file.json file.json.bak-TIMESTAMP`
-
-**Write config:**
-```json
-{
-  "hooks": {
-    "SessionStart": { "command": "$CIEL_DIR/hooks/session-start.sh", "stdin": true },
-    "UserPromptSubmit": { "command": "$CIEL_DIR/hooks/user-prompt-submit.sh", "stdin": true },
-    "PreToolUse": { "command": "$CIEL_DIR/hooks/pre-tool-write.sh", "stdin": true, "matcher": "Write|Edit" },
-    "PostToolUse": { "command": "$CIEL_DIR/hooks/post-tool-write.sh", "stdin": true, "matcher": "Write|Edit" },
-    "PreCompact": { "command": "$CIEL_DIR/hooks/pre-compact.sh", "stdin": true },
-    "Stop": { "command": "$CIEL_DIR/hooks/stop.sh", "stdin": true }
-  }
-}
-```
-
-#### OpenCode Branch
-
-**Config file:** `./opencode.json`
-
-**Before writing:**
-1. Backup: `cp opencode.json opencode.json.bak-TIMESTAMP`
-2. Merge existing config (preserve model, provider, mcp, keybinds)
-
-**Ensure:**
+1. `$CLAUDE_PROJECT_DIR/.claude/hooks/` — project-scoped install (v7 default)
+2. `$HOME/.ciel/` — user-level sentinel
+3. If not found → tell user to install:
+   ```bash
+   bash <(curl -fsSL https://raw.githubusercontent.com/KaosKyun/Ciel/main/scripts/install.sh)
+   ```
+
+### Step 3: Configure Platform
+
+**Claude Code** — Backup then write `.claude/settings.json` with hooks registered:
+- SessionStart, UserPromptSubmit, PreToolUse (Edit|Write + Bash rm + Agent), PostToolUse (Edit|Write), SubagentStart (ciel-*), Stop, SubagentStop, PreCompact
+- Copy agents from source to `.claude/agents/`
+- Copy commands from source to `.claude/commands/`
+- Copy skills from source to `.claude/skills/`
+- Ensure `CLAUDE.md` references Ciel pipeline
+
+**OpenCode** — Backup then ensure `opencode.json`:
 - `plugin` array contains `"./.opencode/plugins/ciel.ts"`
 - `instructions` array contains `"AGENTS.md"`
+- Copy plugin, agents, commands to `.opencode/`
 
-**Copy files:**
-- `.opencode/plugins/ciel.ts`
-- `.opencode/agents/ciel-*.md` (6 files)
-- `.opencode/commands/ciel-*.md` (9 files)
-
-#### Other Platforms Branch
-
-Install platform-specific artifacts:
-- **Cursor:** `.cursor/rules/ciel.mdc`
-- **Windsurf:** `.windsurf/rules/*.md`
-- **Codex:** `AGENTS.md`, `.codex/hooks.json`
-- **Kilocode:** `.kilocode/rules/ciel.md`, `.kilo/agents/*`
-- **Ollama:** `Modelfile` (user runs `ollama create`)
-- **LM Studio:** `ciel.preset.json`, `system-prompt.md`
-
-### Step 5: Verification
-
-After configuration, verify:
+### Step 4: Verify
 
-1. **Config file exists** at expected path
-2. **Hooks are executable:** `chmod +x "$CIEL_DIR/hooks/"*.sh`
-3. **Plugin file syntax valid** (for OpenCode: `npx tsc --noEmit`)
+1. Config file exists at expected path
+2. Hooks are executable: `chmod +x .claude/hooks/*.sh`
+3. Agent definitions present (4 files)
+4. Report summary: platform, config path, hooks count, next steps
 
-### Step 6: Report
+## What's preserved
 
-Output summary:
-
-```
-✓ /ciel-init completed
-
-Platform: Claude Code
-Config: /path/to/settings.json
-CIEL_DIR: /path/to/ciel
-Hooks: 8/8 present
-
-Next steps:
-1. Restart Claude Code
-2. Run a test prompt — should see depth hint
-3. Make code changes — should see RELIRE reminder
-```
-
----
+- `ciel-overlay.md` — project-specific rules
+- `.ciel/` — state directory (map.json, memory.json, parking.md)
+- Existing `settings.json` — merged non-destructively
+- Existing `opencode.json` — merged non-destructively
 
 ## Error Handling
 
 | Error | Action |
 |-------|--------|
-| Ciel directory not found | Tell user to run install script |
-| Hooks missing | Try to copy from source, else reinstall |
+| Ciel source not found | Tell user to run install script |
 | Config write fails | Show manual instructions |
 | Platform ambiguous | Ask user to specify with --platform |
-| Permission denied | Suggest running with sudo or check file permissions |
-
----
-
-## Examples
-
-```bash
-# Auto-detect and install to project
-/ciel-init
-
-# Force Claude Code, user scope
-/ciel-init --platform=claude --user
-
-# Check what would change (dry-run)
-/ciel-init --check
-
-# Force OpenCode
-/ciel-init --platform=opencode
-```
+| Permission denied | Check file permissions |

package/assets/platforms/opencode/.opencode/commands/ciel-status.md

@@ -1,45 +1,43 @@
 ---
-description: ---
-subtask: false
----
-
----
-description: Displays the current Ciel environment status — active version, loaded skills, registered hooks, last session state, and configuration health. A diagnostic entry point for "is Ciel working?" questions.
+description: Displays current Ciel environment status — version, platform, hooks, skills, agents, commands, memory health. Diagnostic entry point for "is Ciel working?" questions.
 ---
 
 # /ciel-status — Ciel Environment Health Check
 
-*Displays the current Ciel environment status: version, skills, hooks, and config.*
+Displays the current Ciel environment status: version, platform, hooks, skills, agents, and config health.
 
 Usage: `/ciel-status [--check]`
 
-- `--check` — run diagnostics (verify hooks fire, skills load, config is valid)
+- No flag — summary view
+- `--check` — run full diagnostics (verify hooks fire, skills load, config valid)
 
-## Output
+## Summary output
 
 ```
 ## CIEL STATUS
 
-Version: v6.2.4
+Version: v4.0.1
 Platform: Claude Code
-Config: .claude/settings.json — OK (4 hooks registered)
-Skills directory: skills/ — 43 skills loaded
-Commands: 7 commands available
-Last session: 2026-05-06T11:20:00Z — Skills library reorg
+Config: .claude/settings.json — OK
+Hooks: 12 registered
+Skills: 48 domain skills in .claude/skills/
+Agents: 4 sub-agents (researcher, explorer, critic, improver)
+Commands: 7 available
+Memory: .ciel/memory/ — N episodes
 ```
 
 ## Diagnostics (--check)
 
-- [ ] CLAUDE.md readable and includes Ciel pipeline
-- [ ] .claude/settings.json valid JSON, hooks registered
-- [ ] .ciel/map.json parseable and up-to-date
-- [ ] .ciel/memory.json parseable
-- [ ] Shell hooks executable (check-test-first, block-destructive, track-file, meta-critiquer)
-- [ ] Skills directory non-empty and accessible
-- [ ] Agent definitions present (.claude/agents/ or .opencode/agents/)
+- CLAUDE.md readable and includes Ciel pipeline
+- .claude/settings.json valid JSON, all hooks registered
+- .ciel/map.json parseable
+- .ciel/memory/index.json present
+- Shell hooks executable and firing
+- Skills directory non-empty
+- Agent definitions present (4 files)
 
-## When triggered
+## When to use
 
-- User asks "is Ciel working?" or "check Ciel health"
-- After ciel-init to verify installation
+- After `/ciel-init` to verify installation
+- When "is Ciel working?" is asked
 - Debugging hook failures or missing depth classification

package/assets/platforms/opencode/.opencode/commands/ciel-update.md

@@ -1,63 +1,43 @@
 ---
-description: ---
-subtask: false
----
-
----
-description: Check GitHub for newer Ciel release and re-install. Runs `scripts/install.sh --check-update` then `--update`.
+description: Check GitHub for newer Ciel release and re-install. Preserves project config — ciel-overlay.md, .ciel/, settings.json.
 ---
 
 # /ciel-update — Update Ciel to the latest version
 
 Checks GitHub for a newer release and re-installs if available.
 
-## Steps
-
-1. **Check version**: `bash scripts/install.sh --check-update`
-   - Fetches `VERSION` from GitHub, compares with local
-   - Prints "up to date" or "update available"
-
-2. **Apply update**: `bash scripts/install.sh --update -y`
-   - Re-installs all Ciel files (plugins, agents, commands, hooks)
-   - Preserves: `ciel-overlay.md`, `.ciel/`, existing configs
-   - Non-destructive merge on `opencode.json`
+Usage: `/ciel-update [--check]`
 
-## Flags
+- No flag — full update (check + apply)
+- `--check` — only check remote version, report, don't install
 
-| Flag | Purpose |
-|------|---------|
-| `--check-update` | Check remote version, don't install |
-| `--update` / `-u` | Force reinstall all files |
-| `-y` | Skip confirmation (non-interactive) |
-| `-q` | Quiet mode (summary only) |
-
-## One-liner
+## Steps
 
-```bash
-bash <(curl -fsSL https://raw.githubusercontent.com/KaosKyun/Ciel/main/scripts/install.sh) --check-update
-bash <(curl -fsSL https://raw.githubusercontent.com/KaosKyun/Ciel/main/scripts/install.sh) --update -y
-```
+1. **Check version**: fetch `VERSION` from GitHub, compare with `.ciel/version` or `VERSION`
+2. **Apply update**: re-install all Ciel files (hooks, agents, commands, skills, plugin)
+3. **Verify**: confirm hooks executable, agents present, config valid
 
 ## What's preserved
 
 - `ciel-overlay.md` — project-specific rules
-- `.ciel/map.json`, `.ciel/memory.json`, `.ciel/parking.md`
-- `opencode.json` — existing config merged non-destructively
-- `.claude/settings.json` — hook paths preserved
+- `.ciel/` — state directory (map.json, memory/, parking.md)
+- `.claude/settings.json` — merged non-destructively
+- `.opencode/opencode.json` — merged non-destructively
 
 ## What's replaced
 
-- `.opencode/plugins/ciel.ts` — fresh plugin
-- `.opencode/agents/ciel-*.md` — agent definitions
-- `.opencode/commands/ciel-*.md` — command files
-- `.claude/agents/ciel-*.md` — Claude Code agents
 - `.claude/hooks/*.sh` — shell hooks
-- `CLAUDE.md` — root instruction
+- `.claude/agents/ciel-*.md` — agent definitions
+- `.claude/commands/ciel-*.md` — command files
+- `.claude/skills/` — domain skills
+- `.opencode/plugins/ciel.ts` — plugin
+- `.opencode/agents/ciel-*.md` — OpenCode agents
+- `.opencode/commands/ciel*.md` — OpenCode commands
 
 ## Troubleshooting
 
 | Symptom | Fix |
 |---------|-----|
-| `Could not fetch remote version` | Check internet or proxy: `https_proxy=... bash install.sh --check-update` |
-| Plugin not loaded after update | Restart OpenCode (plugin loaded at session start) |
-| `jq not found` warning | Install jq for automatic opencode.json patching |
+| Could not fetch remote version | Check internet or proxy: `https_proxy=...` |
+| Plugin not loaded after update | Restart editor (plugin loaded at session start) |
+| Hook permissions after update | `chmod +x .claude/hooks/*.sh` |

package/assets/platforms/opencode/AGENTS.md

@@ -1,4 +1,4 @@
-# AGENTS.md — Ciel deep-reasoning workflow (OpenCode, v6.2.4)
+# AGENTS.md — Ciel deep-reasoning workflow (OpenCode, v3.3.0)
 
 Source: https://github.com/KaosKyun/Ciel
 
@@ -8,7 +8,7 @@ Ciel is installed as OpenCode-native primitives:
 
 - **Plugin** (`.opencode/plugins/ciel.ts`) — pre/post-write hooks + depth classification on user prompts.
 - **Subagents** (`.opencode/agents/ciel-*.md`) — dispatch with `@ciel-researcher`, `@ciel-explorer`, `@ciel-critic`, `@ciel-improver`.
-- **Commands** (`.opencode/commands/ciel*.md`) — run with `/ciel`, `/ciel-improve`, `/ciel-refresh`, `/ciel-audit`, `/ciel-init`, `/ciel-eval`, `/ciel-create-skill`, `/ciel-recommend`, `/ciel-update`.
+- **Commands** (`.opencode/commands/ciel*.md`) — run with `/ciel`, `/ciel-improve`, `/ciel-refresh`, `/ciel-audit`, `/ciel-init`, `/ciel-eval`, `/ciel-create-skill`, `/ciel-status`, `/ciel-migrate`, `/ciel-update`.
 
 ---
 
@@ -16,7 +16,7 @@ Ciel is installed as OpenCode-native primitives:
 
 | Level | Example | Pipeline |
 |-------|---------|----------|
-| **Trivial** | rename, typo, 1-line fix | `QUOI` → `FAIRE` → `META` |
+| **Trivial** | rename, typo, 1-line fix | `quoi-framer` → `pattern-fitness-check` → `faire-gatekeeper` → inline review → push |
 | **Standard** | hook, route, component, service | Full pipeline, dispatch `@ciel-researcher` + `@ciel-explorer` in parallel before coding |
 | **Critical** | auth, DB schema, security, payment | Full pipeline + STRIDE threat model + `@ciel-critic` mandatory |
 
@@ -78,7 +78,7 @@ The `ciel.ts` plugin injects depth classification on every user prompt and RELIR
 Ciel ships a `.mcp.json` template at the repo root with two opt-in servers: `playwright` (visual critique) and `context7` (live official docs). Register them via:
 
 ```bash
-bash ~/.claude/plugins/ciel/scripts/install.sh --with-mcp=playwright,context7
+bash <(curl -fsSL https://raw.githubusercontent.com/KaosKyun/Ciel/main/scripts/install.sh) --with-mcp=playwright,context7
 ```
 
 **Important** — OpenCode issue #2319: plugin hooks (`tool.execute.before/after`) do NOT fire for MCP tool calls. The `playwright-visual-critic` skill orchestrates the flow explicitly (navigate → snapshot → dispatch `@ciel-critic`) rather than relying on auto-triggered hooks. When you use a visual-critique workflow, dispatch the critic agent yourself after capture.

package/assets/rules/security.md

@@ -0,0 +1,30 @@
+---
+paths:
+  - "**/auth/**"
+  - "**/security/**"
+  - "**/*Token*"
+  - "**/*Password*"
+  - "**/*Secret*"
+  - "**/*Session*"
+  - "**/*Crypto*"
+  - "**/*Credential*"
+  - "**/encrypt*"
+  - "**/cipher*"
+---
+
+## Dispatch
+- Charge `appsec` AVANT d'ecrire du code d'auth ou de crypto.
+- Si tu touches des tokens/sessions → charge aussi `crypto`.
+- Si le fichier est dans `.github/workflows/` → charge aussi `devsecops` + `supply-chain`.
+
+## Regles dures (zero tolerance)
+- **Jamais** de secret, token, cle API, mot de passe dans le code. Env vars ou secret manager.
+- **Jamais** de `import { random }` pour la crypto. Toujours `crypto.randomBytes` ou equivalent.
+- **Jamais** de `bcrypt.compare` sans `await`. Un `== true` oublie = tous les comptes ouverts.
+
+## Conventions du projet
+- Hachage mots de passe : bcrypt ou argon2. Jamais MD5/SHA1.
+- Chiffrement : AES-256-GCM ou ChaCha20-Poly1305. Jamais ECB.
+- JWT : RS256 ou ES256. Pas de `secret: "mon-super-secret"`.
+- Les cles tournent automatiquement (max 90 jours).
+- Log scrubbing : jamais de PII/token/secret dans les logs.

package/assets/rules/testing.md

@@ -0,0 +1,23 @@
+---
+paths:
+  - "**/*.test.*"
+  - "**/*.spec.*"
+  - "**/__tests__/**"
+  - "**/test/**"
+  - "**/tests/**"
+---
+
+## Dispatch
+- Charge `testing` AVANT d'ecrire du code source.
+- Si c'est un test d'integration avec DB → charge aussi `database-design`.
+- Si c'est un test E2E → charge aussi `cicd-pipeline` (le test doit passer en CI).
+
+## Regle dure (zero tolerance)
+- **RED FIRST** : ecris le test et vois-le echouer avant d'ecrire le code source. Jamais l'inverse.
+- **Flaky test** : si un test echoue sans changement de code > 2% du temps → quarantaine. Jamais "relance le job".
+- **Pas de mock systematique** : vraie DB en integration (testcontainers, pg_tmp). Mock seulement les frontieres lentes (HTTP externe, email).
+
+## Conventions du projet
+- Test pyramid : 70% unitaires, 20% integration, 10% E2E.
+- Tester le comportement observable, pas l'implementation. Input → output.
+- Arrange-Act-Assert. DAMP > DRY dans les tests (lisibilite avant factorisation).

package/assets/skills/agile/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: agile
+description: "Agile — Scrum, Kanban, Shape Up, sprints, estimation, retros, amelioration continue. A charger quand on travaille en mode agile."
+---
+
+# Agile
+
+**Principe premier :** L'agilite n'est pas un framework (Scrum n'est pas l'agilite) — c'est un principe : livrer de la valeur en petits increments, inspecter le resultat, et adapter le plan. Le manifeste agile a 4 valeurs, et la premiere est "les individus et leurs interactions plus que les processus et les outils". Si ton processus agile est plus important que les personnes qui l'utilisent, tu as echoue l'agilite. Le but du process n'est pas d'etre suivi — c'est de rendre l'equipe plus efficace. Un processus qui ralentit l'equipe n'est pas agile, meme s'il suit Scrum a la lettre. Le meilleur indicateur d'agilite : combien de temps entre "j'ai une idee" et "c'est en production" ?
+
+## Checklist
+- [ ] Les ceremonies sont cadrees : standup 15min, retro 1h, planning 1-2h — si plus long, le processus est casse
+- [ ] Les tickets sont INVEST : Independent, Negotiable, Valuable, Estimable, Small, Testable
+- [ ] Le WIP est limite (Kanban/Scrum avec capacite explicite) — pas plus de travail en cours que de capacite
+- [ ] Les retros produisent des actions concretes (pas "on communiquera mieux") — max 2-3 actions par retro
+- [ ] La velocite est utilisee pour le planning, pas pour le jugement de performance
+- [ ] Le backlog est priorise par valeur business, pas par "c'est facile" ou "c'est urgent depuis 6 mois"
+- [ ] Le cycle time (temps ticket ouvert → ferme) est mesure et s'ameliore — c'est le vrai KPI agile
+
+## Anti-patterns
+### Agile = Scrum = standups + sprints
+**Ce qu'on voit :** l'equipe fait des standups, des sprints de 2 semaines, et un retro. "On est agile." Les stories sont estimees en story points. Les sprints sont bookes a 110%. Rien n'est livre en production a la fin du sprint.
+**Pourquoi c'est dangereux :** c'est du theatre agile. Les ceremonies sont suivies mais l'objectif (livrer de la valeur rapidement) est manque. Le processus devient le produit. L'equipe est frustree ("l'agile c'est des reunions qui servent a rien") sans comprendre que le probleme n'est pas l'agilite, c'est l'imitation vide de l'agilite.
+**Faire plutot :** se demander POURQUOI on fait chaque ceremonie. Si le standup est un compte-rendu au manager, c'est foutu — le standup est pour que l'equipe se synchronise. Si la retro ne produit jamais d'actions, l'arreter. Moins de processus, plus de livraison. Commencer par Kanban (pas de sprint, flux continu) et ajouter des ceremonies seulement si le besoin emerge.
+
+### Story points = mesure de performance
+**Ce qu'on voit :** "tu as fait 8 points ce sprint, l'objectif est 13." Les story points deviennent un KPI individuel.
+**Pourquoi c'est dangereux :** les story points mesurent la complexite relative, pas la productivite. Les utiliser comme KPI = l'equipe gonfle les estimations. 1 point devient 3. La velocite augmente mais rien n'est livre plus vite. Culture de la peur et du gaming du systeme.
+**Faire plutot :** les story points servent UNIQUEMENT a la planification de sprint (combien de travail l'equipe peut absorber). La vraie metrique est le cycle time (combien de temps pour livrer) et le throughput (combien de tickets livres par semaine). Ces metriques ne sont pas gameables.
+
+### Retro = rituel vide
+**Ce qu'on voit :** "Qu'est-ce qui s'est bien passe ? Qu'est-ce qui s'est mal passe ?" Memes reponses depuis 6 mois : "la communication" et "les specs pas claires". Zero action concrete.
+**Pourquoi c'est dangereux :** une retro sans action est un signal que l'equipe est apprise a l'impuissance. Les problemes sont identifies mais jamais resolus. La retro devient une soupape ou on se plaint sans consequence — c'est pire que pas de retro car ca cree du cynisme.
+**Faire plutot :** chaque retro produit 1-2 actions concretes, assignees, avec deadline. La retro suivante commence par "est-ce que les actions de la derniere retro sont faites ?" Si non, pourquoi ? Si une action n'est jamais faite, le probleme n'est pas l'equipe — c'est que le systeme empeche l'amelioration.
+
+## Patterns
+### Kanban pour commencer
+**Quand :** equipe qui decouvre l'agilite ou qui a ete brulee par Scrum.
+**Comment :** visualiser le flux (colonnes To Do / In Progress / Done), limiter le WIP (max 2 taches par personne en In Progress), mesurer le cycle time. Pas de sprint, pas d'estimation obligatoire, pas de ceremonies forcees. Ajouter un standup uniquement si la synchro est necessaire. Iterer sur le processus a partir de la.
+
+### Cycle time comme North Star
+**Quand :** mesurer l'amelioration continue.
+**Comment :** cycle time = temps entre "le ticket est pret a developper" et "en production". Mesurer le P50 et P85 (pas la moyenne — les outliers faussent). Objectif : reduire le cycle time sans sacrifier la qualite. Un cycle time qui diminue = l'equipe s'ameliore VRAIMENT.

package/assets/skills/alerting/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: alerting
+description: "Alerting — SLO-based alerting, alert fatigue prevention, on-call, post-mortems, runbooks. A charger quand on configure des alertes."
+---
+
+# Alerting
+
+**Principe premier :** Une alerte qui ne declenche pas d'action n'est pas une alerte — c'est du bruit qui tue les vraies alertes. Chaque alerte doit etre : actionable (tu sais quoi faire), symptom-based (pas cause-based), et avoir un runbook. Si tu ne peux pas ecrire le runbook en < 5 etapes, ne cree pas l'alerte. Le but n'est pas d'etre notifie de tout — c'est d'etre notifie assez tot pour agir avant que les utilisateurs ne remarquent.
+
+## Checklist
+- [ ] Les alertes sont sur les symptomes (P95 > 1s, error rate > 1%), pas sur les causes (CPU > 70%)
+- [ ] Chaque alerte a un runbook — pas "on verra quand ca sonnera"
+- [ ] Les regles d'alerte et la config AlertManager sont dans le repo (alerting as code) — pas creees a la main
+- [ ] SLA de reponse defini : critical (page, < 5 min), high (page jour, < 30 min), medium (ticket, < 4h)
+- [ ] Alertes groupees et de-dupliquees — pas 50 pages pour la meme cause racine
+- [ ] On-call rotation documentee avec escalation — personne n'est on-call seul sans backup
+- [ ] Post-mortem blameless apres chaque incident majeur + 5 Whys jusqu'a la cause racine
+
+## Anti-patterns
+### Alerter sur tout
+**Ce qu'on voit :** "CPU > 70%", "memoire > 60%", "disque > 70%" — 200 alertes configurees. 15 pages par nuit. L'equipe a mute le canal.
+**Pourquoi c'est dangereux :** alert fatigue. Chaque fausse alerte entraine la suivante vers l'ignore. Quand la vraie alerte critique arrive, personne ne la voit. Le canal d'alerte est devenu un flux de bruit ignore.
+**Faire plutot :** alerter sur les symptomes utilisateur. "P95 latency > 1s pendant 5 min" (l'utilisateur ressent la lenteur). "Error rate > 1% pendant 5 min" (l'utilisateur voit des erreurs). Le CPU est une cause possible parmi 10, pas un symptome.
+
+### Alerte sans runbook
+**Ce qu'on voit :** alerte "PaymentService is down". Pas de runbook. L'on-call Googlise "comment restart payment service" a 3h du matin.
+**Pourquoi c'est dangereux :** MTTR explose. L'on-call stresse fait des erreurs. Le runbook est la difference entre "redemarrer en 2 minutes" et "aggraver l'incident en 30 minutes de debugging panique".
+**Faire plutot :** runbook attache a chaque alerte. Etapes concretes. "1. Verifier les logs dans Loki avec {service=payment, level=error}. 2. Si OOM -> restart le pod. 3. Si DB timeout -> verifier les connexions pool. 4. Si rien -> escalader a l'equipe backend. 5. Post-mortem avec 5 Whys dans les 48h."
+
+### Aucun post-mortem
+**Ce qu'on voit :** incident resolu -> "ouf, on passe a autre chose". Pas d'analyse. Le meme incident se reproduit 3 mois plus tard.
+**Pourquoi c'est dangereux :** sans post-mortem, l'organisation n'apprend pas. Les memes erreurs se repetent. Le but du post-mortem n'est pas de trouver un coupable — c'est d'identifier les failles du SYSTEME qui ont permis l'incident.
+**Faire plutot :** post-mortem blameless dans les 48h. Format : timeline, impact, 5 Whys jusqu'a la cause racine, what went well, what went wrong, action items. Les action items ont des owners et des deadlines.
+
+### Corriger le symptome, pas la cause racine
+**Ce qu'on voit :** le disque est plein -> on supprime des logs. Le disque se remplit 3 jours plus tard. Meme incident, meme reponse. 5 iterations avant de se demander POURQUOI.
+**Pourquoi c'est dangereux :** corriger le symptome sans trouver la cause racine garantit la recidive. Chaque recurrence erode la confiance. Le MTTR apparent est bas, le MTTR reel est infini (l'incident n'est jamais vraiment resolu).
+**Faire plutot :** methode des 5 Whys. "Le disque est plein" -> Pourquoi ? "Les logs font 50 Go/jour" -> Pourquoi ? "Level DEBUG active en prod" -> Pourquoi ? "Le deploiement a ecrase la config" -> Pourquoi ? "La config n'est pas versionnee" -> Action racine : versionner la config + alerter si disque > 80%. Le bug est le niveau DEBUG. La cause racine est l'absence d'IaC pour la config. On corrige la cause, pas le symptome.
+
+## Patterns
+### AlertManager (routing + dedup + silence)
+**Quand :** toute stack Prometheus en production.
+**Comment :** Prometheus evalue les rules -> alertes -> AlertManager. AlertManager groupe les alertes (`group_by: [service, severity]`), deduplique (meme alerte = une notification), silencie la maintenance (`matchers: [env=staging]`). Routes par severite : critical -> PagerDuty/Opsgenie, warning -> Slack. Config dans `monitoring/alertmanager.yml`, versionne dans le repo.
+
+### Alerting as Code (regles dans le repo)
+**Quand :** toute equipe de plus d'une personne.
+**Comment :** regles Prometheus (`monitoring/rules.yml`), config AlertManager (`monitoring/alertmanager.yml`), dashboards Grafana (`monitoring/dashboards/`) — tout dans le repo, versionne, deploye via CI/CD. Pas de regle creee a la main dans l'UI Grafana. Une PR pour chaque changement d'alerte — le seuil, le runbook_url, la severite sont revus comme du code.
+
+### Runbook integre a l'alerte
+**Quand :** chaque alerte creee.
+**Comment :** `annotations: { runbook_url: "https://wiki.corp/runbooks/payment-latency" }`. Le runbook contient : (1) ce que signifie l'alerte, (2) comment verifier dans Grafana/Loki/Tempo, (3) actions de mitigation, (4) qui escalader, (5) comment faire un 5 Whys si la mitigation ne suffit pas.
+
+### Post-mortem blameless + 5 Whys
+**Quand :** tout incident qui a declenche une alerte on-call.
+**Comment :** document blameless dans les 48h. Sections : timeline, impact, 5 Whys jusqu'a la cause racine systemique, what went well, what went wrong, action items avec owners et deadlines. L'objectif est d'ameliorer le SYSTEME — pas de trouver un responsable. Action items prioritaires sur le prochain sprint.

package/assets/skills/api-design/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: api-design
+description: "API Design — l'API comme contrat, REST/GraphQL/gRPC, pagination cursor-based, idempotency, structured errors, rate limiting. À charger quand on crée ou modifie des endpoints."
+---
+
+# API Design
+
+**Principe premier :** Une API est un contrat entre un client et un serveur qui évoluent à des rythmes différents. Le client peut être une app mobile qui se met à jour une fois par mois, le serveur peut être déployé 10× par jour. Le design d'API est l'art de faire évoluer le contrat sans le casser. Chaque champ que tu ajoutes est un engagement, chaque champ que tu changes est une rupture. La question n'est pas "est-ce que c'est RESTful ?" mais "est-ce que le client peut survivre à 6 mois de changements serveur sans mise à jour ?"
+
+## Checklist
+- [ ] L'API est versionnée — dans l'URL (/v1/) ou le header (Accept-Version)
+- [ ] Pagination cursor-based — stable, index-friendly, pas de doublon entre pages
+- [ ] Les erreurs sont structurées : `{error: {code, message, details}}` — pas de `200 OK {success: false}`
+- [ ] Les mutations POST/PUT/DELETE supportent l'idempotency key
+- [ ] Rate limiting en place avec headers standards : `Retry-After`, `X-RateLimit-*`
+- [ ] Le schéma est documenté (OpenAPI/GraphQL schema/gRPC proto) et la doc est le contrat, pas une suggestion
+- [ ] Pas de breaking change sans nouvelle version ou deprecation window explicite
+
+## Anti-patterns
+### Breaking change silencieux
+**Ce qu'on voit :** `{price: 10}` devient `{price: {amount: 10, currency: "EUR"}}` sur la même version d'API. Les clients mobiles qui n'ont pas été mis à jour crashent.
+**Pourquoi c'est dangereux :** le client n'a aucun moyen de savoir que le contrat a changé. Il parse ce qu'il reçoit, ça casse. Le pire : ça peut arriver à 20% des utilisateurs seulement (ceux qui n'ont pas la dernière version de l'app). Le bug est invisible côté serveur.
+**Faire plutôt :** nouvelle version (/v2/) avec le nouveau format. L'ancienne version (/v1/) est maintenue pendant une deprecation window (6-12 mois) avec un header `Deprecation: true` et `Sunset: <date>`. Les clients ont le temps de migrer.
+
+### `200 OK` avec erreur dedans
+**Ce qu'on voit :** toutes les réponses sont HTTP 200. Le corps contient `{success: false, error: "quelque chose"}`. Même pour une erreur 500.
+**Pourquoi c'est dangereux :** HTTP a un système de codes d'erreur pour une raison. Les CDN cachent les 200. Les load balancers comptent les 5xx. Les outils de monitoring alertent sur les taux d'erreur HTTP. En faisant tout en 200, tu rends ton API invisible à toute la chaîne d'infrastructure.
+**Faire plutôt :** utiliser les codes HTTP comme prévu. 201 Created, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 409 Conflict, 422 Unprocessable, 429 Too Many Requests, 500 Internal. Le code HTTP est un signal machine-readable.
+
+### Offset pagination
+**Ce qu'on voit :** `GET /orders?page=3&limit=50` → `LIMIT 50 OFFSET 100`. À la page 100, la DB scanne 5000 rows pour en retourner 50.
+**Pourquoi c'est dangereux :** deux problèmes. Performance : OFFSET N oblige la DB à scanner N rows. Cohérence : si une row est insérée entre deux pages, toutes les rows suivantes sont décalées et l'utilisateur voit des doublons ou manque des entrées.
+**Faire plutôt :** cursor-based : `GET /orders?cursor=xyz&limit=50` → `WHERE id > 'xyz' ORDER BY id LIMIT 50`. Index-friendly. Stable. Pas de doublon. Le cursor est opaque pour le client.
+
+## Patterns
+### Structured errors
+**Quand :** toute API.
+**Comment :** `{error: {code: "INSUFFICIENT_FUNDS", message: "Solde insuffisant", details: [{field: "amount", reason: "minimum 10 EUR"}]}}`. `code` : machine-readable (switch côté client). `message` : human-readable (debug). `details` : actionable (form validation).
+
+### Idempotency key
+**Quand :** toute mutation où le double-submit est dangereux (paiements, créations).
+**Comment :** header `Idempotency-Key: <uuid>`. Le serveur stocke la clé + le résultat. Même clé = même réponse, l'opération n'est exécutée qu'une fois. Stripe utilise ce pattern pour 100% de leurs mutations.
+
+### Rate limiting avec headers
+**Quand :** tout endpoint public.
+**Comment :** `429 Too Many Requests` + `Retry-After: 30` + `X-RateLimit-Limit: 100` + `X-RateLimit-Remaining: 0` + `X-RateLimit-Reset: 1716000000`. Le client sait exactement quand réessayer. Pas de backoff deviné.