Claudeception

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

Il ne crée ni ne met à jour de skills. 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 par un workflow séparé.

Quand l'utiliser

Utilisez ce skill dans l'un de ces cas :

Une tâche a nécessité du débogage ou une investigation non évidente
Un contournement ou un chemin de récupération a été découvert par essais et erreurs
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 « enregistre cela comme un skill », « extrais un skill de cela » ou « qu'avons-nous appris ? »

N'utilisez pas ce skill pour créer de la connaissance procédurale durable. Si l'apprentissage doit devenir un skill réutilisable, laissez cela pour une étape de promotion séparée.

Règle essentielle

Ne créez jamais un skill à partir de ce skill.

Même quand l'utilisateur dit « enregistre cela comme un skill », honorez l'intention en écrivant une entrée de journal à moins qu'il ne demande explicitement un workflow de création de skill séparé.

Seuil de capture

Écrivez une entrée de journal quand la session a produit une connaissance qui vaut la peine d'être préservée, même si elle est étroite 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 profondes derrière les défaillances confuses
Compromis investigués et contournements
Motifs répétés qui ne sont pas encore généralisés

Ignorer la capture quand :

La tâche était une simple recherche de documentation
La conclusion est déjà bien couverte par un skill existant ou la documentation du projet
La note ne ferait que répéter une connaissance évidente
La note nécessiterait de stocker des secrets ou des détails internes sensibles

Emplacement de sortie

Écrivez les entrées dans :

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

Exemples :

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

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

Format de l'entrée

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

Chaque entrée doit inclure :

Un frontmatter avec date, title, tags et source_trigger
Une brève description factuelle de ce qui s'est passé
L'apprentissage réel, pas seulement les symptômes
Des preuves telles que des erreurs, commandes, fichiers ou observations
Un bref signal de réutilisation 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'unique apprentissage 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 modèle
Incluez des preuves exactes et la véritable conclusion
Arrêtez-vous après avoir écrit l'entrée

Ne créez pas un nouveau skill. Ne mettez pas à jour un skill existant. 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 les apprentissages dignes du journal
Préférez une entrée ciblée par incident ou découverte distinct
S'il y a plusieurs apprentissages non liés, écrivez des entrées séparées
Résumez ce qui a été capturé et où cela a été écrit

Portes de qualité

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

Le nom de fichier est daté
La note décrit quelque chose réellement observé ou vérifié
La writeup inclut des preuves ou des conditions de déclenchement concrètes
La note préserve le contexte local au lieu de le transformer en skill général
Aucun secret, identifiant ou URL sensible n'est inclus
Aucun nouveau fichier de skill n'a été créé

Anti-motifs

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

Prompts d'auto-vérification

Posez-vous :

Qu'est-ce qui s'est passé et qui n'était pas évident au départ ?
Quelle était la véritable cause racine ou contrainte ?
Qu'est-ce que mon futur moi voudrait 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-la pour un workflow de promotion séparé.