Calendar Conflict Defender.

How this fits in the OS.

What you'll build.

A small, focused agent that watches for new calendar invites and answers them the way you would. When a request lands on a slot you'd accept anyway, it queues a clean accept. When the request collides with a deep work block, it drafts a decline in your voice and offers a real counter-time pulled from your live availability. Nothing leaves your outbox without you seeing it first.

This is honestly synthesized, not pulled from a fixed blueprint. The Calendar connector exposes the primitives (read events, find availability, detect conflicts, create events). The preferences live in your CLAUDE.md so future sessions inherit them. The slash command stitches the two together. The cron wakes the loop.

What changes for you.

The artifact is small. The shift in how the day feels is larger. Three changes, roughly in order of how soon you'll notice them:

• The deep work blocks stop being aspirational. They're protected by something that doesn't get tired or polite. The agent treats a Tuesday morning maker block the same way it treats a doctor's appointment.
• You stop being the calendar's secretary. Most invites resolve cleanly without you touching them. The ones that need you arrive pre-framed with a one-line explanation, not as a fresh problem to solve from zero.
• Counter-times stop being awkward. The agent always pairs a decline with a real alternative slot. The other party gets a path forward in the same reply, not a dead end. Friction drops on both sides.

Before you start.

The build.

Six steps. Preferences first, because the slash command reads them. Dry run before the schedule, because you don't want a half-tuned agent firing replies on a real invite. Schedule last.

The agent does most of the mechanical work. The parts that need you are the parts only you can answer: what your protected blocks actually are, who is allowed to override them, and whether the agent's first dry-run reply sounds like you.

When it works.

You'll know the defender is real when you see these signals over the first week:

• Your deep work blocks survive a full week. Not because nobody tried to book over them, but because the agent quietly declined and offered alternatives before you saw the request.
• The first invite of the morning is already resolved. You open your computer and the draft reply (or the clean accept) is waiting in your queue. Most days, two or three are.
• Counter-times actually get accepted. The other party takes the alternative slot without a back-and-forth, because the slot was real and polite.
• You stop hand-checking the calendar tab. The audit log is the new place you look, not the calendar itself. That's the shift.
• The escalations make sense. When the agent does ask you, it's because the invite was genuinely ambiguous, not because the agent was confused. If most escalations look obvious in hindsight, your preferences are too loose; tighten them.

If you get stuck.

Common failure modes, ranked by how often they bite people on a first build:

• The connector has read scope but not write. Most common gotcha. The agent can see the invite and detect the conflict, but it can't queue a draft reply or block a counter-time slot. Re-authorize the Google Calendar connector with the calendar write scope and re-run /mcp to confirm green.
• Timezones drift. Your computer is in one zone, the organizer is in another, and the calendar event stores a third. The agent compares the wrong numbers and either declines a clean slot or accepts a real conflict. Fix: pin your default timezone in the ## Calendar Defender Preferences section, and tell the agent to convert every proposed time to your local zone before evaluating it.
• Owner versus attendee confusion. The Calendar connector behaves differently for invites you're hosting versus invites you're receiving. The defender should only counter-propose on invites you're receiving. For invites you're hosting, escalate to you (declining your own event to yourself is a weird shape). Add an explicit rule in your preferences: "If I'm the organizer, always escalate."
• The override list is too broad. If you put a whole domain on the override list (your client's company, say), every cold pitch from that domain lands on your deep work. Override by named person, not by domain, unless you've actually thought it through.
• The agent counter-offers slots you'd never take. 7am to a vendor pitch, 6pm Friday to a colleague. Your counter-time rules need a floor and a ceiling per invite type. Easiest fix: add explicit hour ranges per category (external pitches in 10am-4pm, internal one-on-ones anytime in working hours).
• The agent auto-sent a reply. If this happens, the slash command spec lost the human-gate clause. Open configs/commands/defend-calendar.md and confirm the language explicitly says "queue as draft, never auto-send." Then re-test on a dry run before scheduling again.

Still stuck? Post the invite shape, the agent's decision, and what you expected, in the workshop Slack. Someone in the cohort has probably hit the same edge.

Where to go next.

The defender is one shape of "agent reads a request and replies on your behalf with a human gate." Three natural next moves on the shelf:

A sibling card, Email Reply Queue, applies the same shape (read incoming requests, draft replies with a human gate, escalate the ambiguous ones) to your inbox. It will land on the shelf in the next wave.