decision-logger
par alirezarezvanidecision-logger est un skill d’aide à la décision pour les décisions de conseil approuvées. Il sépare les transcriptions brutes d’un index décisionnel Layer 2, suit les responsables, les échéances, les options rejetées et les suivis, et inclut un tracker Python pour les synthèses, les éléments en retard, les conflits, les filtres par responsable et la recherche.
Ce skill obtient 80/100, ce qui en fait un bon candidat pour les utilisateurs d’annuaire qui ont besoin d’une mémoire structurée des décisions de conseil et d’un suivi des actions. Il offre davantage de prise aux agents qu’un prompt générique grâce à des déclencheurs définis, un format durable pour les décisions approuvées et un script de reporting, même si son adoption est plus simple dans le workflow C-Level Advisor qui l’entoure.
- Conditions de déclenchement claires dans la description : après les réunions de conseil, lors de la revue des décisions approuvées ou pour vérifier les actions en retard.
- Le contenu opérationnel est bien présent : SKILL.md définit un modèle de mémoire décisionnelle en deux couches, brut/approuvé, ainsi que des commandes, des mots-clés et des cas d’usage.
- Inclut un support exécutable avec scripts/decision_tracker.py, ainsi qu’un modèle de saisie de décision avec des règles de champs pour homogénéiser les entrées Layer 2.
- Aucune commande d’installation ni aucun README n’est fourni dans le chemin du skill ; les utilisateurs doivent donc déduire l’installation à partir de la structure globale du dépôt.
- Le workflow semble conçu pour l’écosystème C-Level Advisor/réunions de conseil et pour des commandes slash comme /cs:decisions et /cs:review, ce qui peut limiter son intérêt en usage autonome.
Présentation de la skill decision-logger
Ce que fait decision-logger
decision-logger est une skill de Decision Support conçue pour transformer les conclusions de réunions de conseil en une mémoire décisionnelle durable à deux niveaux. Le niveau 1 conserve le contexte brut de la réunion ; le niveau 2 ne stocke que les décisions approuvées, les responsables, les échéances, les options rejetées et les actions de suivi. L’objectif est très concret : lors de futures réunions assistées par IA, il faut s’appuyer sur des décisions confirmées, et non sur des débats non tranchés ou sur un consensus halluciné.
Le meilleur usage pour les conseils et les directions
La skill decision-logger convient particulièrement aux fondateurs, chiefs of staff, opérateurs de conseil d’administration et agents IA qui accompagnent des réunions exécutives récurrentes. Elle s’intègre bien dans les workflows où les décisions doivent survivre d’une réunion à l’autre, rester consultables plus tard et être séparées des notes de discussion. Elle est surtout utile lorsqu’un processus de type board-meeting se termine par une validation du fondateur et doit ensuite produire un registre clair, propre et vérifiable.
Différenciateur clé : uniquement la mémoire approuvée
Le choix de conception le plus fort est la séparation entre les transcriptions brutes et l’index approuvé du niveau 2. Les revues futures consultent le niveau approuvé, pas tous les arguments échangés pendant la réunion. Cela évite que d’anciennes idées rejetées réapparaissent comme si elles étaient toujours envisageables. Le modèle inclut aussi DO_NOT_RESURFACE, des champs de remplacement, des dates de revue et le suivi des responsables, ce qui le rend plus opérationnel qu’un simple prompt de type « résumer les notes de réunion ».
Points à vérifier avant l’installation
Avant d’adopter decision-logger, vérifiez que votre équipe est à l’aise avec la maintenance d’un index décisionnel local dans ~/.claude/decisions/approved/decisions.md. L’assistant Python inclus lit ce fichier et peut signaler les éléments en retard, les conflits, les actions par responsable et les recherches par mot-clé. Si votre processus ne distingue pas encore clairement les décisions approuvées des notes de discussion, vous devrez probablement ajuster votre workflow de réunion en amont.
Comment utiliser la skill decision-logger
Installation de decision-logger et fichiers à inspecter en premier
Installez la skill depuis le chemin du dépôt :
npx skills add alirezarezvani/claude-skills --skill decision-logger
Après l’installation, lisez ces fichiers dans l’ordre :
SKILL.md— explique le modèle de mémoire à deux niveaux, l’intention de la slash-command et les emplacements de stockage attendus.templates/decision-entry.md— montre le format exact d’une entrée de niveau 2.scripts/decision_tracker.py— fournit des commandes de reporting pour les synthèses, les éléments en retard, les conflits, les filtres par responsable et la recherche.
Le script utilise uniquement la bibliothèque standard Python : il n’y a donc aucune dépendance à installer, en dehors de Python lui-même.
Les entrées nécessaires pour de bons résultats avec la skill
Pour bien utiliser decision-logger, donnez à l’agent davantage qu’un résumé approximatif de réunion. Fournissez le point d’agenda, la décision finale approuvée, le responsable redevable, l’échéance, la date de revue, le rationnel, les alternatives rejetées et tout éventuel arbitrage du fondateur. Le modèle attend une décision par entrée : si plusieurs décisions sont regroupées, séparez-les en enregistrements distincts.
Entrée faible : « Note qu’on a discuté des prix et décidé de tester quelque chose. »
Meilleure entrée : « Log the approved decision from the 2026-03-05 board meeting: move from flat pricing to a three-tier pilot for new customers. Owner: CRO. Deadline: 2026-04-15. Review: 2026-05-01. Rationale: improves expansion path while limiting migration risk. Rejected: immediate migration of all existing customers because support load is too high. Raw transcript path: ~/.claude/decisions/raw/2026-03-05-pricing.md. »
Workflow pratique après une réunion
Utilisez decision-logger après validation, pas pendant un débat encore ouvert. Un workflow fiable consiste à :
- Enregistrer ou référencer la transcription brute dans le niveau 1.
- Demander à l’agent d’extraire uniquement les conclusions approuvées par le fondateur.
- Créer une entrée de niveau 2 avec
templates/decision-entry.md. - Marquer les options rejetées avec leurs raisons et
DO_NOT_RESURFACE. - Exécuter le script de suivi pour vérifier les synthèses, les actions en retard ou les conflits.
Commandes utiles présentes dans le dépôt :
python scripts/decision_tracker.py --demopython scripts/decision_tracker.py --summarypython scripts/decision_tracker.py --overduepython scripts/decision_tracker.py --conflictspython scripts/decision_tracker.py --owner "CTO"python scripts/decision_tracker.py --search "pricing"python scripts/decision_tracker.py --due-within 7
Modèle de prompt pour de meilleures entrées
Une bonne invocation doit demander une entrée de décision, pas un résumé narratif. Par exemple :
« Use the decision-logger skill to create a Layer 2 approved decision entry. Include one clear decision statement, one accountable owner, deadline, review date, rationale, rejected proposals with DO_NOT_RESURFACE, action items, supersedes fields if applicable, and the raw transcript path. Do not include unapproved discussion points. »
Ce cadrage réduit l’ambiguïté et garde le niveau 2 suffisamment propre pour un usage ultérieur en Decision Support.
FAQ de la skill decision-logger
decision-logger sert-elle uniquement aux réunions de conseil ?
Elle est pensée pour la mémoire décisionnelle des conseils d’administration et des équipes dirigeantes, mais elle peut aussi convenir à des comités d’investissement, réunions de leadership, conseils produit ou revues de gouvernance. La condition essentielle est que les décisions soient formellement approuvées et nécessitent un suivi. Elle est moins utile pour des séances de brainstorming où aucune décision finale n’est prise.
En quoi est-ce mieux que de demander à l’IA de résumer un compte rendu ?
Un résumé classique mélange souvent discussion, recommandations, objections et décisions. decision-logger impose une structure : décision approuvée, responsable, échéance, rationnel, options rejetées, actions, remplacement éventuel et lien vers la transcription brute. C’est cette structure qui permet ensuite la revue, la détection des retards et l’identification des conflits.
La skill decision-logger nécessite-t-elle une base de données ?
Non. Les éléments du dépôt indiquent un stockage en markdown et un script Python fondé sur la bibliothèque standard. L’index principal de niveau 2 est attendu dans ~/.claude/decisions/approved/decisions.md, avec une prise en charge héritée d’un autre chemin de fichier via --file. Cela rend l’ensemble léger, mais les équipes qui ont besoin de permissions multi-utilisateurs, de tableaux de bord ou de journaux d’audit devront peut-être ajouter d’autres outils.
Quand vaut-il mieux ne pas utiliser decision-logger ?
Ne l’utilisez pas comme fourre-tout pour toutes les notes de réunion. C’est aussi un mauvais choix si les décisions changent constamment sans responsable ni date, ou si votre organisation n’arrive pas à identifier ce qui a réellement été approuvé. Dans ces cas, une skill de notes de réunion ou une intégration à un outil de gestion de projet peut être plus adaptée avant d’ajouter une mémoire décisionnelle.
Comment améliorer la skill decision-logger
Améliorer les résultats de decision-logger avec des validations plus nettes
Le facteur de qualité le plus important est la clarté de la validation. Avant de consigner une décision, vérifiez : qu’a-t-on exactement décidé ? Qui en est responsable ? Pour quelle date ? Qu’est-ce qui a été explicitement rejeté ? Que les futurs agents doivent-ils éviter de reproposer ? S’il manque l’un de ces éléments, posez une question de clarification plutôt que de créer une entrée vague.
Modes d’échec fréquents à éviter
Surveillez les entrées qui contiennent plusieurs décisions dans un même paragraphe, une responsabilité partagée sans personne clairement redevable, des échéances comme « bientôt », un rationnel qui répète simplement la décision, ou des idées rejetées sans raison associée. Tout cela affaiblit les recherches et les revues ultérieures. Les règles de champ du modèle doivent être traitées comme des contraintes, pas comme de simples suggestions.
Itérer après la première entrée générée
Une fois l’entrée rédigée par l’agent, relisez-la comme un enregistrement opérationnel. Ramenez la décision à une phrase, convertissez les noms ou rôles en un seul responsable, remplacez les dates relatives par YYYY-MM-DD et vérifiez que les actions sont contrôlables. Exécutez ensuite --summary, --overdue ou --conflicts pour vous assurer que l’entrée se comporte correctement dans le tracker.
Adapter la skill à votre modèle opérationnel
Les équipes peuvent améliorer decision-logger en ajoutant des tags d’agenda cohérents, des libellés de comité, un niveau de risque, un type de décision ou des liens vers des tickets projet. Gardez ces extensions compatibles avec l’index markdown et évitez d’ajouter des champs que personne ne maintiendra. Le but n’est pas de produire une documentation plus riche pour elle-même ; c’est d’obtenir un Decision Support plus propre pour la réunion suivante.