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 lacerbi/dotclaude --skill decision-boardgit clone --depth 1 https://github.com/lacerbi/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/lacerbi/dotclaude/decision-board)<a href="https://agentmods.dev/skills/lacerbi/dotclaude/decision-board"><img src="https://agentmods.dev/badge/skills/lacerbi/dotclaude/decision-board/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/lacerbi/dotclaude/decision-board"><img src="https://agentmods.dev/badge/skills/lacerbi/dotclaude/decision-board.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.00081 | $0.03918 |
| Opus 5.5 | $0.00032 | $0.01567 |
| Sonnet 5.5 | $0.00016 | $0.00784 |
| Haiku 4.5 | $0.00008 | $0.00392 |
Grade A, and why
decision-board 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 today.
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 — 161 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Decision board
A decision board is one Artifact page with a database. Claude writes the points into the database. The user answers each point on the page and submits the round, and Submit posts a comment that wakes the Claude session watching the board. Claude then replies on the cards, settles what was decided and opens the next round.
Beside this file: board.html, the page, which holds nothing about any topic, so every board uses it unchanged; board.py, which seeds a board, builds each round's writes and exports a board as Markdown; and DESIGN.md, the copy of the board on which this skill was designed.
The steps come first, from When to use it to Closing a board; the reference follows, from The data on.
When to use it
- Four or more points for the user to decide, or any point likely to need more than one round. One or two quick questions stay in the chat.
- Offer it first, in one line ("6 points to decide; put them on a board?"). A yes holds for the rest of the session.
- One board per discussion, named after its subject. A later question on the same work goes on the same board as a new point.
- It needs the
Artifact,ArtifactDataandArtifactCommentstools. Without them, as in Codex, ask in the chat. In cloud sessions, neither the tools nor the Submit notification have been tried: check that the tools exist, and use the chat when they don't.
Two levels of record
The project keeps both what a board decided and how it got there:
- The process. After each round, write the whole board into the project as one Markdown file with
board.py export. Keep it the way the project keeps plan or task files, beside the plan or task the board serves, and archive it with that plan or task. - The outcome. Write each round's decisions, for readers, into the project's own documents for them: its record of decisions, a devlog, a spec. Each entry names the board and the round and points to the board's file. It doesn't copy the discussion.
The plan or task file the board serves names the board: its link, the path of its copy, the documents that take its outcome, and the last round fully recorded. Follow the project's conventions for all of these; when it has none, ask. The board is never the only copy.
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- today Changed · +3 lines 698a6757b4ba
- 2d ago First seen · 158 lines · 81 tokens per session scan A 4e6bdbdf29db
decision-board is a skill published in the GitHub repository lacerbi/dotclaude (2 stars, last pushed yesterday), licensed MIT. It adds 81 tokens to every session and 3,918 once invoked, about $0.0003 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-10-25.
Other skills, from other repositories
grooming-sprint-tasks
Grooms sprint tasks by cross-referencing Monday.com board with GitHub issues across multiple repos, then produces subitems, descriptions, linked issues, and SP estimates. Use when grooming a sprint, planning sprint tasks, preparing for sprint planning, or when user says "groom", "sprint planning", "cross-reference…
process-mapper
Use when a BizOps lead, COO, or process-improvement owner needs to document an end-to-end business process (procurement, employee onboarding, incident handoff, customer-onboarding, claims adjudication) in BPMN-style notation, measure cycle times by stage, surface where work spends most of its time waiting vs. being…
strategic-alignment
Cascades strategy from boardroom to individual contributor. Detects and fixes misalignment between company goals and team execution. Covers strategy articulation, cascade mapping, orphan goal detection, silo identification, communication gap analysis, and realignment protocols. Use when teams are pulling in different…
mcore-split-pr
Split a PR into multiple PRs to reduce the number of required CODEOWNERS reviewer groups.
feature-prioritisation
Aplica marcos de priorización (RICE, MoSCoW, Kano, ICE, Opportunity Scoring) para clasificar características e items del backlog. Úsalo cuando se te pida priorizar características, clasificar un backlog, decidir qué construir a continuación, o evaluar compensaciones entre ideas competidoras. Produce una lista de…
design-handoff-brief
Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context…