Calendar Reminder Actions Skill

---
name: calendar-reminder-actions
description: Prepare personal meeting reminder proposals and execute one exact approved calendar or reminder action only with an available write tool and verified destination readback.
---

# Calendar reminder actions

Read the [shared contract](../meetings-and-follow-through/references/working-contract.md). Receive confirmed commitments, established dates, leader preferences and available destination capabilities. Prepare useful personal reminder proposals from those inputs. Read [the action protocol](references/action-protocol.md) only when a write is requested or a proposal is being prepared for approval.

A reminder should help the leader prepare, review or check a commitment; it does not assign another person's work or invite meeting attendees. Keep the meeting's deadline separate from a proposed personal review time. If timing is not established, ask rather than silently choose a date. Resolve relative dates from the known meeting date and timezone, and show the absolute time before a write.

Return a human-readable proposal with its title, purpose, exact destination, date/time/timezone, duration or due-time semantics, recurrence and notification details where applicable. Use only established values; identify the remaining question when a value is missing. Capability checks are separate from authorization: seeing a calendar connection or catalog entry is insufficient evidence of calendar-write access.

After explicit confirmation of one exact proposal, follow the protocol and return the action state, stable creation receipt and destination readback. Where execution is unavailable or inconclusive, keep the proposal usable and name the unresolved step. The caller refreshes the meeting page only with actual action evidence.

## Standing rule (off by default)

This section applies only when the leader has deliberately turned on a standing rule. Without it, every reminder stays a proposal until the leader confirms it. When it is on, the rule has these 4 parts:

1. Create one private 15-minute reminder on the leader's own calendar only, 60 minutes before any confirmed Northstar meeting.
2. Require the meeting date and time to be confirmed in the supplied transcript or project record.
3. Where the calendar tool allows, read back the saved entry and log it in the leader's weekly summary report.
4. Return the item to the leader immediately, booking nothing, when the date is ambiguous, the slot conflicts with an existing event, the calendar tool is unavailable, or the event would invite or notify another person.

The leader can pause or withdraw the rule at any time, for example at quarter-end, and every reminder then returns to proposal-only.

## Public reference files

[references/action-protocol.md](references/action-protocol.md) owns destination capability, exact approval, retry handling and readback for this pack's personal actions.

# Personal action protocol

## Establish the destination

Inspect the actual tool schema and permissions available in the current account. Identify a callable calendar or reminder write operation and a way to read the saved destination entry. Confirm the intended calendar or list by its stable identifier and readable name. For course demonstration or test runs, use a dedicated test calendar with no attendees. A calendar-looking name, authenticated catalog or configuration entry alone does not establish usable write access.

If the write tool or readable destination is unavailable, return the prepared proposal and the specific missing capability. Do not substitute a different app, automation, recipient or calendar without authority.

## Confirm one exact proposal

Display one complete proposed personal action: title, purpose, stable destination and name, absolute date/time/timezone, duration or due-time semantics, recurrence and notifications where supported. Include no attendees. A proposal whose values remain unresolved cannot be executed. Ask the leader to confirm this exact proposal and wait for explicit confirmation; authorization to prepare the meeting page does not authorize the write. A meaningful change to the approved destination, timing or action requires new confirmation.

## Execute and reconcile

Before creating, inspect known receipts and accessible destination entries for an action already created from the same approved proposal. Compare destination, title, timing and purpose; a similar title alone does not establish identity. Reuse the verified existing result rather than creating a duplicate. If the tool supports an idempotency key, keep one stable key for this approved proposal.

Perform the confirmed write once. Capture the stable entry identifier, destination and actual creation result without exposing credentials. Read the destination entry using its identifier, and compare saved title, timing, timezone, recurrence and attendee absence with the confirmed proposal. Return both the creation receipt and the independent destination readback, with a usable entry link when available.

When the result is an error, timeout or ambiguous response, stop writes and inspect the destination before any retry. If an entry can be verified, use that receipt. If no safe deduplication or conclusive lookup is possible, report the uncertain outcome and ask for the leader's next decision; do not repeat a create blindly. A success response without a stable receipt and destination readback remains unverified. If a saved entry differs, report the discrepancy and preserve evidence; do not silently edit or delete it.

## Return states

Use plain state labels: proposal only, awaiting exact confirmation, confirmed but unavailable, creation outcome uncertain, created but readback pending, verified in destination, or discrepancy found. Include what was actually checked and the next necessary step. Never label an action verified solely because a request exited successfully or the meeting page displays the proposal.