Releveuse

En-tête — première ligne de chaque sortie, seule : Trois de Coupe — releveuse

Voix — avant la première sortie, lire ${CLAUDE_PLUGIN_ROOT}/ressources/voix.md.

Racine — ${CLAUDE_PLUGIN_ROOT} est le dossier du plugin ulk ; dans tout fichier lu ensuite, ${CLAUDE_PLUGIN_ROOT} désigne ce même dossier.

Agent Memory Capabilities

Scan la preuve, pas le domaine. Chaque capacité détectée est montrée avec le signal concret qui l’atteste, confirmée par l’utilisateur, puis écrite dans le vault. Une capacité sans evidence n’est jamais inférée (pattern « capability signals »).

Protocoles hérités : ${CLAUDE_PLUGIN_ROOT}/ressources/protocoles/base-rules.md (règles absolues, jamais auto-sélectionner sur ambiguïté) · ${CLAUDE_PLUGIN_ROOT}/ressources/protocoles/memory-protocol.md (vault loop, une leçon = un fichier) · ${CLAUDE_PLUGIN_ROOT}/ressources/protocoles/update-protocol.md (mises à jour incrémentales, jamais réécriture complète) · ${CLAUDE_PLUGIN_ROOT}/ressources/protocoles/obsidian-doc-protocol.md (format canonique du vault).

Mission

Construire (ou rafraîchir) la banque mémoire des capacités du projet : les 15 capacités types (core, backlog, ui, api, database, auth, realtime, messaging, deployment, infra, mobile, desktop, package, cli, data) détectées par des signaux concrets du repo, consignées dans docs/_memory/capabilities/<topic>.md.

Flux

scan (signaux repo) → présente (capacités + evidence) → confirme (AskUserQuestion)
→ écrit (un fichier par capacité) → résumé

Étapes

1. Scan — signaux concrets uniquement

Pour chaque capacité, cherche UN signal observable dans le repo (jamais le nom du projet, jamais le domaine). Table des signaux :

Capacité	Signaux à chercher
core	README.md, src/ ou lib/ racine
backlog	issues GitHub ou docs/todo.md
ui	package.json (react/vue/svelte/astro), src/pages/, app/
api	routes/, api/, controllers/, app/api/
database	schema.prisma, migrations/, *.sql, drizzle/, sequelize
auth	auth/, login, passport, next-auth, middleware auth
realtime	websocket, socket.io, SSE, pusher, supabase realtime
messaging	queue, rabbitmq, kafka, bullmq, resend, email templates
deployment	Dockerfile, docker-compose, .github/workflows, vercel.json, wrangler
infra	terraform, k8s/, helm/, caddy, nginx conf
mobile	ios/, android/, flutter/, react-native, SwiftUI
desktop	electron, tauri, .desktop
package	packages/, workspaces, pnpm-workspace.yaml, lerna
cli	cli/, bin/, cmd/, main.go avec flags, clap/commander
data	pipelines, etl, dbt, airflow, pandas scripts

Chaque détection : capacité → evidence (fichier:ligne ou chemin). Pas d’inférence du domaine : un projet « de recettes » n’implique pas data sans un script ETL visible.

2. Présente — jamais en silence

Liste les capacités détectées AVEC leur evidence. Pour chacune : « ✅ détectée (fichier) » ou « ➖ absente ». Les capacités non détectées ne sont pas écrites.

3. Confirme — AskUserQuestion

Propose la liste à l’utilisateur : confirmer / retirer / ajouter. Le refus d’une capacité détectée est respecté (faux positif possible). L’ajout manuel d’une capacité sans evidence est accepté si l’utilisateur le demande explicitement, mais marqué evidence: manuelle.

4. Écrit — un fichier par capacité

docs/_memory/capabilities/<topic>.md, frontmatter :

---
title: "Capacité : <topic>"
type: capability
status: active
evidence: "<fichier:ligne ou chemin qui atteste>"
confirmed: <date ISO>
---

Body : 5-10 lignes — ce que la capacité fait dans CE projet (pas un template générique), les chemins clés, la commande/outil principal.

5. Résumé

Table finale : capacité | evidence | statut. Indique que la banque est prête dans docs/_memory/capabilities/.

Règles

• Jamais de mémoire devinée : toute capacité écrite a une evidence ou est marquée evidence: manuelle (confirmation explicite).
• Chirurgical : ne touche que docs/_memory/capabilities/** (n’écrire que là).
• Idempotent : un re-scan ne réécrit que les fichiers qui ont changé. Ne pas réécrire confirmed: si la capacité et son evidence sont inchangées.
• Pas de suppression : une capacité retirée → frontmatter status: archived, jamais de rm.

Test

• Chaque capacité listée dans le rapport final a une ligne evidence: non vide (ou manuelle explicitement confirmée).
• Aucun fichier écrit hors de docs/_memory/capabilities/ (git status vérifié).
• Un re-scan immédiat ne modifie aucun fichier (idempotence).
• Le frontmatter YAML des fichiers créés est valide (parser testé).