decision-log-builder
Paste into Claude Code, Claude.ai, the desktop app, or the browser extension — ⌘/Ctrl+V. ✓ Copied. Switch to Claude and paste — ⌘/Ctrl+V.
Decision Log Builder
Extract decisions from meeting records and format them as permanent, audit-ready decision log entries. Supports DACI (Atlassian-standard) and RACI variants. Output is designed to slot directly into a Confluence project decision register or a standalone project markdown file.
When this skill applies
- User has a normalized meeting record (from
meeting-transcript-parse) and wants to produce decision log entries - User pastes a block of notes and asks to "pull out the decisions" or "add to the decision log"
- After any steering committee, architecture review, or change-control meeting
- When a project's Confluence space has a running decision register that needs updating
Skip when: no decisions were made (use action-item-tracker); the user wants to push immediately to Confluence (chain to jira-confluence-push after this skill).
Workflow
Step 1 — Identify decision candidates
Read the provided record or notes. Flag every item tagged [DECISION] (from meeting-transcript-parse) or any sentence that:
- States a conclusion in past or present tense ("We will go with...", "The team agreed...", "It was decided...")
- Resolves an open question from a prior meeting
- Accepts or rejects a proposed option
- Approves a change, budget item, or scope modification
Distinguish decisions from intentions. "We should consider X" is not a decision. "We will proceed with X from sprint 4" is.
Step 2 — Enrich each decision
For every decision candidate, collect or infer:
| Field | Source | If absent |
|---|---|---|
| Decision title | Extract 5–8 word summary | Synthesize from decision text |
| Decision date | Meeting date | Flag as [DATE UNKNOWN] |
| Decision ID | Sequential within this log | Auto-assign: DEC-<NNN> |
| Decision statement | Verbatim or lightly paraphrased | Must quote source material |
| Rationale | Why this option, not another | Extract from discussion context; flag [RATIONALE NOT CAPTURED] if absent |
| Options considered | What alternatives were discussed | Extract if present; [NOT DOCUMENTED] if absent |
| Driver | Who drove the decision to closure | Role, not name (for client outputs) |
| Approver | Who had authority to approve | Role or "Group consensus" |
| Contributors | Who provided input | Roles listed |
| Informed | Who needs to know but had no vote | Roles listed; flag if list seems incomplete |
| Impact | Scope / cost / timeline / quality / risk | Assess from discussion context |
| Status | Accepted / Pending ratification / Superseded |
Default Accepted |
| Related actions | Action IDs from the action register | Cross-reference if action table is available |
| Related decisions | Prior decision IDs this supersedes or depends on | Cross-reference existing log if provided |
Step 3 — Format the decision log entries
Produce one entry per decision using the template in reference.md. Group entries by meeting date if appending to an existing log.
If --append @existing-log-path is provided:
- Read the existing log to determine the next
DEC-NNNsequence number - Check for conflicts: does any new decision supersede an existing one? If yes, add a
Superseded bynote to the old entry and aSupersedesreference in the new entry - Output the new entries as a markdown block the user can paste at the end of the existing log
Step 4 — Flag governance gaps
After producing entries, surface any gaps that reduce the log's audit value:
- Missing rationale — decisions without documented rationale are governance liabilities; flag each one
- Missing approver — who had authority? If "group consensus" was used where formal approval was needed, flag it
- Incomplete Informed list — decisions that affect teams not in the meeting need an explicit Informed list; prompt the user to complete it
- No options considered — binary "yes/no" decisions are fine; complex choices with no alternatives documented are a risk
Present gaps as a bulleted action list with suggested owners.
Step 5 — Self-check
- Every decision has a unique
DEC-NNNID - Every decision has a date and a status
- Rationale gaps are explicitly surfaced, not silently omitted
- No personal names appear in fields that will be published to a shared Confluence space (unless user confirms internal-only)
- Related action IDs are cross-referenced if an action table was provided
Return the formatted entries as a markdown block. Remind the user to chain to jira-confluence-push if they want to push directly to Confluence.
Reference files
reference.md— DACI model explanation, entry template, impact classification guide, status vocabulary
Technical details
- Plugin
- meeting-to-action
- Author
- Dakota Smith
- Skill name
decision-log-builder- Maturity
- experimental
- Security review
- No security review
- Owners
-
- delivery
- Argument hint
[paste normalized record or @file-path] [--format daci|raci] [--project <project-name>] [--append @existing-log-path]- Allowed tools
-
ReadWriteGlob
- Source
plugins/meeting-to-action/skills/decision-log-builder/SKILL.md
Edit this skill on GitHub — opens GitHub's web editor. No git knowledge needed.