/checkin

name: checkin
description: Run an interactive email check-in with FYIs, decisions, drafts, and durable follow-up. Use for inbox review, catch-up, continuing an email batch, or changing check-in preferences. The broader calendar/reminder routine is an explicit option. Do not use for an isolated email lookup or standalone reply.
metadata:
  version: "2.0.0"

Check-in

Default to email: run the installed `/triage-inbox`, then present **FYIs** followed by **Needs attention**. Keep the user's decisions, unfinished drafts, and unshown candidates across sessions. Use existing approved mail tools, not a private send script or a newly created authenticated client.

The normal FYI setting marks selected, fully reviewed, no-action messages read before showing their summaries. It does **not** archive them. Disclose this during setup and honor existing policy or any user opt-out. No reply needed does not necessarily mean no action: an attachment to read, portal task, intentional later reading, or an unresolved hold belongs in Needs attention.

This folder includes configuration, workflow references, and a Python 3.9+ standard-library batch writer. It requires a mail connection. `/triage-inbox` is a separately installed skill for the sorting phase; if missing, report that and offer to install its full public folder. Read-only email review can still proceed with a disclosed triage gap. Calendar, task app, and meeting tools are optional and only used when relevant or requested.

First-time setup

1. Find the user's existing email-assistant project, account, policy, and triage configuration. Reuse them. Do not replace customized files or introduce a second policy. Resolve the installed skill paths and use actual connector schemas on the current host. 2. Create `config/checkin-config.md` from the bundled [template](assets/checkin-config.md) only if no working check-in configuration exists. Fill in the account, policy and runtime paths. Keep batches outside the skill, for example under `state/checkin-email-batches/`. Preserve old session summaries without pretending they contain per-item decisions. 3. Explain the default FYI behavior: read the selected messages and their context, mark qualifying ones read, verify, and summarize them; leave them in the inbox. Record this specific standing permission in the policy if the user accepts it. Do not override an existing preserve-unread instruction silently. There is no repeated per-message approval once this permission is established. 4. Configure the enabled extra reviews using [preferences.md](references/preferences.md): family/important labels, quarantine digests, and newsletter reading holds. Ask for relevant sources once during setup. Enabled without a source means **not configured**, not a completed review. If an extra does not apply, the user can turn it off in plain language. Do not invent a provider, label, subscription, or private workflow. 5. Choose reply mode: `review_then_send` through the available approved connector, or `draft_only`. Check the connection's actual capabilities. Record the user's writing preferences and any task app they already use. Never copy another person's addresses, voice files, sending infrastructure, or standing forwarding instructions. 6. Save the agreed account and file paths in project instructions for later sessions. Mark setup complete only after resolving these choices. Installing this skill does not schedule a check-in or send any mail.

Modes and boundaries

| Request | Scope | |---|---| | `/checkin` or `/checkin email` | New email review of the last 24 hours, plus known unfinished obligations. | | `/checkin last 6 hours` | Requested interval. “Since last review” uses the last verified discovery cutoff, not answer time. | | `/checkin catch up` | Last 14 days, both read and unread, plus known unfinished work. A requested number of days overrides 14. | | `/checkin resume` | Reconcile an existing batch and its pending work. Do not start general triage again. | | “Next batch” / “keep going” | Continue the current scope and its unshown candidates. Retain earlier decisions, drafts, and holds. | | `/checkin full` | Broader routine in [full-session.md](references/full-session.md). | | `quick`, `tomorrow`, or `no-email` | Corresponding broader mode, as defined in that reference. | | `no-triage` | Skip ordinary filing for this review. Enabled family/quarantine reviews remain read-only unless separately authorized. | | `noapply`, `dryrun`, or explicit read-only preview | No mail, calendar, reminder, policy, batch, or operational-state writes. Pass preview to triage. Return proposals in chat. |

Explicit fixed historical ranges, only-new requests, excluded sections, and user opt-outs take precedence over wider default discovery. A one-session skip is not a permanent preference. An explicit “turn off from now on” updates the saved configuration, unless the user requested preview only.

Review workflow

Read [review.md](references/review.md) and [continuity.md](references/continuity.md). For enabled extras read [preferences.md](references/preferences.md). Read [sending.md](references/sending.md) before preparing final approvals or acting on replies.

1. Recover context and run canonical triage

Read the current policy/configuration and relevant open/recent batches. Keep older unfinished work and useful unshown candidates, even from batches whose displayed items are finished. Do not copy old approvals to new mail.

Before triage, resolve configured newsletter windows and existing message holds into exact message IDs; preserve any rule that keeps unread status or retains a message in Inbox. On a fresh ordinary review, invoke the actual installed `/triage-inbox` workflow with the account, policy paths, mode/range, and current exact-ID holds. Do not inline an older triage algorithm or write its state yourself. One executor owns mailbox filing at a time. Reuse returned verified results, actual coverage, and failur