Why this is hard to get right
The Problem with Scattered Decision Logs
Marcus is a Chief of Staff at a 200-person SaaS company. Every Monday, he's responsible for sending a leadership update covering the prior week's decisions. The problem: those decisions live everywhere. Some are buried in a Confluence doc from Thursday's product sync. Others exist only as Slack threads. A few were made verbally in the all-hands and never written down at all.
Marcus used to spend two hours each Monday morning hunting through notes, reformatting bullet points, and chasing down owners. His first attempt using a generic AI prompt looked like this: "Summarize our leadership decisions from last week and tell everyone what to do next." The output was padded, vague, and mixed confirmed decisions with ideas someone floated in a brainstorm. Three team members followed up to ask what was actually decided. That made things worse, not better.
The real difficulty isn't summarizing — it's filtering. Marcus needed the AI to distinguish between a confirmed call and an open question. He needed it to assign owners by name and role, not just say "the team." He needed a consistent structure so the exec team could scan 10 bullet points in 90 seconds, not read 400 words of narrative.
When Marcus tightened his prompt, everything shifted. He specified that the AI should act as a Chief of Staff, not a generic assistant. He defined exactly what fields each decision entry needed: the decision itself, the rationale, the owner, the due date, dependencies, risks, and next step. He told the AI to flag anything not yet confirmed as a separate section of open questions. He set a hard cap of 10 items and asked for a table followed by a 120-word narrative.
The output changed immediately. The table was scannable. Owners were named. Open questions were separated cleanly from confirmed decisions. The Monday update went out in 35 minutes instead of two hours, and the exec team stopped asking follow-up questions about what was actually decided.
That shift — from a vague request to a structured, role-aware, field-specific prompt — is what separates a summary people act on from one people ignore. The prompt does the heavy lifting that Marcus used to do manually. It enforces a format, sets the audience, and defines the rules for what counts as a decision before the AI writes a single word.
Common mistakes to avoid
Mixing Decisions with Ideas and Options
When you don't tell the AI what qualifies as a 'decision,' it pulls in brainstorms, proposals, and half-formed ideas. This creates a bloated log that confuses readers. Explicitly state: only include items where a call was made and a path was chosen. Everything else belongs in a separate 'open questions' section.
Omitting Owner Format and Role Level
Asking for 'who owns this' without specifying format gets you inconsistent results — sometimes a name, sometimes a team, sometimes nothing. Specify the format: 'Owner: First Name, Role.' This forces the AI to flag gaps where ownership is actually unclear, which is often the most important signal in a decision log.
Not Setting a Length Cap
Without a limit, the AI defaults to exhaustive summaries. A 30-item decision log is not a summary — it's a transcript. Set a hard cap (10 items max works for most exec teams) and tell the AI to prioritize by impact or urgency. This forces triage, which is the actual job.
Skipping the Audience and Tone Specification
A summary for a VP of Engineering reads differently than one for the board. Without audience context, the AI writes at a generic level. Name the audience (exec team, functional leads, board) and specify tone (direct, neutral, no hype). This single addition changes reading level, word choice, and what gets emphasized.
Forgetting to Include Risk and Dependency Fields
Most users ask for decision and owner but skip risks and dependencies. This creates a clean-looking log that fails in execution — someone starts work without knowing a blocker exists. Require both fields in every decision entry so downstream teams can plan around constraints before they hit them.
Pasting Raw Notes Without Any Context Frame
Dumping unstructured notes and expecting perfect output rarely works. The AI doesn't know which meeting these came from, what time period they cover, or which format matters. Add a one-line frame before the pasted notes: meeting name, date, and the audience who will read the output. This context dramatically improves extraction accuracy.
The transformation
Summarize our leadership decisions from last week and tell everyone what to do next.
You’re a **Chief of Staff** creating a **weekly decision log summary**. **Input:** I’ll paste meeting notes and a running decision log. 1) Extract **only confirmed decisions** (ignore ideas). 2) For each decision, write: **Decision**, **Why now**, **Owner (name/role)**, **Due date**, **Dependencies**, **Risks**, **Next step**. 3) Add a section: **Decisions needing confirmation** with 3-5 bullet questions. **Audience:** exec team + functional leads. **Tone:** direct, neutral, no hype. **Format:** 10-item max, table first, then 120-word narrative recap.
Why this works
Role Assignment Anchors Tone
The prompt opens with 'You're a Chief of Staff creating a weekly decision log summary.' This isn't cosmetic. Naming a specific role tells the AI to write with executive-level judgment — filtering noise, using direct language, and prioritizing clarity over completeness. Without a role, the AI defaults to a generic assistant voice that doesn't match leadership contexts.
Field-Level Structure Prevents Gaps
The prompt requires seven named fields per decision: Decision, Why now, Owner, Due date, Dependencies, Risks, Next step. This functions like a schema. When source notes are missing an owner or a due date, the AI flags the gap rather than skipping it. That's more valuable than a polished summary built on incomplete information.
Separation of Confirmed vs. Open Items
Step 3 of the prompt explicitly adds a 'Decisions needing confirmation' section with 3-5 bullet questions. This prevents the most common decision log failure: treating proposals as decisions. By building the distinction into the prompt structure, the AI does the filtering work automatically instead of leaving it to the reader.
Hard Format Constraints Enable Scanning
The prompt specifies '10-item max, table first, then 120-word narrative recap.' This dual-format output serves two audiences: leaders who need to scan quickly get the table, while people who need context get the narrative. The hard cap forces prioritization, which is what distinguishes a useful summary from a document dump.
Tone Specification Removes Ambiguity
The prompt states 'Audience: exec team + functional leads. Tone: direct, neutral, no hype.' These three words — direct, neutral, no hype — eliminate an entire category of AI failure. Without them, the AI often writes in a motivational or padded style that erodes credibility with senior stakeholders who read dozens of updates per week.
The framework behind the prompt
The Theory Behind Decision Documentation
Organizational decision-making research consistently identifies documentation lag as a primary driver of execution failure. When decisions aren't captured in a structured format within 24-48 hours, recall accuracy drops significantly — teams reconstruct what was decided rather than remember it. This reconstruction introduces drift: different stakeholders walk away with different versions of the same decision.
The DACI framework (Driver, Approver, Contributor, Informed) was developed specifically to address decision ownership ambiguity in fast-moving organizations. It forces teams to name exactly one accountable person per decision — not a team, not a committee. The After Prompt on this page applies the same principle by requiring an Owner field with name and role, not just a department label.
Structured decision logging also relates directly to After Action Review (AAR) methodology, originally developed by the U.S. Army and adapted widely in business settings. AAR separates what was decided from why it was decided, and what happened next — the same separation embedded in the prompt's seven-field structure (Decision, Why now, Owner, Due date, Dependencies, Risks, Next step).
From a cognitive load perspective, the dual-format output (table plus narrative) maps to how different types of readers process information. Research on executive communication confirms that scanning and reading are different cognitive tasks. A table supports scanning; a narrative supports comprehension. Requiring both in the prompt ensures the output serves both cognitive modes without asking the reader to switch documents.
Finally, the prompt's explicit instruction to separate confirmed decisions from open questions reflects decision hygiene principles used in governance frameworks like RACI and OKR reviews. Conflating proposals with decisions is not just a formatting problem — it creates false accountability and erodes trust in the decision log itself over time. The structured prompt enforces this separation automatically, every time.
Prompt variations
You are a Chief of Staff preparing a quarterly decision summary for a board of directors.
Input: I'll paste decision logs and meeting notes from the past 13 weeks.
Your task:
- Extract only decisions with company-level impact (hiring freezes, pricing changes, market exits, major investments).
- For each decision: Decision made, Strategic rationale, Accountable executive, Expected outcome by quarter-end, Key risk, Status (implemented / in progress / delayed).
- Flag any decisions from Q3 that remain unresolved entering Q4.
Format: Maximum 8 decisions in a two-column table. Follow with a 150-word executive narrative. Use plain language — no acronyms without definition.
Tone: Formal, factual, no editorializing. Write as if a board member is reading this for the first time.
You are a Staff Engineer documenting a weekly technical decision log for cross-functional engineering leads.
Input: I'll paste notes from architecture reviews, incident retrospectives, and sprint planning.
Your task:
- Extract only architectural, tooling, or process decisions — not task assignments.
- For each decision: Decision, Context (why this came up), Alternatives considered, Owner (name + squad), Affected systems, Rollback plan if any, Review date.
- Separate a section: Deferred decisions — items discussed but not resolved, with a one-line reason for deferral.
Format: Table with 8 columns, max 12 rows. Follow with a 100-word summary of the highest-risk decision only.
Tone: Precise, technical but readable by non-engineers. Avoid passive voice.
You are a Customer Success Operations Lead summarizing weekly policy and process decisions for frontline CS managers.
Input: I'll paste notes from CS leadership syncs, escalation reviews, and cross-functional meetings.
Your task:
- Extract decisions that change how the CS team handles accounts, escalations, or renewals.
- For each decision: Policy change, Effective date, Accounts or segments affected, Owner (CS Lead name), Manager action required, Customer communication needed? (Yes/No).
- Add a section: Expiring policies — any temporary decisions made in the last 30 days that need review.
Format: Plain numbered list, max 10 items. End with a 3-sentence 'what managers need to do this week' paragraph.
Tone: Clear, direct, friendly. Managers read this on Monday morning — make it easy to act on immediately.
You are a founder's executive assistant capturing daily decisions from a fast-moving startup.
Input: I'll paste quick notes, voice memo transcripts, or Slack messages from the past 24 hours.
Your task:
- Extract any item where a clear choice was made — even if informally.
- For each decision: What was decided (one sentence), Who decided it, Who needs to act, By when.
- Flag any item that sounds like a decision but lacks an owner or deadline — mark these as 'incomplete.'
Format: Bullet list only, max 8 items. No table. Keep each entry under 30 words.
Tone: Informal, fast, scannable. This is a daily capture, not a formal report. Prioritize speed over polish.
When to use this prompt
Founders running fast weekly exec meetings
Turn scattered notes into a weekly decisions summary with owners and dates, so nothing slips between meetings.
Product managers aligning roadmap trade-offs
Capture confirmed product calls, the rationale, and dependencies to keep engineering and go-to-market in sync.
Customer success leaders tracking policy changes
Summarize service decisions, escalation rules, and risks into a format your managers can roll out the same week.
Engineering leaders managing cross-team dependencies
Extract decision owners and blockers from technical reviews and publish a single list of next steps for leads.
Pro tips
- 1
Define what qualifies as a decision so you don’t mix in brainstorms or options.
- 2
Specify your cadence and length limits so the summary fits your weekly rhythm.
- 3
Name the roles that must take action so the AI assigns owners in your preferred format.
- 4
Add your risk threshold so the AI flags only issues you’d raise in an exec forum.
Most decision logs fail not because the format is wrong but because the source material is incomplete. Meeting notes capture 60-70% of what was actually decided. The rest lives in Slack threads, email replies, and verbal side conversations.
To handle multi-source extraction, structure your prompt input in layers:
- Label each source block before pasting: 'Source: Product sync, Tuesday 10am' or 'Source: Slack thread, #eng-leads, Wednesday.'
- Tell the AI to reconcile conflicts when the same decision appears differently across sources: 'If the same topic appears in multiple sources, use the most recent version and note the date it was updated.'
- Add a confidence flag to your field list: 'Confidence: High (confirmed in meeting) / Medium (mentioned in Slack) / Low (verbal only, unconfirmed).'
This three-layer approach turns scattered source material into a single, traceable log. It also surfaces the decisions that exist only in someone's memory — which is often where execution breaks down. Teams that use confidence flags catch 30-40% more 'assumed decisions' before they become missed deadlines.
The base prompt is built for weekly cadences, but decision log frequency varies widely by team and company stage. Here's how to adapt the core structure:
Daily standups (startup / high-velocity teams): Reduce the field count to four: Decision, Owner, Deadline, Blocker. Cap at 5 items. Ask for output in 60 seconds of reading time. Anything longer won't get read before the next standup.
Bi-weekly sprint reviews (product / engineering): Add an 'Affects sprint goal? Yes/No' field. This single binary flag tells the team whether a decision changes their current priorities or can wait until planning.
Monthly leadership reviews: Expand the narrative section to 250 words and add a 'Revisit date' field. Monthly decisions often have longer time horizons, and the AI needs permission to write more context, not less.
Quarterly board updates: Drop granular fields like 'Next step' and replace them with 'Expected outcome by quarter-end.' Board members don't need task-level detail — they need strategic trajectory.
The key principle: match the field count and length cap to how quickly your audience needs to process the information. A Monday morning field manager and a quarterly board member are solving different reading problems.
Run through this checklist before you paste your notes and submit your prompt. It takes 90 seconds and prevents the most common output failures.
Input quality:
- Have you labeled each source block with a meeting name and date?
- Have you removed any content that's clearly off-topic (small talk, scheduling discussions)?
- Have you noted the time period covered (e.g., 'Week of June 9-13')?
Prompt specificity:
- Did you define what counts as a confirmed decision vs. an open question?
- Did you name the audience who will read the output?
- Did you specify a maximum item count?
- Did you list every field you want in the table, in the order you want them?
Format requirements:
- Did you specify table format (markdown, plain text, or another format your tool supports)?
- Did you set a word limit for the narrative section?
- Did you tell the AI what to do with incomplete entries (flag them, skip them, or mark them as 'TBD')?
After output:
- Check that every entry has a named owner, not just a team name.
- Verify that the 'open questions' section exists and is not empty.
- Confirm the narrative recap doesn't introduce new information not in the table.
If any of these checks fail, the fix is almost always a one-sentence addition to your prompt — not starting over.
When not to use this prompt
This prompt pattern works best when you have actual meeting notes or a decision log to paste in. It's not the right tool in a few specific situations:
-
When no decisions were actually made: If your meeting was a brainstorm or a status update with no confirmed calls, a decision log prompt will either hallucinate decisions or produce an embarrassingly short output. Use a meeting summary prompt instead.
-
When the audience is external (clients, regulators, auditors): This prompt is built for internal exec and functional lead communication. It uses a direct, neutral tone that may be too sparse for external stakeholders who need more narrative context, diplomatic framing, or legal precision.
-
When decisions require version control or audit trails: AI-generated summaries don't constitute a formal record. For compliance-sensitive decisions (HR, legal, financial), use proper governance tooling with tracked changes, not an AI-generated summary.
-
When you have fewer than 3 decisions to document: The overhead of the structured table format isn't worth it for very short logs. A plain bulleted list with owners and dates is faster and clearer.
If you're unsure which prompt type fits, start with your output goal: do readers need to act on this information (use this prompt) or simply understand it (use a meeting summary or briefing prompt instead)?
Troubleshooting
The AI includes ideas and proposals alongside confirmed decisions
Add an explicit definition at the top of your prompt: 'A confirmed decision is any item where a specific option was chosen, a responsible person was named, and the team moved forward.' Then add: 'Move all other items — proposals, options under consideration, and deferred discussions — to a separate section called Open Questions.' This two-part instruction eliminates conflation at the source.
Owners are listed as team names instead of individual names
Change your owner field instruction from 'Owner' to 'Owner (First Name + Role, e.g., Sarah — VP Product).' Add: 'If no individual was named as accountable, mark the owner as UNASSIGNED and bold it.' The UNASSIGNED flag creates visible accountability gaps, which is often more valuable than a clean-looking log with vague team names.
The output narrative repeats the table instead of adding context
Replace 'narrative recap' with a more specific instruction: 'Write a 120-word paragraph that covers only: (1) the single highest-risk decision and why it matters, and (2) what the exec team needs to watch in the next 7 days.' This gives the narrative a distinct job from the table, eliminating redundancy and making both sections earn their place in the document.
The AI hallucinates owners or due dates not present in the notes
Add this line to your prompt: 'If a field cannot be confirmed from the source material, write TBD — do not infer or guess.' Hallucinated owners are the most damaging failure mode in a decision log because they assign accountability to people who never agreed to it. The TBD instruction forces the AI to surface missing information rather than fill it with plausible-sounding fiction.
The summary is too long and executives won't read it
Set a strict word budget per decision entry: 'Each decision entry must be 25 words or fewer across all fields combined.' Also add: 'If you exceed 10 decisions, prioritize by urgency and impact — drop the lowest-priority items, do not include them.' Brevity requires explicit permission in the prompt; the AI defaults to thoroughness without it.
How to measure success
How to Evaluate Your AI Output
A strong decision log output passes these checks before you send it to your team:
Structural completeness:
- Every entry has all seven fields populated — any TBD values are explicitly marked, not omitted
- The table appears before the narrative, not after
- The narrative adds context not visible in the table (not a restatement)
Decision quality:
- No brainstorms or proposals appear in the confirmed decisions table — only items where a clear choice was made
- The 'Decisions needing confirmation' section contains at least one item (if it's empty, the AI likely merged proposals into the main table)
- Every owner is a named individual, not a team or department
Readability benchmark:
- An executive should scan the full table in under 90 seconds — if it takes longer, the log is too long or too dense
- The narrative reads in under 45 seconds
- No sentence in the narrative exceeds 20 words
Accuracy check:
- Cross-reference 3 random entries against your source notes to confirm the AI didn't infer or hallucinate details
- Verify due dates and owners against the actual meeting — these are the two fields most likely to drift
Now try it on something of your own
Reading about the framework is one thing. Watching it sharpen your own prompt is another — takes 90 seconds, no signup.
Turn your scattered meeting notes into a structured decision log your exec team can act on immediately.
Try one of these
Frequently asked questions
Add an explicit definition to your prompt. For example: 'A decision is any item where a specific option was chosen and a responsible party was identified.' Tell the AI to move anything else to an 'open questions' section. This single addition eliminates the most common source of garbage in AI-generated decision logs — items that were discussed but never actually resolved.
Add a framing line before you paste the notes: meeting name, date, and attendees. This gives the AI enough context to distinguish who said what and when. Messy notes are fine — the AI handles noise well when it knows what it's looking for. What it can't recover from is zero context about the source material.
Yes — and you should. The seven fields in the base prompt (Decision, Why now, Owner, Due date, Dependencies, Risks, Next step) work for most teams. But if your team doesn't track due dates weekly, drop that field. If you need a 'Budget impact' column, add it. The AI follows the field list exactly as you write it. Fewer fields means faster reads; more fields means more coverage. Match the fields to what your team actually acts on.
Add a 'Status' field to your prompt: options like 'new,' 'in progress,' or 'carried over.' Then paste notes from both weeks and tell the AI to consolidate decisions that appear in multiple meetings into a single entry. This prevents the same decision from appearing twice with different owners, which is a common problem in rolling decision logs.
Replace summarize language with extraction language. Instead of 'summarize decisions,' write 'extract each confirmed decision as a separate table row.' The word 'summarize' signals a narrative output. 'Extract' signals structured data. This one word change produces dramatically different — and more useful — output formats.
This prompt structure works well across major models. Claude tends to follow field-level formatting instructions most precisely. ChatGPT GPT-4 handles longer unstructured notes well. If you're getting inconsistent table formatting, add 'Use a markdown table with pipe characters' to your format section. That explicit instruction resolves most rendering issues across tools.
Add a 'rolling 4-week archive rule' to your prompt: 'Exclude any decisions where the due date has passed and the status is complete.' This keeps the active log focused on items that still require action. For completed decisions, maintain a separate archive document and paste only the active ones into your weekly prompt.
Yes. Add a 'Function' column to your table spec (e.g., Product, Engineering, Go-to-Market, Finance). Then instruct the AI to group entries by function before presenting the table. This lets cross-functional readers scan only the rows relevant to them without reading the full log. It's especially useful for all-hands updates where multiple departments are represented.