Claudeception

Claudeception capture la mémoire épisodique des sessions de travail.

Il ne crée ni ne met à jour de compétences. Son rôle est de préserver ce qui s'est passé, ce qui a été appris, et pourquoi c'était important dans une entrée de journal datée qui peut être recherchée ultérieurement ou promue via un workflow distinct.

Quand l'utiliser

Utilisez cette compétence quand l'un de ces cas est vrai :

Une tâche a nécessité un débogage ou une investigation non évidente
Un contournement ou un chemin de récupération a été découvert par essai-erreur
Un message d'erreur était trompeur et la véritable cause racine a été identifiée
Une contrainte spécifique au projet ou au système a été découverte
L'utilisateur tape /claudeception
L'utilisateur dit « save this as a skill », « extract a skill from this », ou « what did we learn? »

N'utilisez pas cette compétence pour créer du savoir procédural durable. Si l'apprentissage devrait devenir une compétence réutilisable, laissez cela pour une étape de promotion distincte.

Règle fondamentale

Ne créez jamais une compétence à partir de cette compétence.

Même quand l'utilisateur dit « save this as a skill », honorez l'intention en écrivant une entrée de journal à moins qu'il ne demande explicitement un workflow de rédaction de compétence distinct.

Seuil de capture

Écrivez une entrée de journal quand la session a produit du savoir qui vaut la peine d'être préservé, même s'il est étroit ou spécifique à un seul système.

Bon matériel pour le journal :

Découvertes spécifiques à un incident
Particularités du système et pièges de déploiement
Causes racines derrière des défaillances confuses
Tradeoffs investigués et contournements
Motifs répétés qui ne sont pas encore généralisés

Omettez la capture quand :

La tâche était une simple recherche de documentation
La conclusion est déjà bien couverte par une compétence existante ou la documentation du projet
La note répèterait surtout du savoir évident
La note nécessiterait de stocker des secrets ou des détails internes sensibles

Localisation de sortie

Écrivez les entrées à :

~/.codex/journal/YYYY-MM-DD-topic-slug.md

Exemples :

~/.codex/journal/2026-04-05-fastly-draft-version-publish-mismatch.md
~/.codex/journal/2026-04-05-nextjs-server-side-error-debugging.md

Si plusieurs notes se retrouvent le même jour avec le même slug, ajoutez un court suffixe.

Format d'entrée

Utilisez le template dans resources/journal-entry-template.md.

Chaque entrée devrait inclure :

Frontmatter avec date, title, tags, et source_trigger
Une courte description factuelle de ce qui s'est passé
L'apprentissage réel, pas seulement les symptômes
Des preuves telles que erreurs, commandes, fichiers ou observations
Un bref signal de réutilisabilité décrivant si cela semble ponctuel ou récurrent

Gardez la note concrète. Les entrées de journal ne sont pas des runbooks polis.

Workflow

Examinez la tâche ou la session
Isolez l'apprentissage unique qui vaut la peine d'être préservé
Choisissez un nom de fichier daté avec un slug concis
Écrivez l'entrée de journal en utilisant le template
Incluez des preuves exactes et l'apprentissage réel
Arrêtez-vous après avoir écrit l'entrée

Ne créez pas une nouvelle compétence. Ne mettez pas à jour une compétence existante. Ne généralisez pas au-delà de ce que les preuves soutiennent.

Mode rétrospectif

Quand /claudeception est invoqué à la fin d'une session :

Examinez la session pour trouver des apprentissages dignes du journal
Préférez une entrée focalisée par incident distinct ou découverte
S'il y a plusieurs apprentissages non liés, écrivez des entrées distinctes
Résumez ce qui a été capturé et où cela a été écrit

Contrôles de qualité

Avant de finaliser une entrée de journal, vérifiez :

Le nom de fichier est daté
La note décrit quelque chose d'effectivement observé ou vérifié
La rédaction inclut une preuve ou des conditions de déclenchement concrètes
La note préserve le contexte local au lieu de l'enfler en compétence générale
Aucun secret, identifiants ou URLs sensibles ne sont inclus
Aucun nouveau fichier de compétence n'a été créé

Anti-motifs

Transformer chaque découverte en compétence réutilisable
Réécrire la note comme un runbook poli
Enlever le contexte système concret qui a rendu la découverte utile
Capturer des conclusions vagues sans preuves
Créer des entrées de journal en doublons pour le même apprentissage dans la même session

Invite d'auto-vérification

Posez-vous :

Qu'est-ce qui s'est passé qui n'était pas évident au départ ?
Quelle était la véritable cause racine ou contrainte ?
Qu'est-ce que le moi futur aurait envie de grep ?
Est-ce une note d'incident concrète ou une procédure réutilisable ?

Si c'est une note d'incident, écrivez-la dans le journal.

Si c'est une procédure réutilisable, ne la créez pas ici. Laissez cela pour un workflow de promotion distinct.