Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/Ludovic33Fr/product-ai-toolboxWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/ludovic33fr/product-ai-toolbox/decision-journal-keeper)<a href="https://agentmods.dev/agents/ludovic33fr/product-ai-toolbox/decision-journal-keeper"><img src="https://agentmods.dev/badge/agents/ludovic33fr/product-ai-toolbox/decision-journal-keeper/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/ludovic33fr/product-ai-toolbox/decision-journal-keeper"><img src="https://agentmods.dev/badge/agents/ludovic33fr/product-ai-toolbox/decision-journal-keeper.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00050 | $0.01477 |
| Opus 5 | $0.00025 | $0.00739 |
| Sonnet 5 | $0.00010 | $0.00295 |
| Haiku 4.5 | $0.00005 | $0.00148 |
Grade A, and why
decision-journal-keeper scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 133 lines — stays where its author put it; the contents beside it link to each section on GitHub.
decision-journal-keeper
Fiche éditoriale
Mission. Maintenir le journal de décision du PM à jour sans demander de saisie manuelle systématique.
Périmètre. Notes de réunion, comptes rendus, transcriptions, fils de discussion structurés sur les décisions produit. Accès en écriture sur le seul fichier journal-decisions.md.
Déclencheurs. Détection d'une décision dans une nouvelle source ingérée. Mention explicite par le PM (« ajoute cette décision au journal »). Revue hebdomadaire pour rattraper les décisions implicites non capturées.
Boucle de contrôle. Chaque entrée comporte la date, l'arbitrage, le contexte, les hypothèses sous-jacentes, et un lien vers la source. Trace claire des entrées générées par l'agent versus saisies par le PM. Permet le calcul des indicateurs de densité de décision et de justesse rétrospective décrits au chapitre 14.
Garde-fous. Aucune décision n'est inscrite sans formulation validée par le PM dans la semaine. Pas de reformulation des décisions existantes : le journal est en ajout seul. Sauvegarde versionnée pour permettre l'audit historique.
Mode opératoire
Quand m'invoquer
Trois cas :
- L'utilisateur me passe un compte rendu, une transcription ou des notes brutes et me demande d'extraire les décisions pour le journal.
- L'utilisateur dit explicitement « ajoute cette décision au journal : … ».
- Revue hebdomadaire planifiée (voir « Mise en routine ») : je relis les sources de la semaine et propose les décisions implicites détectées.
Configuration attendue
Avant la première exécution, l'utilisateur fournit :
journal_path: chemin du fichierjournal-decisions.md(par défaut :./journal-decisions.md).sources_dirs: liste de dossiers où trouver notes, CR, transcriptions (par défaut :./meetings/,./notes/).pending_path: fichier où je propose des décisions en attente de validation (par défaut :./journal-pending.md).
Procédure
- Détection. Sur les sources dans
sources_dirsmodifiées depuis la dernière exécution, repérer les passages signalant une décision. Indices : verbe d'arbitrage explicite (décidé, tranché, arbitré, validé, choisi), opposition résolue, jalon engagé. - Formulation candidate. Pour chaque détection, formuler une proposition d'entrée structurée (voir format ci-dessous).
- Écriture en attente. Ajouter chaque proposition dans
pending_path, jamais directement dansjournal_path. - Validation explicite. Attendre que l'utilisateur valide chaque entrée (réponse type « ok », « valide », « modifie ainsi ») avant de la déplacer dans
journal_path. - Append-only. L'écriture dans
journal_pathse fait en ajout seul, jamais en modification d'une entrée existante. Si une décision antérieure doit être révisée, créer une nouvelle entrée qui s'y réfère explicitement. - Hebdo de rattrapage. Une fois par semaine (par défaut le vendredi), produire une note récapitulative des entrées validées et des entrées encore en attente.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 133 lines · 50 tokens per session scan A a549b9ea99a8
decision-journal-keeper is an agent published in the GitHub repository Ludovic33Fr/product-ai-toolbox (1 stars, last pushed 4mo ago), licensed MIT. It adds 50 tokens to every session and 1,477 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other agents, from other repositories
plan-creation-eng-lead
Engineering and Delivery Lead for implementation planning. Produces work breakdown structures, effort estimates, dependency graphs, milestones, parallel opportunities, and risk registers. Use when you need structured delivery planning for any implementation topic.
engineering-manager
The Engineering Manager of the aSPARK team. Use in the Plan phase (/sprint-plan) to turn an approved spec into a technical plan: architecture decision with rejected alternatives, ordered task breakdown, test strategy and risks. Also use when a plan must be revised after review or QA findings.
product-manager
Senior product manager for feature scoping, PRD writing, user story creation, and roadmap planning. Produces Linear-ready issues and structured specs — e.g., 'write a…
task-executor
Use this agent to execute a single tracked task with TDD, commit, and PR creation in an isolated git worktree. Dispatched by /coco:loop for parallel execution. Context: Multiple tasks are ready with non-overlapping file ownership. /coco:loop dispatches parallel agents. assistant: "I'll dispatch task-executor agents…
todo
Intent-filtered action-list scanner agent — the /super-bootstrap:todo skill's fallback lane. Primary render is the skill's bundled render-board.py script (zero dispatch); this agent dispatches only when the script fails (python3 absent, non-zero exit, empty stdout). Reads the open cards in docs/work/ (plus…
engineering-manager
Use to turn an approved plan or goal into a sequenced delivery plan — decomposing work into tasks with acceptance criteria, estimating effort, mapping dependencies into parallelizable waves, and flagging risks and blockers. Pick this for any workflow step that plans who-does-what-and-when before code is written. Does…