# A commitments board for what people promised in meetings

> Every promise made in a meeting lands on one board with an owner, a due date and the meeting it came from, so the ones that slip stay obvious.

- Workflow type: app
- Services: General Input Database, Google Calendar, Slack Bot
- Categories: Operations, Personal Productivity
- Published: 2026-08-22

## What it does

- One shared board of every commitment showing who owns it, what they promised, who they promised it to, when it is due and which meeting it came from.
- Views for overdue first, by owner, by meeting and recently closed, with each person landing on their own open items when they open the app.
- Pick a meeting from your calendar, paste the notes, and an assistant pulls out each promise as a draft row that a person confirms before it reaches the board.
- A nudge button sends the owner a Slack direct message listing their open items, and it only ever goes out when someone presses it.

## What you'll need

- A General Input account, since the board keeps every commitment in your own General Input database rather than a spreadsheet
- A Google Calendar login so the app can list your recent and upcoming meetings to attach commitments to
- A Slack workspace with the bot installed, if you want the nudge button to send direct messages
- Your meeting notes in whatever form you already keep them, ready to paste in when you extract commitments

## Prompt

Build me an app that tracks every commitment people make in meetings. Ours get lost between scattered notes and nobody remembers who promised what by when, so I want one persistent board of promises rather than another checklist. The General Input Database is the anchor and the system of record: it owns the commitments, their owners, due dates, status history and the link to the calendar event each one came from. Every read and write in the app goes through the user-database Execute SQL operation, and on first run the app should use Create or List Databases to find or create the database and then create its tables if they do not exist.

Use roughly this schema, adjusting names as you see fit. A commitments table with: id, owner_name, owner_email, promised_to (the person or team the promise was made to), commitment_text (the actual wording of what was promised), due_date, original_due_date, times_moved, status (draft, open, done, cancelled), calendar_event_id, meeting_title, meeting_start, source (agent or manual), created_by, created_at and closed_at. A date_changes table with: id, commitment_id, previous_due_date, new_due_date, reason, changed_by and changed_at. A nudges table with: id, commitment_id or owner_email, sent_by, sent_at, slack_target and message_preview, so every nudge that has ever gone out is visible on the board.

The app opens on a board of commitments. Each card shows the owner, what they promised in their own words, who they promised it to, the due date and the meeting it came from. Give me these views over the same shared record set: overdue first (anything past due, most overdue at the top, with days late on the card), by owner (grouped per person with an open count and an overdue count each), by meeting (grouped by calendar event, so you can see everything that came out of Monday's planning call), and recently closed (what was completed in the last few weeks, so the board shows follow through and not just debt). When a person opens the app, default them to their own open items, filtered on owner_email matching the signed in viewer, with one click to see the whole team's board. Every one of these views is a SELECT through Execute SQL, and creating, editing, completing or cancelling a commitment is an INSERT or UPDATE through the same operation.

Use the Google Calendar List Events operation to pull recent and upcoming meetings so a commitment can be attached to the meeting it actually came from. Scope it to a window such as the last 30 days through the next 14 days, expand recurring events into individual instances, and order by start time. Show that list wherever someone attaches or reassigns a meeting, and support searching it by title since busy calendars are long. Store the calendar event id on the commitment along with a copy of the meeting title and start time, so the by meeting view still reads correctly even if the calendar entry is later changed or deleted.

Include an "Extract commitments from this meeting" button that kicks off a background agent. The person picks a meeting from the calendar list and pastes in the notes from it, and the agent reads the notes, parses out each distinct commitment, and works out the owner, the exact wording of what was promised, who it was promised to and the due date. It should resolve relative dates like "by end of week" or "before the next sync" against the meeting date, and leave the due date empty rather than guessing when the notes genuinely do not say. The agent writes its findings back through Execute SQL as rows with status set to draft and source set to agent, tagged with the chosen calendar event id. Those drafts never appear on the main board. They land in a review queue where a person reads each one beside the line of notes it came from, edits the owner, wording or date, then confirms it (which flips the status to open and puts it on the board) or discards it. Show the run in progress and land the drafts in the queue when it finishes so the app can display them without the person going anywhere else.

Nudging is always an explicit button, never automatic. When someone presses nudge on an owner, the app uses the Slack Bot Look Up User by Email operation to resolve that owner's email to a Slack user, then Send a Message to direct message them a short, friendly list of their open commitments with the due date and source meeting on each line. Log every nudge to the nudges table and show on the card when the owner was last nudged and by whom, so nobody gets pestered twice in a day by two different people. Do not add any scheduled or background nudging anywhere in the app.

Re-dating a commitment must keep the original date visible so slipped promises stay obvious. When someone changes a due date, keep original_due_date as first captured, write a row to date_changes with the old date, the new date, who moved it and an optional reason, and increment times_moved. The card should read something like "due 17 March, originally 3 March, moved twice", and the overdue view should treat repeat movers as worth noticing rather than quietly resetting the clock. Completing a commitment records who marked it done and when, and it drops into recently closed rather than disappearing.

Keep the whole thing fast to work in: inline editing on the board, a quick add form for a commitment someone remembers after the fact, and a search across owner, wording and meeting title. The people who use this are whoever sits in the meetings, so it has to be readable by someone who has never seen the app before and does not want to learn a workflow.

## How to customize

- Change what counts as overdue, for example allowing a few days of grace before a commitment turns red
- Reword the nudge message, or point it at a shared channel instead of a private direct message
- Set how far back and forward the meeting list reaches, and which calendar it pulls from
- Add your own fields to a commitment, such as a priority level, a project tag or a customer name

## FAQ

### Do I need a meeting recorder or transcription tool for this?

No. You paste in whatever notes you already take, whether that is a few bullets in a doc, a transcript, or a summary someone else wrote. The assistant reads the text you give it and pulls the promises out of that.

### Will it start nudging people on its own?

Never. Nudging is always a button a person presses. Nothing is sent on a schedule and nothing goes out in the background, so the board cannot turn into a source of automated nagging.

### What happens when someone pushes a due date back?

The commitment keeps its original date on the card alongside the new one, plus a count of how many times it has moved. A promise that has slipped three times looks different from one that was always due next Friday.

### Can everyone see everyone else's commitments?

Yes, the board is shared, which is the point. Each person just lands on their own open items first, then switches to the overdue, by owner, by meeting or recently closed views when they want the wider picture.

### Does the assistant put commitments straight onto the board?

No. Everything it finds arrives as a draft that a person reads, edits and confirms. Anything it misread or invented gets thrown away before it becomes a commitment anyone is held to.

Use this prompt in General Input: https://www.generalinput.com/prompts/a-commitments-board-for-what-people-promised-in-meetings