Meeting Minutes & Actions
Turn a meeting transcript, recording notes, or rough scratch into clean, distributable meeting minutes — attendees, agenda topics discussed, decisions made, and (most importantly) action items with owners and due dates. Scopes the minutes structure and what counts as a decision vs an action FIRST, then writes accurate, neutral minutes where every decision is recorded and every action has an owner and a date — the action table is the part people actually use. Use for board/team meeting minutes, project status meetings, and decision logs.
Steps
Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.
- Scope the minutesplannerentry
structure, what counts as a decision vs action, owner/date rule
Show working prompt
Decide the structure and the rules before writing. Step 1: capture the meeting metadata to record — title, date/time, attendees (present + absent), and the agenda/topics. Step 2: define the crucial distinction the minutes must enforce: a DECISION is a settled outcome (record what was decided and by whom), whereas an ACTION is a future task that MUST have an owner and a due date. Step 3: decide the section order: header/metadata, agenda, discussion-by-topic, decisions log, and an action-items table (Action | Owner | Due | Status). Step 4: set the neutrality rule — minutes record what happened factually, not opinion or editorializing. Step 5: write an acceptance-criteria checklist ('header with date + attendees', 'each agenda topic summarized neutrally', 'a decisions section listing every decision', 'an action table where EVERY action has an owner and a due date', 'no editorializing'). Write the structure + rules + checklist via write_task_note AND to notes/scope.md. No minutes prose yet. - Write the minutescopywriter
neutral minutes with a decisions log and an owner/date action table
Show working prompt
Write the minutes as minutes.md from the source material. Step 1: open with the header block — meeting title, date/time, attendees present and absent. Step 2: list the agenda, then write a neutral, concise summary per topic discussed (what was raised and the gist of the discussion) without editorializing or attributing motives. Step 3: write a Decisions section that records every decision reached, each as a clear statement of what was decided. Step 4: write the Action Items as a markdown TABLE with columns Action | Owner | Due Date | Status, and ensure EVERY action row has a named owner and a concrete due date — flag any item missing an owner/date as [OWNER?]/[DATE?] rather than leaving it blank. Step 5: note the next meeting / follow-up if mentioned. Pull only from the source; do not invent decisions or actions that were not discussed. On a loop-back, fix ONLY the named gaps. Write the path + counts of decisions and actions via write_task_note.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
QA the minutes against the locked criteria. Step 1: read minutes.md alongside the source. Step 2: check EACH acceptance criterion: header includes date + attendees, each agenda topic has a neutral summary, a decisions section captures every decision from the source, and an action-items TABLE exists where EVERY row has a named owner and a concrete due date (any [OWNER?]/[DATE?] placeholder or blank is a FAIL on that criterion). Step 3: confirm the tone is factual with no editorializing and that no decision or action was invented beyond the source. Write PASS/FAIL per criterion; on a missing owner/date, name the offending action row and loop back. Then route — this is the whole point of the loop: - **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`. - **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "write" })` to loop back. The builder fixes exactly those gaps. Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in. - Finishdeveloper
All acceptance criteria met. Stamp a short summary and report DONE.
Show working prompt
Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.
Triggers
Phrases that suggest this craftbook to a crew.
- meeting minutes
- write up meeting notes
- minutes from a meeting
- decisions and action items
- meeting recap doc
- action items list
Source
View this craftbook on GitHub · MIT license