---
name: daycare-planning
description: >-
  Plan and maintain daycare drop-off and pick-up schedules in Google Calendar for Mikael and Lisa. Use when the user gives a weekly daycare plan in plain language, such as "Mon: Mikael lämna, Lisa hämta", and Codex needs to create, update, or clean up weekday calendar events, invite only the assigned parent for each event, preserve event ownership on the primary calendar owned by tulebergstrollet@gmail.com, and notify the user when an invite is declined or auth/calendar access blocks the workflow.
---

# Daycare Planning

Create and maintain weekday daycare events on the primary Google Calendar owned by `tulebergstrollet@gmail.com`.

Use `gog` for calendar operations.

## Fixed rules

- Calendar owner: `tulebergstrollet@gmail.com`
- Target calendar: primary calendar for that account
- Required invitee on each daycare event: only the assigned parent
  - invite `lisa.h.bjork@gmail.com` when Lisa is assigned
  - invite `mikael@boid.se` when Mikael is assigned
- Default working days: Monday to Friday
- Time zone: `Europe/Stockholm`
- Drop-off event:
  - Summary: `Lämna barn`
  - Time: `08:00` to `08:15`
- Pick-up event:
  - Summary: `Hämta barn`
  - Time: `16:00` to `18:00`
- No reminders unless the user explicitly asks
- If an invite is declined, notify the user. Do not silently ignore it.
- Support both creating new events and updating or deleting previously managed events when the weekly plan changes.

## Input shape

Expect a weekly plan in simple text, usually one line per weekday.

Examples:

- `Mon: Mikael lämna, Lisa hämta`
- `Tue: Lisa lämna, Lisa hämta`
- `Fri: Mikael lämna, Mikael hämta`

Interpret Swedish verbs as:

- `lämna` = drop-off
- `hämta` = pick-up

If a weekday is omitted, treat it as unspecified. Do not invent assignments for omitted days unless the user explicitly says to assume the full week from an earlier pattern.

## Event model

Manage two separate events per weekday when assignments exist:

- one `Lämna barn` event
- one `Hämta barn` event

Invite only the assigned parent to each daycare event.

Store the assigned parent in both places:

- description, short and human-readable, for example `Ansvarig: Mikael`
- shared properties, so future updates can reliably find and reconcile managed events

Use these shared properties on create and keep them updated:

- `skill=daycare-planning`
- `kind=dropoff` or `kind=pickup`
- `date=YYYY-MM-DD`
- `assigned=Mikael` or `assigned=Lisa`

These properties are the source of truth for later reconciliation.

## Workflow

### 1. Parse the user request

Extract:

- target week or explicit dates
- weekday assignments for drop-off and pick-up
- whether the user wants create-only or reconciliation with existing events

If the week is ambiguous, ask one short follow-up question before touching the calendar.

### 2. Resolve dates

Convert weekday assignments into concrete dates in `Europe/Stockholm`.

Default to Monday to Friday only.

### 3. Preflight checks

Before making changes:

1. Confirm `gog` auth works for the calendar account.
2. Use the primary calendar of `tulebergstrollet@gmail.com`.
3. If auth fails, stop and tell the user exactly what is blocked.

Prefer commands like:

```bash
gog calendar events primary --account tulebergstrollet@gmail.com --today --max 1 --json --no-input
```

If the account cannot access the calendar or returns OAuth errors, do not guess. Report the problem.

### 4. Read existing managed events for the target range

List existing daycare-planning events for the relevant date range with shared property filters.

Example pattern:

```bash
gog calendar events primary \
  --account tulebergstrollet@gmail.com \
  --from 2026-05-04 \
  --to 2026-05-09 \
  --shared-prop-filter skill=daycare-planning \
  --json --no-input
```

Build an in-memory map keyed by `date + kind`.

### 5. Reconcile desired state against existing state

For each target date and kind:

- Create the event if none exists.
- Update the event if summary, time, attendees, description, or assigned parent differs.
- Delete the managed event if it exists but the new plan removes that assignment.

Do not modify unrelated events.

## Command patterns

### Create

Use `--send-updates all` so invitees actually receive updates.

```bash
gog calendar create primary \
  --account tulebergstrollet@gmail.com \
  --summary "Lämna barn" \
  --from 2026-05-04T08:00:00+02:00 \
  --to 2026-05-04T08:15:00+02:00 \
  --description "Ansvarig: Mikael" \
  --attendees "mikael@boid.se" \
  --shared-prop skill=daycare-planning \
  --shared-prop kind=dropoff \
  --shared-prop date=2026-05-04 \
  --shared-prop assigned=Mikael \
  --send-updates all \
  --json --no-input
```

### Update

Replace attendees explicitly so only the assigned parent remains present.

```bash
gog calendar update primary <eventId> \
  --account tulebergstrollet@gmail.com \
  --summary "Hämta barn" \
  --from 2026-05-04T16:00:00+02:00 \
  --to 2026-05-04T18:00:00+02:00 \
  --description "Ansvarig: Lisa" \
  --attendees "lisa.h.bjork@gmail.com" \
  --shared-prop skill=daycare-planning \
  --shared-prop kind=pickup \
  --shared-prop date=2026-05-04 \
  --shared-prop assigned=Lisa \
  --send-updates all \
  --json --no-input
```

### Delete

Only delete events that were previously tagged with `skill=daycare-planning`.

```bash
gog calendar delete primary <eventId> \
  --account tulebergstrollet@gmail.com \
  --send-updates all \
  --json --no-input
```

## Declines and mitigation

After create or update, inspect the returned attendee status when available. Also inspect existing events if the user asks for a check.

If either attendee has declined:

- do not auto-reassign
- notify the user clearly
- include the date, leg (`Lämna barn` or `Hämta barn`), and who declined

Example notification:

- `Lisa declined Hämta barn on 2026-05-04. Reassignment needed.`

## Output expectations

When the work succeeds, report a concise summary:

- created events
- updated events
- deleted events
- any declined invites or auth problems

Example:

- `Created 10 daycare events for week 19.`
- `Updated Tue pick-up from Mikael to Lisa.`
- `No declines detected.`

## Guardrails

- Do not create recurring events unless the user explicitly asks.
- Do not add reminders by default.
- Do not use a different calendar unless the user explicitly overrides the default.
- Do not edit unrelated calendar entries.
- If a date or week reference is ambiguous, ask before changing the calendar.
- Prefer reconciliation over blind creation, to avoid duplicate events.