Commitment tracker

The gap between "we agreed Alice would do X by Friday" and a ticket assigned to Alice due Friday is where most organisational follow-through dies. This skill closes it — without creating a pile of low-quality tickets nobody asked for.

The rule that matters

Never create, assign, or close anything without explicit approval for that specific item. Not batch approval. Not "yes, go ahead" once at the start. Each write is confirmed on its own.

Bad tickets are worse than no tickets: they create cleanup work, they make the tracker untrustworthy, and they are attributed to a person who never agreed to them. The expensive failure mode here is not missing one item — it is filing twelve wrong ones.

Procedure

1. Collect commitments

With Wisprnote: list_action_items, or get_meeting_knowledge for a specific meeting. Otherwise work from notes the user supplies.

Keep the original wording attached to each item. You will need it at the approval step.

2. Check whether it already exists

Before proposing anything, search the tracker for a match on substance. Duplicate tickets are the most common damage this kind of automation causes. Search the owner's name plus a key noun, not the full sentence.

If something close exists, propose updating it rather than creating a new one.

3. Draft, do not create

For each commitment, prepare a proposal and show it in full:

Proposed: <project> ticket

Title:       <imperative, specific — "Add retry to webhook handler", not "Webhooks">
Assignee:    <name> — as named in the meeting
Due:         <date> — as agreed, or "none agreed"
Description:
  <what needs doing, in enough detail to act on>

  Agreed in: <meeting>, <date>
  As stated: "<original wording, verbatim>"

Source confidence: high | medium — <whether owner and date were explicit>

The verbatim line is not decoration. It lets the approver catch the case where your interpretation drifted from what was actually said.

4. Ask, one at a time

Present each proposal and wait. Accept four outcomes: create it, edit then create, skip, stop entirely. Treat silence or ambiguity as skip.

If the user says "do them all", still show the full list once and get confirmation on that list before writing anything.

5. Create, then report back

After each creation, report the identifier and URL. At the end, summarise: what was created, what was skipped, what was already tracked.

Guardrails

• Unowned items do not become tickets. If no person was named, surface it and ask who owns it. Assigning by inference puts work on someone who never agreed to it.
• Never close or reassign existing work unless explicitly asked for that specific item. Creating is recoverable; closing someone else's ticket is not.
• Respect "no date agreed". Inventing a due date manufactures a commitment nobody made.
• Do not editorialise. The description carries what was agreed, not your assessment of whether it is a good idea.
• If the tracker write fails, report the failure plainly and do not retry with altered content.