LearnGrok
Prompts
PromptIntermediateBuilding on the API

Meeting decisions register

Paste-ready prompts for operations leads who need a decisions register from meeting notes, chat updates and project documents.

4 min read

A decisions register gives you one place to see what was agreed, who must act, and what proof is still missing. Use these prompts if you coordinate delivery across teams and need to chase work without reopening every meeting note and chat thread.

Key point

Record the proof, not just the promise

A decision is not ready to close because somebody says it is progressing. Record the evidence that confirms it.

1. Start with the right source set

Choose the prompt based on the state of the work:

If you have Use What you get
One fresh meeting record Create a register from one meeting A first register and a list of gaps
Several sources that overlap Merge decisions across sources One current view, duplicates and conflicts shown separately
A register plus this week's updates Update the weekly chase list Revised rows and a prioritised list of contacts
A register you do not trust Audit a register before escalation Supported corrections and precise escalation questions

Paste the source text in date order where you can. Label each item with its meeting date, chat date, or document version. A short chat update such as “approved” is not useful unless the prompt can see what was approved and by whom.

If the bundle is too large to review reliably in one pass, split it by workstream or reporting period. Behaviour with large source bundles is version-dependent, so check the current guidance in the xAI documentation overview before setting your process.

Watch out

Do not combine unlike decisions

“The team discussed a new launch date” and “The sponsor approved 15 October” are different records. The first may be an unresolved point. The second is a decision.

2. Keep the register fields consistent

Use the same meaning for each field each week. This stops the register becoming a list of vague status statements.

  • Decision or required decision: write the outcome, not the conversation topic. Use “Approve supplier onboarding route” rather than “Supplier onboarding”.
  • Owner: name the accountable person or team. A meeting chair is not automatically the owner.
  • Due date: record the decision deadline or delivery date, not the date somebody mentioned it.
  • Dependency: name the thing that must happen first, such as security review approval or a confirmed staffing allocation.
  • Evidence needed: specify what closes the item. Examples include an approved change request, published report, test sign-off, or written confirmation in the project channel.
  • Unresolved point: state the missing fact or conflict in one sentence. Do not hide it in the next action.

The prompts use Not stated and Unassigned deliberately. They make missing information visible to the person who can fix it. Replacing either with a likely answer makes the register look healthier than it is.

3. Review the register before you send chasers

Read every High priority row and every row marked Blocked. Check the source reference or quoted evidence before you contact someone. Then make sure the chase asks for one concrete outcome: confirmation of an owner, a date, an approval, or the named evidence.

Check

A useful chase can be answered

If your chase says “Any update?”, rewrite it. Ask for the missing decision, date, named owner, or evidence item instead.

Look for these common errors before distribution:

What you see Why it is wrong What to do
A row has an owner but no source assignment The owner may be an assumption Set the owner to Unassigned and ask for confirmation
A row is marked complete with no proof Progress has been mistaken for closure Change it to Pending and request the listed evidence
Two rows describe the same approval Chasers may go to different people Merge them and retain both source references
A deadline says “Friday” It cannot be checked later Convert it only if the source date makes it certain, otherwise ask
A chat message contradicts the meeting note The current position is unclear Put the conflict in Unresolved point and escalate it

4. Use the output in the delivery rhythm

After each decision-making meeting, create or update the register on the same day. Before the weekly delivery review, run the update prompt with new notes, chat updates and reports. Send the resulting chase list to the people named in it, rather than forwarding the entire register.

Keep the full register as the working record. Use the escalation brief only for issues that need a decision from a sponsor, programme lead, or accountable team. This separates ordinary follow-through from problems that require authority.

Note

Keep source references short but traceable

A meeting date plus speaker name, a chat date plus channel, or a document section is usually enough for someone to verify the row quickly.

5. When the output does not work

Do not repair a weak result by guessing. First check whether the source text contains the missing fact. If it does, paste the relevant excerpt again with its date and use the audit prompt. If it does not, leave the field unresolved and ask the named meeting owner or delivery lead.

If the register produces too many rows, ask whether it is recording actions rather than decisions. Actions belong in a delivery plan unless they prove, enable, or resolve a decision. If it produces too few rows, check for decisions stated in chat replies, document comments, and meeting follow-ups that were not included in the source bundle.

Copy-ready prompts

4 prompts. Open one to read it, or take the whole pack.

1Create a register from one meetingUse this immediately after a meeting when you have one set of notes or a transcript and need a clean handover to the delivery lead.
Create a decisions register from the meeting record below. Extract only decisions that were made, commitments that were accepted, and explicit requests for a decision. Do not turn discussion ideas into decisions.

Meeting name: [meeting name]
Meeting date: [YYYY-MM-DD]
Meeting record: [paste meeting notes or transcript]

Return two sections.

1. `Decisions register`, as a Markdown table with these columns in this order:
`ID | Decision or required decision | Status | Owner | Due date | Dependency | Evidence needed | Source reference | Unresolved point | Next chase action`

Use `Made`, `Pending`, `Blocked`, or `Superseded` in `Status`. Give each item an ID in the form `DEC-001`, `DEC-002`, and so on. Use dates only in `YYYY-MM-DD` format. If a date is relative, such as “next Friday”, convert it only if the meeting date makes it unambiguous. Otherwise write `Not stated` and explain the ambiguity in `Unresolved point`.

Use the speaker name or named team as `Owner` only where the source explicitly assigns responsibility. If nobody is assigned, write `Unassigned`. State dependencies as the named decision, deliverable, approval, or external event. For `Evidence needed`, specify the proof needed to close or confirm the item, such as an approved budget, test result, signed-off document, or written stakeholder confirmation. Quote a short phrase and identify the note section or speaker in `Source reference`.

