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.
npx skills add KhaledSaeed18/dotclaude --skill decision-loggit clone --depth 1 https://github.com/KhaledSaeed18/dotclaudeWrote 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/skills/khaledsaeed18/dotclaude/decision-log)<a href="https://agentmods.dev/skills/khaledsaeed18/dotclaude/decision-log"><img src="https://agentmods.dev/badge/skills/khaledsaeed18/dotclaude/decision-log/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/skills/khaledsaeed18/dotclaude/decision-log"><img src="https://agentmods.dev/badge/skills/khaledsaeed18/dotclaude/decision-log.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.00115 | $0.00791 |
| Opus 5.5 | $0.00046 | $0.00316 |
| Sonnet 5.5 | $0.00023 | $0.00158 |
| Haiku 4.5 | $0.00012 | $0.00079 |
Grade A, and why
decision-log 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 1mo 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 — 50 lines — stays where its author put it; the contents beside it link to each section on GitHub.
An ADR is for architecture; most decisions are smaller (we will not support IE; the sprint is two weeks; the API uses cursor pagination; the thesis excludes mobile). They still get relitigated when nobody wrote them down. A decision log is the cheapest record that stops that: one file, one line per decision, appended and never rewritten.
The file
DECISIONS.md at the project root (or docs/DECISIONS.md; match the repo), newest at the bottom so git blame and diffs stay readable:
# Decision log
Format: date | decision | reason | alternatives | who | revisit when
- 2026-09-21 | Cursor pagination on all list endpoints | offset breaks under concurrent writes; clients already handle cursors | offset+limit; keyset only for large tables | API guild (A, B) | if a client cannot support cursors
- 2026-09-21 | Thesis scope excludes mobile clients | no access to a device lab; desktop covers 80% of sessions | include with emulators | K with supervisor | if the device lab opens before December
One line, under 200 words, no nested lists. Long reasoning links to a doc, an ADR, a ticket, or a meeting record.
When to add a line
- A choice between real alternatives was made, by anyone, that others will have to live with.
- A scope was cut or a request declined.
- A convention was set (naming, process, cadence).
- A decision was reversed: add a new line that says "reverses 2026-08-02 ..." and why; never edit the old line.
Do not log: the obvious, the trivial, or a decision that already has an ADR (link it instead).
Writing the line
- Decision in the imperative or declarative, specific enough to be checked ("two-week sprints starting Monday" not "agile process").
- Reason is the constraint or evidence that tipped it, not a restatement of the decision.
- Alternatives as noun phrases, at least one, honestly stated.
- Who decided or confirmed; "consensus" is allowed when true.
- Revisit when: the condition that should reopen it. This is the field that stops future relitigation: the answer to "should we reconsider?" is "only if X".
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.
- 1mo ago First seen · 50 lines · 115 tokens per session scan A 17c62fb5f4ed
decision-log is a skill published in the GitHub repository KhaledSaeed18/dotclaude (5 stars, last pushed yesterday), licensed MIT. It adds 115 tokens to every session and 791 once invoked, about $0.0005 per session on Opus 5.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-09-22.
Other skills, from other repositories
stakeholder-communication
Communicate effectively with stakeholders across functions and seniority levels. Use this skill when writing status updates, preparing executive reviews, sharing technical decisions with non-technical audiences, managing up, communicating bad news, or designing the communication cadence for a project. Triggers on…
after-action-report
Run a structured after-action review (postmortem, retrospective) on a launch, incident, or completed project to capture timeline, root cause analysis, contributing factors, and actionable lessons. Use this skill whenever the user wants to run a postmortem, retrospective, AAR, or after-action review on any past event.…
mass-ulw
Drives dependency-ordered child work through the native workflow tool, each phase's stages defined up front in one run, with retry/amend/send recovery. Use when the user asks for mass-ulw, a DAG of tasks, or fan-out work where some tasks must wait on others.
beta-program-management
Running closed and open betas that produce real signal. Beta participant selection, structured feedback collection, beta-to-GA decision criteria, and the difference between soft-launch (no structure, no signal), kitchen-sink (everyone in, no actionable feedback), and structured beta (calibrated cohort, intentional…
okr-design
OKR design as actually shipped, not as conference-talk theory. Outcome statements that drive decisions, key results that measure the right thing, scoring discipline, mid-quarter recalibration, and the difference between sandbagged OKRs (always 100%) and aspirational OKRs (always 30%) and stretch OKRs (genuine ambition…
roadmap-planning
Build a multi-quarter roadmap from a backlog of ideas, requests, and ongoing initiatives. Use this skill when planning the next quarter, sequencing dependent work, balancing build vs improve vs maintain, or making the case for what NOT to do. Triggers on roadmap, quarterly planning, what should we build next…