How to Turn Meeting Notes into an Internal RFC
Meeting notes are not a decision. Models write "the team agreed" anyway, assign work to people who were not in the room, and invent a vendor cost so the RFC looks finished. You then spend the comment period undoing a vote that never happened.
The matching generator is the Internal RFC from Meeting Notes prompt. Browse related cards in the PromptDig library (Browse more prompts). When a filled run survives, share the version you actually use (Share a prompt).
Source-map every claim before you pick a status
Bullet each claim in the notes with a quote fragment. Mark hearsay versus a named person. A p95 from Maya with a screenshot not attached is Maya's number, unverified in this RFC. Jules saying redis-2 CPU hit 70 percent that day is named. Sam saying "maybe SQS" and leaving at :25 is not a vendor selection.
Status is Draft, Proposed, Accepted, Rejected, or Superseded. Only Accepted if the notes record a decision and a namer. No vote means Draft. Do not upgrade the status because the RFC looks tidy.
Summary in five lines: problem, options counted, recommended option or "no recommendation yet," blast radius, what is explicitly unknown. That last line is the one models skip.
Leading option is not the same as Recommended
Write one primary design. Label it Recommended only if the notes lean that way. Otherwise label Leading option and say who leaned. Maya wanting retries off the web dyno is not Jules agreeing. 24h replay that Jules called "maybe" is not v1.
Alternatives: keep the current path, plus the other real options in the notes. If only one option exists, say so. Do not invent a strawman vendor so the RFC has a third column. SQS without a cost and without a security review is an idea, not a pick.
Rollout and rollback are only the steps the notes support. Missing runbooks go under Open questions, not under a fake feature-flag paragraph. If a freeze forbids prod schema after a date, the proposal cannot quietly include a migration.
Open questions need real owners, and NO_DATA stays visible
Number the questions. Each needs an owner from the people list or "unassigned." Do not assign work to someone who is not on the thread. Do not mint due dates. Use the deadline only if one was provided.
Risks map the constraints you were given. If a constraint was not discussed (DLQ, idempotency, partner duplicates), list it as unreviewed, not "fine."
NO_DATA is every metric, SLA, cost, and vendor quote a reader might expect and that Inputs lack. Pricing, screenshot binaries, error budgets, and partner lists belong here. Citing links you were not given does not.
Keep the RFC skimmable: headings, short paragraphs, numbered questions. Audience is the team, not a press release. Template flavor (IETF-ish, Google design doc, one-pager) changes headings, not the honesty rules.
Fill the card, then run
Paste the messy notes. Name who was on the thread. If a decision was not recorded, do not ask the model to find one.
Working title: [Title]
Meeting notes (paste): [Notes]
Author and reviewers: [People]
Current system in one paragraph: [Current]
Constraints (compliance, budget, freeze): [Constraints]
Deadline if any: [Deadline or none]
Links I may cite: [Links or none]
Template flavor: [IETF-ish / Google design doc / one-pager]
Audience: [Team]
An RFC that lists unassigned questions is more useful than a polished Accepted stamp with no namer. When a run keeps status at Draft and puts SQS under NO_DATA, share that filled card. That is the adapter other staff engineers actually want.
Cite only links that were in the paste. A screenshot Maya mentioned but did not attach stays off the RFC until it is attached. If the freeze date is the only hard clock, put it on the status line and on every rollout step, not buried in a footnote the comment thread will miss.