Un OS personnel avec Claude Code

À quoi ça sert et ce que ça change

Un OS personnel est un dossier de fichiers texte (au format Markdown, que n’importe quel éditeur ouvre) où Claude Code range ce que vous lui confiez, retrouve ce qui a été décidé et prépare la suite. Sans mémoire, chaque conversation avec Claude repart de zéro. Avec ce dossier, la conversation est jetable et le dossier devient la mémoire : ce qui compte est écrit dans un fichier, et Claude relit les fichiers avant de répondre.

Ce que contient le dossier

inbox/

La boîte de dépôt. Vous y glissez la matière brute : transcription de réunion, notes, mail copié.

CLAUDE.md

Les règles d’ingestion. Claude Code lit ce fichier au début de chaque session : il dit qui vous êtes et comment traiter une information nouvelle.

.claude/agents/

Des agents spécialisés. Un agent est un assistant qui a ses propres consignes et ses propres droits (par exemple lire sans jamais écrire).

.claude/commands/

Des commandes. Une commande est un raccourci que vous tapez dans Claude Code, comme /inbox.

05_scope/views/

Des vues générées. Ce sont des tableaux produits par un petit script à partir des fiches de sujets : on ne les modifie jamais à la main.

Trois bénéfices concrets

• Aucune décision ne se perd

  Chaque décision est enregistrée avec sa raison et sa source. Dans trois mois, vous retrouvez pourquoi un choix a été fait, sans rouvrir la discussion.

• Vous savez quoi faire ensuite

  Chaque sujet a un porteur et une prochaine action. Le board de tâches et les vues se mettent à jour à partir de vos notes, sans recopie.

• Changer de sujet coûte moins

  Une fiche par sujet, un fait dans un seul fichier. On rouvre un chantier en quelques minutes, et un rendez-vous se prépare à partir de ce qui s’est dit la dernière fois.

Ce dont on a besoin

• 01

  Claude Code installé

  La commande claude répond dans un terminal. Si ce n’est pas encore fait, le guide Claude Code explique l’installation.

• 02

  Un dossier vide

  Par exemple ~/brain. C’est le seul endroit où Claude écrit pour ce projet.

• 03

  Environ 30 minutes

  Pour l’entretien de départ, la structure et un premier essai avec une vraie note.

Facultatif : Python 3 pour générer les vues, et Git pour pouvoir revenir en arrière.

Installer Claude Code : le guide

Installer la skill

La skill personal-os mène la mise en place pas à pas. Une skill est un dossier d’instructions que Claude lit quand la tâche s’y prête : ici, elle pose les questions, propose les dossiers et écrit les fichiers après votre accord.

curl -L -o personal-os.zip \
  https://github.com/marcus-clay/design-skills/releases/latest/download/personal-os.zip
unzip -o personal-os.zip -d ~/.claude/skills

curl -L -o personal-os.zip \
  https://github.com/marcus-clay/design-skills/releases/latest/download/personal-os.zip
unzip -o personal-os.zip -d ~/.agents/skills

Créer son OS pas à pas

Sept étapes, dans cet ordre la première fois. Pour chacune, vous voyez ce qu’on dit à Claude, ce qu’on obtient, et un extrait d’un fichier du brain d’exemple chez Acme Corp (une entreprise fictive). La skill écrit les fichiers dans la langue choisie à la question 6 : les extraits sont ici dans la langue de la page, les noms de dossiers restent identiques.

