--- name: action-items-capture-format source: https://app.decimal.ai/s/action-items-capture-format@1/SKILL.md source_sha256: b588d3db3915 --- # Action Items — capture into a fixed owner / task / due / status table ## What this does Given raw notes from a meeting or call — the messy running text someone typed while people talked — this pulls out the **things somebody committed to do** and lays them in one fixed table: | owner | task | due | status | |-------|------|-----|--------| Handed those notes and asked to "get the action items out", base models fail two ways. They **over-capture** — every topic discussed becomes a to-do, so background, opinions, and decisions-with-no-task all end up as rows. And they **invent the missing parts** — when the notes never say who owns a task or when it is due, the model fills in a plausible name or a smooth "by next week" that nobody actually said. Both are worse than an honest gap: a made-up owner sends the task to the wrong person, and a made-up date creates a deadline no one agreed to. The K here is the discipline, not the four columns: only real commitments become rows, and a missing owner or missing due date is written **UNASSIGNED** — never guessed. ## When to use / when NOT - **Use** when someone hands over **raw meeting or call notes** and wants the **action items / follow-ups / who-owns-what** pulled out so nothing falls through. - **Do NOT use** for a **pre-meeting brief or agenda** (that is meeting-brief-format), an **outbound recap email to a prospect after a sales call** (sales-follow-up-recap), or **quiz-style study notes** from a lecture (cornell-note-format). This governs the post-meeting action list only. ## The table contract Every action item is one row with exactly these four columns, in this order: 1. **owner** — the person the notes name as responsible. If the notes name no one, write **UNASSIGNED**. Do not pick the most likely person, the meeting organizer, or the reader. 2. **task** — the committed action, as a short imperative ("send the revised budget", "review the API spec"). One action per row; if someone took on two things, that is two rows. 3. **due** — the deadline the notes actually state ("Friday", "by the 15th", "end of sprint"). If no date is stated, write **UNASSIGNED**. Do not infer a date from context or invent one. 4. **status** — where the item stands *as the notes describe it*: `open` by default, or `in progress` / `blocked` / `done` only if the notes say so. If nothing is said, it is `open`. ## The rules 1. **Rows are commitments, nothing else.** A row means *someone will do something*. Topics discussed, information shared, opinions, and decisions that carry no follow-up task are **not rows** — leave them out entirely. If you cannot name the task as "someone will do X", it does not belong in the table. 2. **Never invent an owner.** No name in the notes → `UNASSIGNED`. A confidently wrong owner is worse than an admitted gap: it routes the work to someone who never agreed to it. 3. **Never invent a due date.** No date in the notes → `UNASSIGNED`. Do not translate "soon", "eventually", or "when we get to it" into a specific date the group never set. 4. **Split, don't merge.** "Dana will draft the doc and set up the review" is two commitments, so two rows — each can have its own owner, date, and status. 5. **Keep the owner's own words for who.** If the notes say "the design team" rather than a person, the owner is "design team" — that is a stated owner, not UNASSIGNED. UNASSIGNED is only for items where the notes name no one at all. ## Worked example Raw notes (what you were handed): ``` Kicked off with the launch date — everyone agrees end of month is tight but doable. Priya said she'll finalize the pricing page copy by Thursday. We talked about whether to gate the free tier; no decision, revisit next week. Someone needs to update the changelog before we ship. Marcus is going to reach out to the two beta customers — didn't say when. Long tangent about the old billing bug, nothing to do there. Design review is already done. ``` **BEFORE (base default — over-captures and invents):** > - Priya: finalize pricing page copy — due Thursday > - Team: decide on gating the free tier — due next week > - Marcus: update the changelog before ship — due this week > - Marcus: reach out to beta customers — due Friday > - Priya: confirm launch date — due end of month *(It turned a no-decision discussion into a task, guessed Marcus owns the changelog and invented "Friday" for the beta outreach, invented a "this week"/"Friday" deadline, and added a "confirm launch date" task nobody committed to.)* **AFTER (this format):** | owner | task | due | status | |-------|------|-----|--------| | Priya | Finalize the pricing page copy | Thursday | open | | UNASSIGNED | Update the changelog before ship | UNASSIGNED | open | | Marcus | Reach out to the two beta customers | UNASSIGNED | open | *(The gating question was a discussion with no task — dropped. The billing tangent — dropped. The design review was already done and needs nothing — dropped. The changelog has no owner and no date, so both are UNASSIGNED. Marcus's outreach has an owner but no stated date, so due is UNASSIGNED.)* ## Edge cases - **Nothing was committed.** If the notes are all discussion and no one took anything on, say so plainly ("No action items — this was a discussion, nothing was assigned") rather than inventing tasks to fill the table. - **A decision, not a task.** "We decided to go with option B" is a decision. It only becomes a row if someone also committed to *do* something about it ("Sam will write up option B"). - **A group owner.** "Ops will handle rollout" → owner is "Ops". That is a stated owner; do not downgrade it to UNASSIGNED, and do not pick a single person out of the group. - **A vague time that is not a date.** "soon", "before launch", "next sprint" with no anchor → due is UNASSIGNED. Only write a due when the notes give a real point in time. - **Someone volunteered but the task is fuzzy.** Keep the owner, phrase the task as best the notes support, and if the deliverable is unclear leave a short note in the task cell rather than inventing specifics. - **No table support (plain text).** Keep the four fields per line in the same order — `owner — task — due — status` — with UNASSIGNED where a field is missing. The contract survives without literal columns. ## Do / Don't - **Always** produce one table with the columns owner, task, due, status, in that order. - **Always** write UNASSIGNED for a missing owner and UNASSIGNED for a missing due date. - **Always** make each row a single concrete commitment phrased as an action. - **Always** drop discussion, background, and decisions that carry no task. - **Never** guess an owner, the organizer, or the reader when the notes name no one. - **Never** invent or infer a deadline the notes did not state. - **Never** turn a topic that was merely discussed into an action item. ## Common mistakes (the base's wrong defaults) 1. Every discussed topic becomes a to-do, so the table is padded with non-commitments. 2. A plausible owner is guessed for an ownerless task instead of UNASSIGNED. 3. A specific due date is invented ("by Friday") when the notes gave none. 4. "soon" / "next sprint" is silently converted into a concrete date. 5. Two commitments in one sentence are merged into a single row with a muddled owner. 6. A decision with no follow-up ("we agreed on option B") is logged as an action item.