Scenarios

Three end-to-end walkthroughs — one per lane. Each shows the boundary between user-on-device, daemon, and external agent so you can spot where your own use case fits.

1 · Capture a bug from the iPhone

The user is on the train. They notice a bug in the wallgen UI. Instead of opening a laptop, they open Reminders, type a title, hit save. Five seconds after the Mac comes online, the bead exists.

iOS capture flow. EKEventStoreChanged does not fire for iCloud changes, so the latency is bounded by the 5s interval, not the iCloud sync itself.

What's interesting

The user never touched a terminal, never named the bead, never set a priority. The daemon defaults to p2 on capture.
The reminder gets renamed in place — iCloud carries the rename back to the phone so the user sees the assigned ID next time they look.
If the train trip is offline-only, the reminder still gets added locally; iCloud holds it until reconnect. Capture is essentially asynchronous.

2 · Voice walk with the voice agent

The user is mid-conversation with Claude Code about a migration. They want to keep thinking but stop staring at a screen. They invoke /voice-chat-takeout; the project agent composes a brief with everything that's on the table; the voice agent reads it on the phone and pushes back.

One voice exchange end-to-end. The 'done' reminder is the canonical close signal — it tears the list down on the next daemon cycle.

What's interesting

The skill's pre-flight (step 1) is what makes the difference between a substantive brief and an agenda summary. Anything proper-noun-grade gets backed by a tool call before it lands in the brief.
The voice agent has no idea about the wider project context — only what's in the brief. POV in the brief therefore has to address it directly ("you", as in the voice agent), with the user as third party.
The user closing with "done" is the cleanest path. Adding done as a reminder is the same as running rbridge mailbox close — both fire on the next 5s cycle.

3 · Multi-turn chat from Reminders.app

The user wants a quick summary of open bugs. No need to open a terminal — they file a chat-mode reminder, the daemon runs claude -p in the background, the reply lands in the body. A follow-up question is just another you: block in the same reminder.

Multi-turn chat. Session id persists in the reminder body, so close + reopen + new 'you:' block resumes the same conversation.

What's interesting

The reminder stays unchecked across turns. Checking it just makes the daemon skip it; the session JSONL persists under ~/.claude/projects/ and a new you: block on a rechecked reminder resumes the same session.
Output formatting is whatever Claude returns in the result event. For predictable structure, prompt for it explicitly ("reply in a markdown table").
This is the lane that crosses lines least — it has no beads coupling and no voice coupling. It's just "remote Claude with the reminder as terminal."

Pattern recap

Across all three scenarios, the same shape repeats:

User puts intent into Reminders (a title, a brief, a prompt).
Daemon notices on the next cycle (event or interval).
Daemon takes the action with the right backend (bd / claude / mailbox CLI).
Result lands back in Reminders — either as a renamed/restructured reminder, an appended body, or a brand-new list.

The user never needs to open the daemon's logs or run rbridge commands directly. Everything is round-trippable through the same surface.