AI Prompts for Meeting Notes, Docs and Data: Mark It, Don't Fill It

The transcript never says who owns the follow-up. The summary often does. These AI prompts for meeting notes, docs and data put a visible marker where the source goes quiet, so you can see what was decided and what was quietly filled in.

Why an Owner Gets Invented

Abstractive summarization does not copy, it rewrites - and rewriting pushes a model toward the shape it has seen a thousand times. Research on faithfulness and factuality in abstractive summarization (Maynez and colleagues, ACL 2020) documents exactly that: fluent, human-sounding summaries that contain content the source never supported, and it separates faithfulness (what is derived from the article) from factualness (what is true about the world). An invented owner is not a rare bug. It is the expected behavior of rewriting.

Watch where the invented detail lands. In a real meeting the shortage is rarely the fact; the fact was said out loud. The shortage is the name. Someone says "somebody should check that with the vendor", and the model returns "Priya to check with the vendor by Friday". The owner and the date are plausible, professionally formatted, and nowhere in the recording. The file gets forwarded, and whoever receives it treats all four columns as equally sourced.

The Three AI Prompts for Meeting Notes, Docs and Data - and the Rule They Share

All three come from the catalog, and none of them asks for "a summary". Each one names its inputs, fixes the output shape, and writes one rule that pushes the missing information into the open instead of covering it.

Minutes Where the Owner Comes From the Transcript - or Says [UNASSIGNED]

Claude Meeting Notes & Action Items takes a meeting type, a rough duration and the raw transcript. It returns a three-bullet summary, decisions with who decided them, action items in a table with task, owner, due date and blocker, open questions, risks (including deadlines or resources mentioned only in passing) and a suggested agenda for the next meeting. The written rules are the part that matters: extract owners from the transcript, never invent names, and print [UNASSIGNED] when the source does not say. It also has to keep what was mentioned apart from what was decided, and stay readable in under two minutes.

Docs Where an Inference Says [INFERRED - VERIFY]

Claude Technical Docs Writer takes code snippets, a rough spec or an existing README, plus the project name and the stack. It produces a quickstart with a hello world that runs, core concepts in five bullets, an API reference with signatures, parameter tables, return types and one example each, three copy-ready common tasks and five troubleshooting entries with cause and fix. Its rule is the same idea in a different material: complete examples with imports, and anything the model inferred rather than read gets flagged as [INFERRED - VERIFY]. A section cannot claim behavior that no file shows.

A Dataset Where Every Change Is Counted

Claude Data Cleaning Partner takes the rows, the columns and what looks wrong. It returns an issue inventory with example rows, numbered cleaning rules (dedupe key, date format, case normalization, outliers), a complete pandas script that exports both the cleaned file and a data quality report, a data dictionary for the output columns, and the edge cases: nulls, empty strings, mixed types. Two rules are written into it - never silently drop data, and the report must count every change - because a threshold like "drop spend above the 0.99 quantile" is not a rule, it is a guess.

Why "Mentioned" Is Not "Decided"

A decision needs a sentence in which someone agrees. If nobody said that sentence, what you have is a topic that came up, and dressing it as a decision makes the log disagree with the meeting it claims to record. The same test works on the other two deliverables. A documentation section cannot assert behavior that no file shows. A cleaning rule cannot remove rows without accounting for them.

The expensive failure is not missing information. It is that the reader cannot tell what came from the source apart from what was completed, and then acts on both the same way. The fix is not more text. It is two columns of different natures: the fact, and its origin.

The Marker, Not the Fix

The obvious repair, "review everything", does not survive the first busy week. What scales is a visible convention. [UNASSIGNED] where the transcript names no owner. [INFERRED - VERIFY] where the model deduced instead of reading. A change report that counts every row it touched in the dataset. Four rules keep it honest: the marker goes in the output, not in a footnote; it is greppable (brackets, capitals, fixed text) so you can search before forwarding; it names what is missing without adjectives; and it is never solved by guessing, only by asking the source, whether that source is the person in the room, the code, or the system that owns the data.

Notice how far that is from asking the model to "make it better". A marker that says the owner is unknown is more useful than a name that happens to be wrong, because the first is resolved by a two-line message and the second is discovered a month later during a follow-up. The request that works is "mark what you cannot prove".

Provenance Is the Point

The common thread has a name outside of AI. The W3C PROV family calls provenance the information about the entities, activities and people involved in producing a piece of data, which is what lets someone judge its quality and trustworthiness. In practice it means each line of the record either points to its origin or carries a marker saying it has none. For minutes, that origin is the sentence in the transcript, or the timestamp block in the recording. For docs, it is the file or the endpoint that shows the behavior. For a dataset, it is the numbered rule that touched the row plus the row count before and after.

When that link is missing the record is not "a bit unreliable". It is not auditable, and the cost lands on whoever receives the file. It is the same argument data teams make when they insist on a documented transformation log instead of a silently cleaned file nobody can reproduce.

What Only You Can Supply

Three things stay outside the model. Paste the real source: the full transcript, not your memory of the meeting; the code, not the intention; the raw file, not a version that is almost clean. Decide who is the legitimate owner of a task nobody wanted, because assignment is a management call and not a text call. And accept that the correct answer can be "it is not written down" - which is where the R-Tuning line of work is relevant: language models are known to generate non-existent facts, and part of that research goes into teaching them to refrain from answering instead of inventing. Refusing is a behavior you write into a prompt, not a virtue you wait for.

Then check the two things that never depend on the model. In the meeting, an invented owner costs more than an honest [UNASSIGNED], because the invented one is discovered late, in the follow-up. In the dataset, the change report is what gets archived with the output; without it the cleaning cannot be reproduced and the next person starts again from the original mess.

Mark It, Don't Fill It

A model can hand you minutes, developer documentation and a clean dataset in one pass, in a tone that reads finished. What decides whether those files are worth anything is whether the reader can see where the source stopped talking. The three prompts above - meeting minutes with real owners, technical docs that flag inferences and a dataset with a counted change report - write that marker into the deliverable instead of a disclaimer at the end. If you want the same habit inside a reusable system prompt, the companion post on constraining output covers the format side.