---
name: reminder
description: Manage the current user's Reminder (时光小筑) events, todos, notes, journals, habits, focus sessions, and statistics through the configured Reminder MCP server. Use when an agent needs to read or change Reminder data, resolve relative dates, inspect conflicts or free time, record habits or focus, or handle Reminder MCP errors and idempotent writes.
---

# Reminder (时光小筑)

Use the configured Reminder MCP connection to operate on the authenticated user's data.

## Start Safely

1. Confirm that the Reminder MCP server is configured in the current host.
2. Never ask the user to paste an App JWT or long-lived Agent Token into chat.
3. If the connection is missing, ask the user to generate a new one-time installation link in the Reminder App. Read [auth-and-connection.md](references/auth-and-connection.md) before handling installation or authentication problems.
4. Never pass, invent, or infer `userId` or `user_id`; the bearer credential binds the user.

## Choose The Operation

- For reads, call the matching read-only MCP tool. Read [read-tools.md](references/read-tools.md) when selecting a tool.
- For every create, update, complete, check-in, archive, restore, or delete operation, call `commit_actions`. Read [write-actions.md](references/write-actions.md) before writing.
- For statistics, prefer dedicated stats tools instead of estimating from limited list results.
- For relative dates such as today, tomorrow, or this week, call `get_time_context` when the effective date or timezone is not already certain.

## Resolve Targets Before Writing

- Search or fetch the current resource before modifying, deleting, completing, archiving, or restoring it.
- Do not guess event, todo, note, habit, focus, category, tag, occurrence, or version identifiers.
- If several resources match, ask the user to choose before writing.
- Before a high-impact operation, show the resolved target and get user confirmation when the user's intent is not already explicit.

## Write Through `commit_actions`

- Use a new `idempotencyKey` for each independent user intent and start with `commitSeq: 1`.
- Keep every `actionId` unique within a commit.
- If a network failure leaves the result unknown, replay the exact same key, sequence, action IDs, and payload.
- If the server explicitly returns a retryable failed action, keep the same key, increment `commitSeq`, use a new `actionId`, and submit only the failed action.
- Never resubmit an action already marked `COMPLETED`.
- Treat a `READ_ONLY` authorization failure as final; do not search for another write path.

## Handle Results Honestly

- Check MCP `isError` before interpreting content.
- Inspect structured `status`, `errorCode`, `retryStrategy`, and per-action results.
- Do not report success when the server returned an error, partial failure, unknown result, or clarification request.
- Follow [failure-handling.md](references/failure-handling.md) for HTTP, MCP, and retry behavior.

## Time And Privacy

- Use ISO local date-time values such as `2026-08-16T15:00:00` and dates such as `2026-08-16`.
- Default to `Asia/Shanghai` unless the user or tool context provides another timezone.
- Do not expose credentials, setup links, private content, or raw service responses in logs or final replies.
- Private notes remain subject to server policy; never attempt to bypass a denied private-content read.