decision-logger
Maintains a structured record of meeting transcripts and finalized decisions.
Install
mkdir -p .claude/skills/decision-logger && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/7926" && unzip -o skill.zip -d .claude/skills/decision-logger && rm skill.zipInstalls to .claude/skills/decision-logger
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Two-layer memory architecture for board meeting decisions. Manages raw transcripts (Layer 1) and approved decisions (Layer 2). Use when logging decisions after a board meeting, reviewing past decisions with /cs:decisions, or checking overdue action items with /cs:review. Invoked automatically by the board-meeting skill after Phase 5 founder approval.Key capabilities
- →Log board meeting decisions using two-layer memory
- →Search historical approved decisions
- →Track overdue action items
- →Detect conflicts in decision history
How it works
The skill maintains a two-layer system where Layer 1 stores raw transcripts and Layer 2 stores only founder-approved decisions for future reference.
Inputs & outputs
When to use decision-logger
- →Log outcomes from board meetings
- →Search past meeting decisions
- →Verify approved project requirements
About this skill
Decision Logger
Two-layer memory system. Layer 1 stores everything. Layer 2 stores only what the founder approved. Future meetings read Layer 2 only — this prevents hallucinated consensus from past debates bleeding into new deliberations.
Keywords
decision log, memory, approved decisions, action items, board minutes, /cs:decisions, /cs:review, conflict detection, DO_NOT_RESURFACE
Quick Start
python scripts/decision_tracker.py --demo # See sample output
python scripts/decision_tracker.py --summary # Overview + overdue
python scripts/decision_tracker.py --overdue # Past-deadline actions
python scripts/decision_tracker.py --conflicts # Contradiction detection
python scripts/decision_tracker.py --owner "CTO" # Filter by owner
python scripts/decision_tracker.py --search "pricing" # Search decisions
Commands
| Command | Effect |
|---|---|
/cs:decisions | Last 10 approved decisions |
/cs:decisions --all | Full history |
/cs:decisions --owner CMO | Filter by owner |
/cs:decisions --topic pricing | Search by keyword |
/cs:review | Action items due within 7 days |
/cs:review --overdue | Items past deadline |
Two-Layer Architecture
Storage follows the canonical two-layer decision memory (see ../agent-protocol/SKILL.md → "Decision Memory (Canonical Layout)") — the same layout /cs:decide writes.
Layer 1 — Raw Transcripts
Location: ~/.claude/decisions/raw/YYYY-MM-DD-<slug>.md
- Full Phase 2 agent contributions, Phase 3 critique, Phase 4 synthesis
- All debates, including rejected arguments
- NEVER auto-loaded. Only on explicit founder request.
- Archive after 90 days →
~/.claude/decisions/raw/archive/YYYY/
Layer 2 — Approved Decisions
Location: ~/.claude/decisions/approved/ — one record per decision (YYYY-MM-DD-<slug>.md) plus the append-only index decisions.md
- ONLY founder-approved decisions, action items, user corrections
- Loaded automatically in Phase 1 of every board meeting
- Append-only. Decisions are never deleted — only superseded.
- Managed by Chief of Staff after Phase 5. Never written by agents directly.
Migration: a legacy memory/board-meetings/ folder may exist from earlier versions; read it for history but write all new entries to ~/.claude/decisions/.
Decision Entry Format
## [YYYY-MM-DD] — [AGENDA ITEM TITLE]
**Decision:** [One clear statement of what was decided.]
**Owner:** [One person or role — accountable for execution.]
**Deadline:** [YYYY-MM-DD]
**Review:** [YYYY-MM-DD]
**Rationale:** [Why this over alternatives. 1-2 sentences.]
**User Override:** [If founder changed agent recommendation — what and why. Blank if not applicable.]
**Rejected:**
- [Proposal] — [reason] [DO_NOT_RESURFACE]
**Action Items:**
- [ ] [Action] — Owner: [name] — Due: [YYYY-MM-DD] — Review: [YYYY-MM-DD]
**Supersedes:** [DATE of previous decision on same topic, if any]
**Superseded by:** [Filled in retroactively if overridden later]
**Raw transcript:** ~/.claude/decisions/raw/[DATE]-<slug>.md
Conflict Detection
Before logging, Chief of Staff checks for:
- DO_NOT_RESURFACE violations — new decision matches a rejected proposal
- Topic contradictions — two active decisions on same topic with different conclusions
- Owner conflicts — same action assigned to different people in different decisions
When a conflict is found:
⚠️ DECISION CONFLICT
New: [text]
Conflicts with: [DATE] — [existing text]
Options: (1) Supersede old (2) Merge (3) Defer to founder
DO_NOT_RESURFACE enforcement:
🚫 BLOCKED: "[Proposal]" was rejected on [DATE]. Reason: [reason].
To reopen: founder must explicitly say "reopen [topic] from [DATE]".
Logging Workflow (Post Phase 5)
- Founder approves synthesis
- Write Layer 1 raw transcript →
~/.claude/decisions/raw/YYYY-MM-DD-<slug>.md - Check conflicts against
~/.claude/decisions/approved/decisions.md - Surface conflicts → wait for founder resolution
- Write the approved record to
~/.claude/decisions/approved/YYYY-MM-DD-<slug>.mdand append to the indexdecisions.md - Confirm: decisions logged, actions tracked, DO_NOT_RESURFACE flags added
Marking Actions Complete
- [x] [Action] — Owner: [name] — Completed: [DATE] — Result: [one sentence]
Never delete completed items. The history is the record.
File Structure
~/.claude/decisions/
├── raw/YYYY-MM-DD-<slug>.md # Layer 1: full transcript per meeting
├── raw/archive/YYYY/ # Raw files after 90 days
├── approved/YYYY-MM-DD-<slug>.md # Layer 2: one record per approved decision
└── approved/decisions.md # Layer 2 index: append-only, founder-approved
References
templates/decision-entry.md— single entry template with field rulesscripts/decision_tracker.py— CLI parser, overdue tracker, conflict detector
When not to use it
- →When attempting to write directly to the decision log as an agent
- →When the decision has not been approved by the founder
Prerequisites
Limitations
- →Decisions must be approved by the founder
- →Agents cannot write directly to the log
How it compares
It prevents hallucinated consensus by separating raw debate from approved outcomes, unlike a flat log.
Compared to similar skills
decision-logger side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| decision-logger (this skill) | 0 | 2mo | Review | Intermediate |
| ejs-session-init | 0 | 4mo | Review | Beginner |
| pmbok-project-management | 38 | 9mo | No flags | Intermediate |
| project-planner | 32 | 9mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by alirezarezvani
View all by alirezarezvani →You might also like
ejs-session-init
McFuzzySquirrel
>
pmbok-project-management
jgtolentino
Comprehensive PMP/PMBOK project management methodologies and best practices. Use this skill when users need guidance on project management processes, templates, knowledge areas, process groups, tools, techniques, or certification preparation. Covers all 10 PMBOK Knowledge Areas and 5 Process Groups with practical templates, frameworks, and industry-standard approaches. Includes risk management, stakeholder engagement, schedule management, cost control, quality assurance, and resource planning.
project-planner
adrianpuiu
Comprehensive project planning and documentation generator for software projects. Creates structured requirements documents, system design documents, and task breakdown plans with implementation tracking. Use when starting a new project, defining specifications, creating technical designs, or breaking down complex systems into implementable tasks. Supports user story format, acceptance criteria, component design, API specifications, and hierarchical task decomposition with requirement traceability.
spec-kit-workflow
jmanhype
Guides specification-driven development workflow. Automatically invoked when discussing new features, specifications, technical planning, or implementation tasks. Ensures proper workflow phases (specify → clarify → plan → checklist → tasks → analyze → implement).
product-manager-toolkit
davila7
Comprehensive toolkit for product managers including RICE prioritization, customer interview analysis, PRD templates, discovery frameworks, and go-to-market strategies. Use for feature prioritization, user research synthesis, requirement documentation, and product strategy development.
notion-spec-to-implementation
openai
Turn Notion specs into implementation plans, tasks, and progress tracking; use when implementing PRDs/feature specs and creating Notion plans + tasks from them.