/commitments

/commitments

Small interpersonal promises are where trust is won or lost — "I'll send that over," "can you review this?" — and they evaporate because they never become tracked commitments. This skill surfaces them from what you already captured, and turns the real ones into tasks only when you say so.

Governing rule: do not rebuild the data layer. The Work MCP already ships the scanner — get_commitments_due reads recent meeting notes and person-page action items and returns them bucketed by due date. This skill is a thin present → confirm → create layer on top of it. It does not re-scan, add a store, or touch the extraction logic.

Arguments

$RANGE: optional — today (default), this-week, or all. Maps to the tool's date_range.

Step 1 — Scan (existing tool, don't reinvent)

Call get_commitments_due(date_range=$RANGE). It returns commitments_due_today, commitments_due_this_week, and commitments_no_date — each item carries commitment, due_date, source (the meeting file or person page), and, for person-page items, to_person.

If get_commitments_due returns a feature_status other than ok, follow the standard contract (surface the user-facing message it returns; never invent a result). If it errors or the Work MCP is unavailable, say so plainly and stop — do not fabricate a commitments list.

Optional enrichment (degrades silently): if ScreenPipe is active and opted-in, you may also fold in the commitment-scan (agent skill) results as an extra source. If ScreenPipe is absent — the normal case — skip it entirely and say nothing about it. The shipped skill must never depend on the beta.

Step 2 — Dedup against existing tasks

For each candidate, check it isn't already a task before showing it (Work MCP's create_task similarity gate is the backstop, but pre-filtering means the user isn't asked about things already captured). Drop obvious duplicates; keep near-matches but mark them "possibly already tracked."

Step 3 — Present, grouped by direction

Show two short lists so the user sees both sides of the ledger:

• Promises you made (outbound — you owe someone)
• Asks you received (inbound — someone owes you, or asked you to do something)

Direction is inferred from phrasing and to_person, not a field the scanner provides — so when a commitment's direction is genuinely unclear, put it under a third Unclear heading rather than guessing wrong. Each row shows: the commitment, the person (by name), the source (meeting or person page, by name), and the due_date (or "no date"). Refer to people and sources by name, never by id or file path noise.

If nothing is found, say so plainly ("No open commitments surfaced from the last two weeks of meetings and your person pages") — do not pad the list.

Step 4 — Confirm before creating (hard gate — never auto-create)

Nothing is written without the user's say-so. Offer, per item, three choices: create a task / already handled / not a real commitment. Only the items the user picks become tasks. This is the no-write-without-authority discipline — do not batch-create, and do not create anything the user didn't confirm.