1. Étape 1 / 7

   L’entretien de départ

   Claude pose sept questions, une par une, en attendant votre réponse à chacune. Des réponses courtes suffisent. À la fin, il résume ce qu’il a compris en dix lignes et attend votre accord.

   Ce qu’on dit à Claude

   CopierCopié

   Crée mon OS personnel avec la skill personal-os. Commence par l’entretien de départ.

   Ce qu’on obtient

   • 1. Votre rôle et votre équipe, en une phrase : la section « Qui je suis » du CLAUDE.md.
   • 2. Vos trois à cinq chantiers en cours : une fiche de sujet par chantier.
   • 3. Les personnes avec qui vous travaillez le plus : l’annuaire.
   • 4. Les matières que vous recevez (transcriptions, mails, notes) : le tri de l’inbox.
   • 5. Où reporter ce que vous produisez (wiki, outil de tickets) : le CHANGELOG.md.
   • 6. Votre langue et vos règles d’écriture : la section « Style ».
   • 7. Le rythme de vos revues : les commandes et agents à installer en premier.

2. Étape 2 / 7

   La structure

   Claude propose l’arborescence, puis la crée une fois que vous avez dit oui. Un principe guide tout : un fichier, un sujet, un nom neutre. Aucun fichier ne porte le nom d’une personne, ce qui la concerne va dans l’annuaire.

   Ce qu’on dit à Claude

   CopierCopié

   Propose-moi l’arborescence du dossier à partir de mes réponses. Crée-la seulement quand j’aurai dit oui.

   Ce qu’on obtient

   • Les dossiers de base, avec le rôle de chacun : inbox/ et archive/ pour la matière brute et son rangement, 00_journal/ pour les historiques, 01_steering/ pour le board, 04_decisions/ pour le registre, 05_scope/ pour les fiches et les vues.
   • Les modèles de journal, de registre, de board et de fiche, remplis avec vos réponses.

   brain/
     CLAUDE.md                  règles lues par Claude Code à chaque session
     README.md                  index pour les humains
     CHANGELOG.md               ce qu'il faut reporter dans les outils externes
     inbox/                     matières brutes à traiter
     archive/                   originaux traités (jamais modifiés)
     00_journal/
       journal.md               journal daté (ajout seulement)
       timeline.md              faits datés (ajout seulement)
       activity/                vues générées jour par jour
     01_steering/
       board.md                 tâches par horizon
     02_product/                un fichier par produit ou par thème
     03_team/
       directory.md             annuaire des personnes
     04_decisions/
       decision-register.md     décisions et raisons (ajout seulement)
     05_scope/
       sheets/                  une fiche par sujet
       views/                   tableaux générés (ne pas éditer)
     06_resources/
       glossary.md              lexique et noms à reconfirmer
     _to-decide/                ce qui attend une réponse
     scripts/
       build_views.py
     .claude/
       agents/                  un fichier par agent
       commands/                un fichier par commande

3. Étape 3 / 7

   Le fichier CLAUDE.md

   CLAUDE.md est lu automatiquement par Claude Code à chaque session. Il contient les règles du jeu : qui vous êtes, ce que Claude fait quand une information arrive, les règles de sûreté et le style d’écriture. Gardez-le court (une à deux pages) : le détail vit dans d’autres fichiers que Claude lit au besoin.

   Ce qu’on dit à Claude

   CopierCopié

   Écris le CLAUDE.md à partir de mes réponses, en une à deux pages. Il doit contenir le protocole d’ingestion, la règle de fraîcheur, les fichiers en ajout seulement et les règles de sûreté.

   Ce qu’on obtient

   • Un CLAUDE.md qui dit qui vous êtes, comment traiter une information nouvelle, et ce que Claude ne fait jamais sans votre accord.
   • La liste des noms souvent déformés par les outils de transcription, à compléter au fil du temps.

   ## Qui je suis
   
   Sam dirige une équipe de quelques designers sur deux produits : Acme Portal (espace client)
   et Acme Insights (tableaux de bord). Sam travaille avec Dana (VP Produit), Riley (directeur
   technique) et Morgan (designer produit).
   
   ## Quand une information nouvelle arrive
   
   1. Ajouter une entrée datée dans 00_journal/journal.md. Domaine entre crochets, → action,
      ? question, ! point de vigilance, rien devant un fait brut.
   2. Extraire les actions et les proposer pour 01_steering/board.md, avec leur porteur.
      Ne jamais fixer d'échéance sauf si Dana, Riley ou un document officiel l'a donnée.
   3. Router les décisions vers 04_decisions/decision-register.md (contexte, décision, raison,
      conséquences ; « raison non documentée » si absente).
   4. Ne jamais répéter un fait déjà écrit ailleurs : renvoyer vers le fichier.
   
   ## Sûreté
   
   - Proposer d'abord, écrire après validation explicite.
   - Ne jamais inventer une décision, une action ou une échéance.
   - Ne rien supprimer ni déplacer sans accord, hors du flux inbox vers archive.