2. `Questions to resolve before chasing`, as bullets. Include only missing owners, unclear dates, conflicting statements, or unclear decision wording.

Do not invent owners, deadlines, approvals, dependencies, or evidence.
2Merge decisions across sourcesUse this when a project decision is spread across meeting notes, chat threads and a project document, and you need one register without duplicate entries.
Build a consolidated decisions register from the source bundle below. Compare sources before writing the register. Treat a later dated, explicit decision as the current position unless a source says it replaces or reverses an earlier decision.

Project: [project name]
Register cut-off date: [YYYY-MM-DD]
Source bundle:
A. Meeting notes, dated [YYYY-MM-DD]: [paste]
B. Chat updates, dated [YYYY-MM-DD to YYYY-MM-DD]: [paste]
C. Project document, version/date [identifier]: [paste]

Return three sections.

1. `Current decisions register`, as a Markdown table with these columns in this order:
`ID | Decision | Status | Owner | Due date | Dependency | Evidence needed | Current source | Earlier or conflicting source | Unresolved point | Next chase action`

Use one row per distinct decision. Use `Made`, `Pending`, `Blocked`, or `Superseded` in `Status`. Give each row an ID in the form `DEC-001`. Preserve exact dates in `YYYY-MM-DD` format. If a source does not state a field, write `Not stated`, not a guess. If ownership is implied but not assigned, write `Unassigned`.

2. `Duplicates merged`, as a bullet list. For each merged item, name the register ID and the source references that described the same decision.

3. `Conflicts requiring a delivery lead decision`, as a Markdown table with:
`Register ID | Conflicting statements | Sources and dates | What must be confirmed | Recommended chase target`

Do not silently choose between genuinely conflicting owners, dates, scope statements, or approvals. Cite every decision with a source label and a short quote or section reference.
3Update the weekly chase listUse this before a delivery review. It compares the existing register with the latest updates and produces the work people need to chase this week.
Update the decisions register using the new project updates below. Keep existing IDs wherever the underlying decision is the same. Do not mark an item complete unless the update includes the evidence required by the register.

Today: [YYYY-MM-DD]
Existing decisions register: [paste current register]
New meeting notes: [paste or write None]
New chat updates: [paste or write None]
New project documents or status reports: [paste or write None]

Return four sections.

1. `Updated decisions register`, as a Markdown table with these columns in this order:
`ID | Decision | Status | Owner | Due date | Dependency | Evidence needed | Latest evidence | Unresolved point | Next chase action`

Use only `Made`, `Pending`, `Blocked`, `Complete`, or `Superseded` for `Status`. Retain a due date unless a source explicitly changes it. If an update conflicts with the existing register, preserve the old value in `Unresolved point` and state the source of the conflict.

2. `Chase list for this week`, as a Markdown table with:
`Priority | ID | Person or team to contact | What to ask | Why now | Evidence to request`

Set priority to `High` for overdue items, blocked dependencies, or decisions needed before another committed activity. Set `Medium` for items due within seven calendar days. Set `Low` for all other open items. If a due date is missing, do not assign High solely for that reason.

3. `Completed or superseded since last update`, as bullets. State the supporting evidence or replacement decision ID.

4. `New gaps`, as bullets. Include missing owners, missing dates, unclear evidence, and decisions that the updates refer to without recording.

Do not infer completion from vague phrases such as “in hand”, “looking good”, or “we discussed it”.
4Audit a register before escalationUse this when the delivery lead needs to know whether the register can be trusted before sending chasers or escalating blockers.
Audit the decisions register against the supplied source records. Find rows that are inaccurate, incomplete, duplicated, stale, or unsupported by evidence. Do not rewrite the register unless a correction is supported by a source.

Today: [YYYY-MM-DD]
Decisions register: [paste register]
Source records: [paste meeting notes, chat updates, and project documents]

Return three sections.

1. `Audit findings`, as a Markdown table with these columns:
`ID | Check result | Problem found | Source evidence | Required correction | Escalation needed`

Use one of these values in `Check result`: `Supported`, `Missing evidence`, `Conflicting`, `Incomplete`, `Duplicate`, `Stale`, or `Not found in sources`. Quote the relevant source wording or identify the document section. Mark `Escalation needed` as `Yes` only where a named person must resolve a conflict, assign ownership, approve a decision, or set a date.

2. `Corrected rows`, as a Markdown table using these columns:
`ID | Decision | Status | Owner | Due date | Dependency | Evidence needed | Unresolved point | Next chase action`

Include only rows where the sources support a specific correction. Keep `Not stated` where the source does not provide the missing value.

3. `Escalation brief`, as bullets. For each escalation, state the decision ID, the single question to ask, the person or team best placed to answer, and the source conflict or missing fact behind it.

Do not present an assumption as a correction. If the records disagree, report the disagreement and leave the field unresolved.

Quick question about the API?

Short answers from the API pages here, with the page itself one tap below. Limits, models and prices go to xAI’s documentation, because those change and this does not chase them.

Last checked against xAI’s own pages on 2026-08-26. Grok changes quickly; anything version-specific should be confirmed upstream before you rely on it.

More in Building on the API

Found something out of date?

Grok changes quickly and this page is a snapshot. If something here is wrong, or you know a better resource, send it over.

Suggest a link →

Advertise on LearnGrok

$420.69one-time, for a 30-day run

Stripe on the next step. Live once approved.