decision-logger

Overview of decision-logger skill

What decision-logger does

decision-logger is a Decision Support skill for turning board-meeting outcomes into a durable two-layer decision memory. Layer 1 preserves raw meeting context; Layer 2 stores only approved decisions, owners, deadlines, rejected options, and follow-up items. The point is practical: future AI-assisted meetings should rely on confirmed decisions, not unresolved debate or hallucinated consensus.

Best fit for board and executive workflows

The decision-logger skill is best for founders, chiefs of staff, board operators, and AI agents supporting recurring executive meetings. It fits workflows where decisions need to survive across meetings, be searchable later, and remain separate from discussion notes. It is especially useful when a board-meeting style process ends with founder approval and then needs a clean, auditable record.

Key differentiator: approved memory only

The strongest design choice is the separation between raw transcripts and the approved Layer 2 index. Future reviews read the approved layer, not every argument from the meeting. This helps prevent old rejected ideas from reappearing as if they were still viable. The template also includes DO_NOT_RESURFACE, supersession fields, review dates, and owner tracking, which makes it more operational than a generic “summarize meeting notes” prompt.

What to check before installing

Before adopting decision-logger, confirm that your team is comfortable maintaining a local decision index at ~/.claude/decisions/approved/decisions.md. The included Python helper reads that file and can report overdue items, conflicts, owner-specific actions, and keyword searches. If your process does not distinguish approved decisions from discussion notes, you may need to adjust your meeting workflow first.

How to Use decision-logger skill

decision-logger install and files to inspect first

Install the skill from the repository path:

npx skills add alirezarezvani/claude-skills --skill decision-logger

After installation, read these files in order:

1. SKILL.md — explains the two-layer memory model, slash-command intent, and expected storage locations.
2. templates/decision-entry.md — shows the exact Layer 2 entry format.
3. scripts/decision_tracker.py — provides reporting commands for summary, overdue items, conflicts, owner filters, and search.

The script uses Python standard library only, so there is no dependency setup beyond having Python available.

Inputs the skill needs to work well

For strong decision-logger usage, give the agent more than a rough meeting summary. Provide the agenda item, the final approved decision, accountable owner, due date, review date, rationale, rejected alternatives, and any founder override. The template expects one decision per entry, so split bundled outcomes into separate records.

Weak input: “Log that we discussed pricing and decided to test something.”

Better input: “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.”

Practical workflow after a meeting

Use decision-logger after approval, not during open debate. A reliable workflow is:

1. Save or reference the raw transcript in Layer 1.
2. Ask the agent to extract only founder-approved outcomes.
3. Create a Layer 2 entry using templates/decision-entry.md.
4. Mark rejected options with reasons and DO_NOT_RESURFACE.
5. Run the tracker script to check summaries, overdue actions, or conflicts.

Useful commands from the repository include:

• python scripts/decision_tracker.py --demo
• python scripts/decision_tracker.py --summary
• python scripts/decision_tracker.py --overdue
• python scripts/decision_tracker.py --conflicts
• python scripts/decision_tracker.py --owner "CTO"
• python scripts/decision_tracker.py --search "pricing"
• python scripts/decision_tracker.py --due-within 7

Prompt pattern for better entries

A good invocation should ask for a decision entry, not a narrative summary. For example:

“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.”

This framing reduces ambiguity and keeps Layer 2 clean enough for later Decision Support.

decision-logger skill FAQ

Is decision-logger only for board meetings?

It is designed around board and C-level decision memory, but it can also work for investment committees, leadership staff meetings, product councils, or governance reviews. The key requirement is that decisions are formally approved and need follow-up. It is less useful for brainstorming sessions where no final decision is made.

How is this better than asking AI to summarize minutes?

A normal summary often blends discussion, recommendations, objections, and decisions. decision-logger forces structure: approved decision, owner, deadline, rationale, rejected options, action items, supersession, and raw transcript link. That structure is what enables later review, overdue checks, and conflict detection.

Does the decision-logger skill require a database?

No. The repository evidence points to markdown-based storage and a Python standard-library script. The main Layer 2 index is expected at ~/.claude/decisions/approved/decisions.md, with legacy support for another file path via --file. This makes it lightweight, but teams needing multi-user permissions, dashboards, or audit logs may need additional tooling.

When should I not use decision-logger?

Do not use it as a dumping ground for every meeting note. It is also a poor fit if decisions change constantly without owners or dates, or if your organization cannot identify what was actually approved. In those cases, a meeting-notes skill or project-management integration may be more appropriate before adding decision memory.

How to Improve decision-logger skill

Improve decision-logger results with cleaner approvals

The most important quality factor is approval clarity. Before logging, verify: What exactly was decided? Who owns it? By when? What was explicitly rejected? What should future agents avoid resurfacing? If any of those are missing, ask a follow-up question instead of creating a vague entry.

Common failure modes to prevent

Watch for entries that contain multiple decisions in one paragraph, shared ownership with no accountable person, deadlines like “soon,” rationale that restates the decision, or rejected ideas without reasons. These weaken later search and review. The template’s field rules are worth treating as constraints, not suggestions.

Iterate after the first generated entry

After the agent drafts an entry, review it like an operations record. Tighten the decision to one sentence, convert names or roles into a single owner, replace relative dates with YYYY-MM-DD, and ensure action items are checkable. Then run --summary, --overdue, or --conflicts to verify the entry behaves well in the tracker.

Extend the skill for your operating model

Teams can improve decision-logger by adding consistent agenda tags, board committee labels, risk level, decision type, or links to project tickets. Keep extensions compatible with the markdown index and avoid adding fields no one will maintain. The goal is not richer documentation for its own sake; it is cleaner Decision Support for the next meeting.