4. Étape 4 / 7

   Les agents et les commandes

   Un agent et une commande sont de simples fichiers Markdown dans le dossier .claude/. Commencez petit : l’agent inbox-ingestion avec la commande /inbox pour traiter ce que vous déposez, puis la commande /journal pour consigner une note rapide. Le reste vient quand le besoin se présente.

   Ce qu’on dit à Claude

   CopierCopié

   Installe l’agent inbox-ingestion et la commande /inbox, puis la commande /journal. Vérifie qu’ils apparaissent dans /agents.

   Ce qu’on obtient

   • Les fichiers .claude/agents/inbox-ingestion.md et .claude/commands/inbox.md, puis .claude/commands/journal.md.
   • Cinq autres agents disponibles quand vous en avez besoin : board-review (revue du board), consistency-check (cohérence, lecture seule), deliverables-writer (rédaction), meeting-prep (préparation de rendez-vous, lecture seule), decision-advisor (éprouver une décision, lecture seule).
   • Les commandes /review-board, /prep-1to1 et /propagate pour plus tard.

   ---
   name: inbox-ingestion
   description: "Traite un fichier déposé dans inbox/ (compte rendu, note, transcription).
     Sépare décisions, actions, faits et questions ouvertes. Propose tout, n'écrit
     qu'après validation explicite."
   tools: Read, Grep, Glob, Edit, Write
   ---
   
   # Ingestion d'un fichier d'inbox
   
   Lis d'abord CLAUDE.md, 03_team/directory.md et 06_resources/glossary.md.
   
   ## Limites
   
   - Aucune décision, action ou échéance inventée. Une idée évoquée est une question ouverte.
   - Aucune suppression. Aucun nom corrigé de mémoire.
   - Un fait vit dans un seul fichier : le journal renvoie, il ne recopie pas.

   ---
   description: Traiter les fichiers déposés dans inbox/
   argument-hint: [nom d'un fichier de inbox/, facultatif]
   ---
   Traite ce qui est déposé dans inbox/. Utilise l'agent inbox-ingestion.
   
   1. Liste inbox/. S'il n'y a rien, dis-le et arrête-toi.
   2. Lis chaque fichier en entier. Donne un verdict par fichier.
   3. Présente la liste numérotée de modifications (fichier, avant, après, source, statut).
   4. N'écris rien tant que je n'ai pas écrit « valide tout » ou une liste de numéros.
   5. Après validation : écris, ajoute l'entrée de CHANGELOG.md, déplace l'original vers archive/.

5. Étape 5 / 7

   Le premier essai avec l’inbox

   Écrivez ou collez une vraie note, même courte, dans inbox/ (par exemple inbox/2026-01-15_point-equipe.txt), puis tapez /inbox. Claude lit le fichier en entier, repère les passages douteux, croise avec l’existant et rend une liste numérotée de modifications proposées. Rien n’est écrit tant que vous n’avez pas répondu.

   Ce qu’on dit à Claude

   CopierCopié

   /inbox

   Ce qu’on obtient

   • Une proposition numérotée : pour chaque ligne, le fichier, l’avant, l’après, la source et le statut.
   • Une liste « possibles, non retenues » pour les actions que Claude déduit lui-même, et les points à reconfirmer.
   • Vous répondez « valide 1, 2, 4 » ou « valide tout ». Claude écrit, déplace l’original dans archive/, ajoute une ligne au CHANGELOG.md et relance le script de vues.

   1. 00_journal/journal.md, ajout de l'entrée du 12 mars 2026 [PROD]
   2. 04_decisions/decision-register.md, ajout de D-003
      Décision : la checklist d'accueil v1 ne s'affiche que pour les nouveaux comptes
      Raison : limiter la charge technique avant l'été (dite par Riley)
   3. 02_product/products.md, correction en place
      Avant : API de filtres enregistrés prévue en juin 2026
      Après : prévue en avril 2026 (ancienne valeur : juin 2026, avant le 12 mars)
   4. 01_steering/board.md, 3 actions avec leur porteur
      Possibles, non retenues : mesurer le taux d'activation (déduit, non dit)
   À reconfirmer : « Dina » (Dana ?), « décaler les filtres » (idée ou décision ?)

6. Étape 6 / 7

   Les routines

   Une mémoire ne sert que si on l’alimente à intervalles réguliers. Quatre rythmes suffisent pour commencer. Demandez à Claude de les écrire dans le README.md du dossier, là où vous les verrez.

   Ce qu’on dit à Claude

   CopierCopié

   Écris dans le README.md mes quatre routines (quotidienne, après une réunion, hebdomadaire, avant un 1:1) avec la commande de chacune.

   Ce qu’on obtient

   • Une section « Routines » dans le README.md, que le chapitre « Au quotidien » détaille ci-dessous.

   ## Routines
   
   - Chaque jour : déposer dans inbox/, taper /inbox, valider.
   - Chaque semaine : /review-board, puis l'agent consistency-check.
   - Avant un 1:1 : /prep-1to1 Dana (ou Riley, Morgan).
   
   Les volumes ne sont pas écrits ici : scripts/build_views.py les calcule.

7. Étape 7 / 7

   Faire évoluer son OS

   Un nouveau sujet se crée avec une fiche dans 05_scope/sheets/. Le script build_views.py la lit et régénère les tableaux : les fiches sont la source, les vues sont des dérivés. Avant d’ajouter quoi que ce soit (fiche, agent, vue), posez-vous quatre questions : cela m’évite-t-il de perdre une décision et sa raison ? me dit-il la prochaine action et son porteur ? réduit-il l’effort pour passer d’un sujet à un autre ? laisse-t-il une trace utile à mon équipe ? Si la réponse est non partout, ne l’ajoutez pas.

   Ce qu’on dit à Claude

   CopierCopié

   Ajoute un sujet « Filtres enregistrés » : crée sa fiche dans 05_scope/sheets/ à partir du modèle, puis relance le script de vues.

   Ce qu’on obtient

   • Une fiche avec son en-tête (identifiant, statut, porteur, prochaine action, horizon, source).
   • Les vues par statut et par porteur régénérées. Vous ne les modifiez jamais à la main.

   ---
   id: INS-FLT
   title: Filtres enregistrés d'Acme Insights
   status: en attente
   owner: Riley
   next_action: Confirmer par écrit la date de l'API
   horizon: Cette semaine
   source: archive/2026-03-12_sync-portal.txt
   ---

   ## en attente (1)
   
   | ID | Sujet | Porteur | Prochaine action | Horizon |
   |---|---|---|---|---|
   | INS-FLT | Filtres enregistrés d'Acme Insights | Riley | Confirmer par écrit la date de l'API | Cette semaine |

Utiliser au quotidien

Quatre routines couvrent l’essentiel. Aucune ne demande plus de quelques minutes : l’effort est de déposer la matière, le reste est la proposition de Claude et votre validation.

• Chaque jour

  5 minutes

  Déposez ce qui est arrivé dans inbox/, tapez /inbox et validez. En fin de journée, /journal pour une note libre.

  /inbox/journal

• Après une réunion

  Dans la foulée

  Déposez la transcription ou vos notes, tapez /inbox. Vérifiez en priorité les décisions et leur raison, puis les actions et leur porteur.

  /inbox

• Chaque semaine

  15 minutes

  Tapez /review-board, puis demandez à l’agent consistency-check de contrôler les dates, les statuts et les noms. Relancez le script de vues.

  /review-boardconsistency-check

• Avant un 1:1

  5 minutes

  L’agent meeting-prep rassemble ce qui a été dit, ce qui est en attente et les questions ouvertes, avec la source de chaque ligne.

  /prep-1to1 Dana

Les cas d’usage

Sept situations, avec les personnes et produits d’Acme Corp (fictifs). Pour chacune : la situation, ce qu’on demande, ce que Claude fait.

1. 01

   Le product design au quotidien

   La situation

   Morgan, designer produit, enchaîne trois réunions dans la journée. Le soir, ses notes sont dispersées et elle ne sait plus quelle décision a été prise sur quel écran.

   Ce qu’on demande

   Elle dépose ses trois fichiers de notes dans inbox/ et tape /inbox.

   Ce que Claude fait

   Il traite les fichiers un par un, sépare décisions, actions, faits et questions ouvertes, signale un nom douteux, puis écrit et archive après validation. Le lendemain, /review-board lui donne ses cinq actions de la semaine avec leurs sources.

2. 02

   Le head of design qui définit la stratégie et pilote l’activité

   La situation

   Sam doit présenter à Dana la répartition de l’équipe entre trois sujets, et savoir où l’activité est bloquée.

   Ce qu’on demande

   « Lance le script de vues, puis donne-moi les sujets en attente et ce qui bloque, par porteur. Ensuite, demande à l’agent decision-advisor d’éprouver l’idée de mettre une personne de plus sur les filtres d’Insights. »

   Ce que Claude fait

   Il lit les vues par statut et par porteur, puis liste les sujets en attente avec leur prochaine action. L’agent relit le registre et rend ses hypothèses non vérifiées, deux alternatives et trois questions à poser à Dana.

3. 03

   Concevoir un parcours

   La situation

   Morgan doit concevoir le parcours d’arrivée dans Acme Portal pour les nouveaux comptes.

   Ce qu’on demande

   « Rassemble tout ce que le brain dit sur l’accueil des nouveaux comptes : décisions, contraintes techniques, questions ouvertes. Propose ensuite une description du parcours, étape par étape, avec les états et les cas limites. »

   Ce que Claude fait

   Il lit la fiche du sujet, le registre (D-003 limite la checklist aux nouveaux comptes) et les comptes rendus archivés. Il rend un brouillon avec les étapes, les règles de gestion, les cas limites et une section « À confirmer » pour tout ce qui n’est pas documenté.

4. 04

   Concevoir avec un MCP (Figma) en s’appuyant sur le brain

   La situation

   Un MCP est un connecteur qui donne à Claude Code l’accès à un outil externe, ici un outil de maquettes. Morgan l’a branché pour que Claude puisse lire et créer des écrans.

   Ce qu’on demande

   « Crée dans le fichier de maquettes les écrans de la checklist d’accueil, à partir de la fiche du sujet et du parcours validé. Ne fais que ce que la fiche justifie. »

   Ce que Claude fait

   Il relit la fiche et le parcours, liste les écrans à produire et demande votre validation avant de toucher au fichier. Il signale ce qui sort de la fiche, ne supprime rien sans confirmation, et ajoute une ligne au CHANGELOG.md. Les maquettes suivent le texte, pas l’inverse.

5. 05

   Déployer des prototypes

   La situation

   Riley, directeur technique, veut tester la checklist avec cinq clients avant l’été. Morgan doit fournir un prototype cliquable.

   Ce qu’on demande

   « À partir du parcours validé du sujet d’accueil, construis un prototype cliquable dans le dossier ~/prototypes/portal-onboarding. N’écris rien dans le brain. »

   Ce que Claude fait

   Il annonce ce qu’il va produire (écrans, interactions, ce qui est simulé), construit le prototype dans le dossier désigné et note les écarts avec le parcours. Les retours de test repassent ensuite par /inbox et deviennent des faits, des décisions et des actions sourcés.

6. 06

   Concevoir des présentations

   La situation

   Sam présente l’état du périmètre design au comité produit, devant des personnes qui ne sont pas designers.

   Ce qu’on demande

   « Utilise l’agent deliverables-writer pour un plan de présentation de huit diapositives : où nous en sommes, ce qui est décidé, ce qui bloque, ce que nous demandons. Lecteurs : le comité produit, sans vocabulaire de design. »

   Ce que Claude fait

   L’agent lit les vues, le registre et le board, puis propose un plan avec un message par diapositive et les sources en note. Il distingue ce qui est décidé de ce qui est envisagé, et ne prend aucun engagement à la place de Sam.

7. 07

   Mettre à jour la mémoire de tous les contenus après un changement

   La situation

   Dana annonce que le lancement d’Acme Insights passe de septembre à octobre. Cette date figure dans la fiche du sujet, le fichier produit, le board, deux pages externes et un support de présentation.

   Ce qu’on demande

   /propagate Lancement d’Acme Insights décalé de septembre à octobre 2026, annoncé par Dana le 12 mars.

   Ce que Claude fait

   Il cherche la date dans tout le dossier, choisit un fichier source où corriger la valeur (l’ancienne reste entre parenthèses), propose de renvoyer vers lui dans les autres fichiers, liste dans le CHANGELOG.md les pages externes à mettre à jour, puis fait relire le résultat par consistency-check. Un seul endroit porte la nouvelle date, et rien n’est oublié parce que la liste vient d’une recherche.

Un exemple pas à pas chez Acme Corp

Acme Corp est une entreprise fictive, tout comme Sam, Dana, Riley et Morgan. Sam, head of design, dépose la transcription d’un point de 25 minutes dans inbox/ et tape /inbox. Voici la note brute, ce que Claude repère avant de proposer, puis ce qui est écrit dans chaque fichier après « valide tout ».

La note brute

Transcription automatique, point hebdomadaire Portal et Insights, jeudi 12 mars 2026.
Présents : Sam, Dana, Riley, Morgan.

[03:30] Riley : Côté technique, la liste en bandeau est faisable avant l'été. Pour les comptes
existants, il faudrait migrer les données de profil, et on n'a pas la capacité avant juillet.
[05:00] Dana : Alors on part là-dessus : la checklist v1 uniquement pour les nouveaux comptes.
Les comptes existants, ce sera la v2.
[06:00] Morgan : Oui, je prépare les trois variantes pour la semaine prochaine.
[09:00] Riley : L'API de filtres enregistrés sera disponible en avril, plus en juin.
[09:45] Dina : Il me faudrait ça par écrit, avec la date, avant vendredi prochain, pour le comité.
[13:15] Dana : Franchement, on pourrait peut-être décaler les filtres à l'été. On verra.

Ce que Claude repère avant de proposer

• « Dina » parle à 09:45, mais l’annuaire ne contient aucune Dina et Dana est présente. Déformation de transcription probable : Claude écrit « Dana (à reconfirmer) » et ne crée aucune personne.
• « On pourrait peut-être décaler les filtres à l’été » n’est pas une décision : c’est une question ouverte.
• « Avant vendredi prochain », dit un jeudi, peut désigner le 13 ou le 20 mars. Claude retient le 20, le signale et le dit dans le board.

Ce qui est écrit, avant et après

• Le journal (ajout seulement)

  Une entrée datée est ajoutée à la fin, avec les symboles → (action), ? (question) et ! (point de vigilance). Les faits ne sont pas recopiés : l’entrée renvoie vers les fichiers où ils vivent.

  ## 2026-02-10, Rituel de revue de design
  
  [PIL] Sam met en place un rendez-vous fixe pour l'équipe design.
  
  Décision : une revue de design hebdomadaire le mardi (voir D-002, raison non documentée).

  (entrée du 10 février inchangée)
  
  ## 2026-03-12, Point hebdomadaire Portal et Insights
  
  [PROD] Point de 25 minutes avec Dana, Riley et Morgan.
  
  Décision : périmètre de la première version de la checklist d'accueil (voir D-003).
  Nouvelle date pour l'API de filtres enregistrés, voir 02_product/products.md.
  → Morgan : préparer trois variantes de la checklist
  → Riley : confirmer la date de l'API par écrit
  ? Les filtres peuvent-ils être décalés à l'été ? Évoqué par Dana, non tranché.
  ! « Dina » est probablement Dana (voir 06_resources/glossary.md).
  ! « Vendredi prochain » peut désigner le 13 ou le 20 mars.
  
  Source : archive/2026-03-12_sync-portal.txt

• Le registre de décisions (ajout seulement)

  La décision est ajoutée avec ses quatre champs. La raison est le plus important : sans elle, la décision se rediscute dans trois mois.

  ## D-001 : un seul fichier de maquettes par produit
  ## D-002 : revue de design hebdomadaire le mardi

  ## D-001 : un seul fichier de maquettes par produit
  ## D-002 : revue de design hebdomadaire le mardi
  
  ## D-003 : checklist d'accueil v1 uniquement pour les nouveaux comptes
  
  - Date : 2026-03-12
  - Décidée par : Dana (VP Produit)
  - Contexte : le support reçoit de nombreux tickets de personnes perdues à leur première
    connexion à Acme Portal.
  - Décision : la première version ne s'affiche que pour les nouveaux comptes.
    Les comptes existants verront la checklist dans une version 2.
  - Raison : migrer les données de profil des comptes existants demande une capacité
    technique que l'équipe n'a pas avant juillet (dit par Riley).
  - Conséquences : la forme finale reste à trancher après les trois variantes de Morgan.
  - Source : archive/2026-03-12_sync-portal.txt, de 03:30 à 05:00

• Le board de tâches

  Chaque action a un porteur et une source. Une échéance n’est posée que si un tiers l’a donnée, ici Dana. Ce que Claude déduit seul va dans « possibles, non retenues ».

  ## Cette semaine
  
  (aucune de ces tâches)

  ## Cette semaine
  
  - [?] Confirmer par écrit la date de l'API de filtres enregistrés
    (porteur : Riley ; échéance : vendredi 20 mars, demandée par Dana, à reconfirmer)
  
  ## Semaine suivante
  
  - [~] Préparer trois variantes de la checklist d'accueil (porteur : Morgan)
  
  ## Possibles, non retenues
  
  - Mesurer le taux d'activation après la v1 (déduit par Claude, non dit)

• La fiche de sujet

  L’en-tête de la fiche change en place (statut, porteur, prochaine action), et une ligne est ajoutée à l’historique. Le script régénère ensuite les vues.

  status: ouvert
  owner: Sam
  next_action: À préciser
  horizon: Plus tard

  status: engagé
  owner: Morgan
  next_action: Préparer trois variantes de la checklist (bandeau, fenêtre guidée, page dédiée)
  horizon: Semaine suivante
  
  ## Historique des mises à jour
  - 2026-03-12 : périmètre v1 décidé, porteur Morgan (source : archive/2026-03-12_sync-portal.txt)

• Un fait durable, corrigé en place

  Riley annonce une nouvelle date. La règle de fraîcheur s’applique : la valeur la plus récente et la plus officielle remplace l’ancienne, qui reste entre parenthèses avec sa date.

  - API de filtres enregistrés : disponibilité prévue en juin 2026.

  - API de filtres enregistrés : disponibilité prévue en avril 2026
    (ancienne valeur : juin 2026, avant le 12 mars 2026).
    Source : archive/2026-03-12_sync-portal.txt, 09:00, annonce de Riley.

• Le changelog

  Il dit, page par page, quoi reporter dans les outils externes : « ajouter » veut dire coller à la fin, « remplacer » veut dire remplacer un paragraphe identifié. Les outils externes sont des vues du brain, la source reste dans le dossier.

  ## 2026-02-10, rituel de revue de design
  
  - Wiki « Rituels de l'équipe design »
    ajouter · fin de page
    « Revue de design chaque mardi, 45 minutes. »  [x]

  ## 2026-03-12, point hebdomadaire Portal et Insights
  
  - Wiki « Acme Portal, checklist d'accueil »
    remplacer · paragraphe « Périmètre de la v1 »
    « La première version s'affiche uniquement pour les nouveaux comptes. »  [ ]
  - Wiki « Acme Insights, feuille de route »
    remplacer · ligne « API de filtres enregistrés »
    « Disponibilité prévue : avril 2026 (en attente de confirmation écrite). »  [ ]
  - Wiki « Décisions de l'équipe design »
    ajouter · fin de page
    « 12 mars 2026, D-003 : checklist v1 pour les nouveaux comptes seulement. »  [ ]
  
  ## 2026-02-10, rituel de revue de design
  (inchangé)

Pour finir, Claude déplace l’original vers archive/, relance python3 scripts/build_views.py et liste ce qui a été fait. Il laisse à Sam trois points à trancher : confirmer que « Dina » est Dana, confirmer l’échéance du 20 mars, prendre ou écarter les lignes « possibles, non retenues ».

Les règles de sûreté

Ces règles sont copiées dans le CLAUDE.md et valent pour tous les agents.

1. 01

   Claude propose, vous validez, puis il écrit

   Il présente d’abord ce qu’il compte modifier. Il n’écrit qu’après votre accord explicite (« valide tout » ou une liste de numéros).

2. 02

   Il n’invente jamais une décision

   Une décision, une action ou une échéance qui n’est pas dans le texte n’est pas créée. Si la raison manque, il écrit « raison non documentée ».

3. 03

   Il signale les doutes

   Un passage ambigu, une date sans année ou un nom qui ressemble à une déformation de transcription donnent lieu à une question, jamais à un choix silencieux.

4. 04

   Rien n’est supprimé sans accord

   Aucun fichier n’est supprimé ni déplacé hors du flux prévu (inbox vers archive) sans que vous l’ayez demandé.

5. 05

   Un fait, une idée et un engagement restent distincts

   Ce qui est fait, ce que vous avez promis à quelqu’un et ce que vous envisagez sont trois statuts. Une suggestion de Claude n’est jamais présentée comme un engagement.

6. 06

   Chaque ligne garde sa source

   Chaque fait important renvoie à son fichier d’origine et à sa date, jamais à un résumé produit à partir du brain.

Questions fréquentes

Mes notes restent-elles privées ?

Les fichiers restent sur votre machine. En revanche, Claude Code lit leur contenu pour répondre, donc ce qu’il lit est envoyé au modèle pendant la session. Évitez d’y mettre des mots de passe ou des données personnelles inutiles.

Faut-il savoir coder ?

Non. Tout est en fichiers texte que Claude écrit pour vous. Seul le script de vues demande Python 3, et il est facultatif.

Et si Claude se trompe ?

Rien n’est écrit sans votre accord, chaque ligne a sa source et l’original est archivé sans modification. Avec Git, vous pouvez en plus revenir à l’état précédent du dossier.

Cela marche-t-il avec Codex ou Claude.ai ?

La skill s’installe aussi dans Codex et dans Claude.ai, et elle vous guide pour la structure et les règles. Les agents et les commandes comme /inbox sont des fichiers du dossier .claude/, lus par Claude Code.

Pour aller plus loin

• Le guide Claude CodeDe l’installation au déploiement, pour les designers.
• Le catalogue de skillsLes skills que j’utilise, à installer en une commande.
• La page ClaudeComment je travaille avec Claude au quotidien.