@aitne-sh/aitne 0.1.5 → 0.1.7

package/agent-assets/skills/external-services/SKILL.native.claude.md

@@ -20,9 +20,9 @@ Base URL: `http://localhost:8321`. All daemon calls via `curl -s` with
 > - `POST /api/integrations/google_calendar/reconcile` (410)
 > - `/api/calendar/*` (route-prefix 410 in native mode)
 >
-> Reach Google Calendar through the
-> `mcp__claude_ai_Google_Calendar__*` MCP tools this Claude session
-> already holds.
+> Reach Google Calendar through the in-session Google Calendar
+> connector your harness exposes. Your tool menu lists every available
+> tool at session start — pick the Calendar one.
 >
 > Only **Google Calendar** is integration-gated here. Apple Calendar,
 > Outlook Calendar, Obsidian, GitHub, recurring-schedule CRUD,
@@ -65,71 +65,61 @@ The native gate covers Google Calendar only.
 ---
 
 <!-- service:calendar -->
-## Google Calendar — Claude connector (native MCP)
+## Google Calendar — in-session connector
 
-Tool namespace: `mcp__claude_ai_Google_Calendar__`
+The exact tool names depend on which Calendar connector your harness
+has loaded. Inspect your tool menu at session start and pick the
+matching capability.
 
-### Read-class tools (`requiredCapabilities` floor + optional reads)
+### Read-class capabilities (`requiredCapabilities` floor + optional reads)
 
-| Capability | Tool | Use |
-|---|---|---|
-| `list_events` | `mcp__claude_ai_Google_Calendar__list_events` | Window-list events on a calendar. |
-| `get_event` | `mcp__claude_ai_Google_Calendar__get_event` | Fetch a single event by id. |
-| `list_calendars` | `mcp__claude_ai_Google_Calendar__list_calendars` | Enumerate the user's calendars (find `primary`). |
-| `suggest_time` | `mcp__claude_ai_Google_Calendar__suggest_time` | Free-slot proposal — pure compute, no calendar side effect. |
+| Capability | What to do |
+|---|---|
+| `list_events` | Window-list events on a calendar (`calendarId`, `timeMin`, `timeMax`, `maxResults`). |
+| `get_event` | Fetch a single event by id. |
+| `list_calendars` | Enumerate the user's calendars (find `primary`). |
+| `suggest_time` | Free-slot proposal — pure compute, no calendar side effect. |
 
-Canonical list call:
-
-```
-mcp__claude_ai_Google_Calendar__list_events(
-  calendarId="primary",
-  timeMin="<ISO-8601 with offset>",
-  timeMax="<ISO-8601 with offset>",
-  maxResults=50
-)
-```
+Canonical list flow: invoke your connector's list-events function with
+`calendarId="primary"`, `timeMin` / `timeMax` as ISO-8601 timestamps with
+TZ offset, and a sensible `maxResults` (≈50).
 
 Canonical detail read (always GET-before-PATCH; see PATCH semantics
-below):
-
-```
-mcp__claude_ai_Google_Calendar__get_event(
-  calendarId="primary",
-  eventId="<id>"
-)
-```
+below): invoke your connector's get-event function with `calendarId` and
+the `eventId` returned by list.
 
-### Destructive tools (require explicit user confirmation)
+### Destructive capabilities (require explicit user confirmation)
 
 Per the registry's
-`google_calendar.backendConnectors.claude.destructiveTools`:
+`google_calendar.backendConnectors.claude.destructiveTools`, the
+following capability classes are destructive in native:claude mode:
 
-- `create_event` — adds a new event.
-- `update_event` — mutates an existing event (attendees field is
+- **Create event** — adds a new event.
+- **Update event** — mutates an existing event (attendees field is
   whole-list replacement; see warning below).
-- `delete_event` — removes the event.
-- `respond_to_event` — dispatches an RSVP to the organizer.
+- **Delete event** — removes the event.
+- **Respond to event** — dispatches an RSVP to the organizer.
 
 Apply the destructive-confirm contract every time. Summarise the
 intended change ("create 30-min focus block at 14:00 JST tomorrow"),
 wait for explicit OK, then issue the call.
 
-**ATTENDEES WARNING.** `update_event` replaces the attendees array
-verbatim — it does not append. To add one attendee:
+**ATTENDEES WARNING.** The update-event function replaces the attendees
+array verbatim — it does not append. To add one attendee:
 
-1. `get_event(...)` → copy `attendees: [...]`.
+1. Get the event → copy its `attendees: [...]`.
 2. Append the new attendee object.
-3. `update_event(... attendees=[<full list>])`.
+3. Update the event with the full attendees list.
 
 Forgetting the GET drops every existing invitee.
 
 **Recurring events.** Single-instance edits require the instance id
-(usually returned alongside the master in `list_events`). PATCHing the
+(usually returned alongside the master in list-events). PATCHing the
 master id shifts the whole series. Confirm with the user which scope
 they meant — "move this 9am to 10am" can mean the master or a single
 occurrence and the agent must not guess.
 
-`suggest_time` is read-only and exempt from the confirm dance.
+The suggest-time capability is read-only and exempt from the confirm dance.
 
 ### Time discipline
 
@@ -148,10 +138,10 @@ fetch every hour and POSTs each materialised event to
 `/api/observations`. The hourly_check native variant's Step 0b spells
 out the exact shape; this skill describes the call surface.
 
-Free-busy queries are composed locally — `suggest_time` returns slot
-proposals against a primary calendar; for explicit free-busy across
-multiple calendars, list each calendar's events in the window and
-intersect.
+Free-busy queries are composed locally — the suggest-time capability
+returns slot proposals against a primary calendar; for explicit
+free-busy across multiple calendars, list each calendar's events in
+the window and intersect.
 
 <!-- /service:calendar -->
 
@@ -253,27 +243,28 @@ When the hourly_check native flow's Step 0b fetches imminent-window
 events, POST each materialised event to `/api/observations` so
 subsequent runs can dedup. The daemon computes `contentHash`
 server-side via `@personal-agent/shared/observations-hash.ts` — pass
-the raw `payload`:
+the raw `payload`.
+
+**Batch when you have more than one event.** Use
+`POST /api/observations/batch` with up to 200 items in one
+`observations[]` array (see the `observations` skill for the envelope).
+The single-item form below is for the rare "one new event surfaced"
+case.
 
 ```bash
 curl -s -X POST http://localhost:8321/api/observations \
   -H 'Content-Type: application/json' \
   -d '{
-    "source": "google_calendar",
-    "type": "calendar:lifecycle",
+    "source": "google_calendar:<calendarId>",
     "ref": "<eventId>",
-    "actor": "user",
-    "receivedAt": "<ISO-8601 UTC>",
-    "summary_text": "<title — start..end>",
-    "refs": {
-      "eventId": "<id>",
-      "calendarId": "primary",
-      "windowKey": "primary:imminent"
-    },
-    "payload": <verbatim MCP event object>
+    "changeType": "created",
+    "actor": "agent",
+    "payload": <verbatim connector event object>
   }'
 ```
 
+`actor` MUST be `"agent"` or `"system"` — the server rejects `"user"`.
+
 `/api/observations` is never gated. HTTP 409 indicates a mode-flip race
 window (§11.3.1) — stop and re-read `<integration_modes>`.
 

package/agent-assets/skills/external-services/SKILL.native.codex.md

@@ -1,13 +1,13 @@
 ---
 name: external-services
-description: Load when an external-services surface is in scope (Google Calendar / Obsidian / GitHub / Skills CRUD / scheduling) and Google Calendar is in native mode bound to Codex (`nativeBackend === "codex"`). Calendar runs through Codex's hosted Calendar MCP directly; the daemon does not proxy Calendar. Other surfaces (Apple/Outlook Calendar, Obsidian, GitHub, scheduling, Skills CRUD) keep their direct routes.
+description: Load when an external-services surface is in scope (Google Calendar / Obsidian / GitHub / Skills CRUD / scheduling) and Google Calendar is in native mode bound to Codex (`nativeBackend === "codex"`). Calendar runs through the in-session Calendar connector your Codex harness exposes directly; the daemon does not proxy Calendar. Other surfaces (Apple/Outlook Calendar, Obsidian, GitHub, scheduling, Skills CRUD) keep their direct routes.
 allowed-tools:
   - Bash(curl *)
   - Bash(jq *)
   - Read
 ---
 
-# External Services — Native Mode (Codex Calendar MCP)
+# External Services — Native Mode (in-session Calendar connector)
 
 Base URL: `http://localhost:8321`. All daemon calls via `curl -s`
 with `Content-Type: application/json` on POST/PATCH/PUT.
@@ -20,9 +20,9 @@ with `Content-Type: application/json` on POST/PATCH/PUT.
 > - `POST /api/integrations/google_calendar/reconcile` (410)
 > - `/api/calendar/*` (route-prefix 410)
 >
-> Reach Google Calendar through the
-> `mcp__codex_apps__google_calendar._*` MCP tools your Codex session
-> already holds.
+> Reach Google Calendar through the in-session Google Calendar
+> connector your harness exposes. Your tool menu lists every available
+> tool at session start — pick the Calendar one.
 >
 > Only **Google Calendar** is integration-gated here. Apple Calendar,
 > Outlook Calendar, Obsidian, GitHub, recurring-schedule CRUD,
@@ -49,63 +49,55 @@ allowlist constraints.
 ---
 
 <!-- service:calendar -->
-## Google Calendar — Codex hosted Calendar MCP (native)
+## Google Calendar — in-session connector
 
-Tool namespace: `mcp__codex_apps__google_calendar._`
+The exact tool names depend on which Calendar connector your harness
+has loaded. Inspect your tool menu at session start and pick the
+matching capability. Codex-side hosted Calendar connectors typically
+expose batch read and a free-busy primitive that Claude's hosted
+connector approximates with `suggest_time`; rely on the capability
+classes below rather than specific names.
 
-The Codex namespace terminates with `._`; the bare suffix below is what
-you write after the namespace (`_search` = `mcp__codex_apps__google_calendar._search`).
+### Read-class capabilities
 
-### Read-class tools
+| Capability | What to do |
+|---|---|
+| `search` | Free-text / filter search across events. Most connectors expose two variants — a general search and a window-list flavor scoped to a `calendarId` + `timeMin` / `timeMax`. |
+| `read` | Single-event read by id; many connectors also expose a "fetch full payload incl. attendees" flavor. |
+| `get_availability` | Free-busy across one or more calendars (pure compute, no side effect). |
+| `batch_read` | Pull many events by id in one round-trip — use when the search returned a list and you need each event's full body. |
 
-| Capability | Tool(s) | Use |
-|---|---|---|
-| `search` | `_search`, `_search_events` | Free-text / filter search. |
-| `read` | `_read_event`, `_fetch` | Single-event read; `_fetch` returns the full payload incl. attendees. |
-| `get_availability` | `_get_availability` | Free-busy across one or more calendars (pure compute, no side effect). |
-| `batch_read` | `_batch_read_event` | Pull many events by id in one round-trip. |
+Canonical window-list flow: invoke your connector's search-events /
+list-events function with `calendar_id="primary"`, `time_min` /
+`time_max` as ISO-8601 timestamps with TZ offset, and a sensible
+`max_results` (≈50).
 
-Canonical search call (window-list):
+Canonical detail read (always GET-before-PATCH; see PATCH semantics
+below): invoke the read-event function with `calendar_id` and the
+`event_id` returned by search.
 
-```
-mcp__codex_apps__google_calendar._search_events(
-  calendar_id="primary",
-  time_min="<ISO-8601 with offset>",
-  time_max="<ISO-8601 with offset>",
-  max_results=50
-)
-```
-
-Canonical detail read:
-
-```
-mcp__codex_apps__google_calendar._read_event(
-  calendar_id="primary",
-  event_id="<id>"
-)
-```
-
-### Destructive tools (require explicit user confirmation)
+### Destructive capabilities (require explicit user confirmation)
 
 Per the registry's
-`google_calendar.backendConnectors.codex.destructiveTools`:
+`google_calendar.backendConnectors.codex.destructiveTools`, the
+following capability classes are destructive in native:codex mode:
 
-- `_create_event`
-- `_update_event` — attendees field is whole-list replacement; see
-  warning below.
-- `_delete_event`
-- `_respond_event` — dispatches an RSVP to the organizer.
+- **Create event** — adds a new event.
+- **Update event** — mutates an existing event (attendees field is
+  whole-list replacement; see warning below).
+- **Delete event** — removes the event.
+- **Respond to event** — dispatches an RSVP to the organizer.
 
 Apply the destructive-confirm contract: summarise the plan, wait for
 explicit OK, then issue. The starter `deniedTools` list is enforced
 before the call lands.
 
-**ATTENDEES WARNING.** `_update_event(attendees=[...])` replaces the
-list verbatim. To add one attendee:
+**ATTENDEES WARNING.** The update-event capability replaces the
+attendees array verbatim. To add one attendee:
 
-1. `_read_event(...)` → copy `attendees`.
+1. Read the event → copy `attendees`.
 2. Append the new attendee.
-3. `_update_event(..., attendees=[<full list>])`.
+3. Update with the full attendees list.
 
 **Recurring events.** Single-instance edits require the instance id;
 master-id PATCH shifts the whole series. Confirm scope before issuing.
@@ -200,27 +192,27 @@ from the session's integration state independently of Calendar.
 
 ## Persisting Calendar observations from native fetches
 
+**Batch when you have more than one event.** Use
+`POST /api/observations/batch` with up to 200 items in one
+`observations[]` array (see the `observations` skill for the envelope).
+The single-item form below is for the rare "one new event surfaced"
+case.
+
 ```bash
 curl -s -X POST http://localhost:8321/api/observations \
   -H 'Content-Type: application/json' \
   -d '{
-    "source": "google_calendar",
-    "type": "calendar:lifecycle",
+    "source": "google_calendar:<calendarId>",
     "ref": "<eventId>",
-    "actor": "user",
-    "receivedAt": "<ISO-8601 UTC>",
-    "summary_text": "<title — start..end>",
-    "refs": {
-      "eventId": "<id>",
-      "calendarId": "primary",
-      "windowKey": "primary:imminent"
-    },
-    "payload": <verbatim MCP event object>
+    "changeType": "created",
+    "actor": "agent",
+    "payload": <verbatim connector event object>
   }'
 ```
 
 The daemon computes `contentHash` server-side — pass the raw `payload`
-verbatim. HTTP 409 indicates a mode-flip race window (§11.3.1); stop
+verbatim. `actor` MUST be `"agent"` or `"system"` — the server rejects
+`"user"`. HTTP 409 indicates a mode-flip race window (§11.3.1); stop
 and re-read `<integration_modes>`.
 
 ---

package/agent-assets/skills/external-services/SKILL.native.gemini.md

@@ -1,13 +1,13 @@
 ---
 name: external-services
-description: Load when an external-services surface is in scope (Google Calendar / Obsidian / GitHub / Skills CRUD / scheduling) and Google Calendar is in native mode bound to Gemini (`nativeBackend === "gemini"`). Calendar runs through the google-workspace extension directly; the daemon does not proxy Calendar. Other surfaces (Apple/Outlook Calendar, Obsidian, GitHub, scheduling, Skills CRUD) keep their direct routes.
+description: Load when an external-services surface is in scope (Google Calendar / Obsidian / GitHub / Skills CRUD / scheduling) and Google Calendar is in native mode bound to Gemini (`nativeBackend === "gemini"`). Calendar runs through the in-session Calendar connector your Gemini harness exposes directly; the daemon does not proxy Calendar. Other surfaces (Apple/Outlook Calendar, Obsidian, GitHub, scheduling, Skills CRUD) keep their direct routes.
 allowed-tools:
   - Bash(curl *)
   - Bash(jq *)
   - Read
 ---
 
-# External Services — Native Mode (Gemini google-workspace extension)
+# External Services — Native Mode (in-session Calendar connector)
 
 Base URL: `http://localhost:8321`. All daemon calls via `curl -s` with
 `Content-Type: application/json` on POST/PATCH/PUT.
@@ -20,9 +20,10 @@ Base URL: `http://localhost:8321`. All daemon calls via `curl -s` with
 > - `POST /api/integrations/google_calendar/reconcile` (410)
 > - `/api/calendar/*` (route-prefix 410)
 >
-> Reach Google Calendar through the
-> `mcp_google-workspace_calendar.*` MCP tools your Gemini session
-> already holds via the `google-workspace` extension.
+> Reach Google Calendar through the in-session Google Calendar
+> connector your harness exposes (typically Gemini CLI's
+> `google-workspace` extension). Your tool menu lists every available
+> tool at session start — pick the Calendar one.
 >
 > Only **Google Calendar** is integration-gated here. Apple Calendar,
 > Outlook Calendar, Obsidian, GitHub, scheduling, and Skills CRUD
@@ -46,65 +47,61 @@ provider-specific direct route (`/api/apple-calendar/*` or
 ---
 
 <!-- service:calendar -->
-## Google Calendar — google-workspace extension (native MCP)
+## Google Calendar — in-session connector
 
-Tool namespace: `mcp_google-workspace_calendar.`
+The exact tool names depend on which Calendar connector your harness
+has loaded. Inspect your tool menu at session start and pick the
+matching capability. Gemini CLI's `google-workspace` extension is the
+typical provider here; rely on the capability classes below rather
+than specific tool names.
 
-### Read-class tools
+### Read-class capabilities
 
-| Capability | Tool | Use |
-|---|---|---|
-| `list_events` | `listEvents` | Window-list events on a calendar. |
-| `get_event` | `getEvent` | Single-event read. |
-| `list_calendars` | `list` | Enumerate the user's calendars (the `primary: true` flag identifies the default). |
-| `find_free_time` | `findFreeTime` | Free-slot proposal — pure compute. |
-
-Canonical list call:
+| Capability | What to do |
+|---|---|
+| `list_events` | Window-list events on a calendar (`calendarId` + `timeMin` / `timeMax`). |
+| `get_event` | Single-event read by id. |
+| `list_calendars` | Enumerate the user's calendars (the `primary: true` flag identifies the default). |
+| `find_free_time` | Free-slot proposal — pure compute. |
 
-```
-mcp_google-workspace_calendar.listEvents(
-  calendarId="primary",
-  timeMin="<ISO-8601 with offset>",
-  timeMax="<ISO-8601 with offset>",
-  maxResults=50
-)
-```
+Canonical list flow: invoke your connector's list-events function with
+`calendarId="primary"`, `timeMin` / `timeMax` as ISO-8601 timestamps
+with TZ offset, and (if supported) `maxResults=50`.
 
-**Gemini-specific Calendar quirk** (carries over from delegated mode):
+**Gemini-specific Calendar quirks** (typical of the
+`google-workspace` extension; verify against your connector's actual
+behavior):
 
 | Quirk | Effect | Workaround |
 |---|---|---|
-| `maxResults` is silently ignored on `listEvents` | Result set bounded only by the time window + Google's default | Narrow the time window when the connector returns more than expected; do not assume the cap applies. |
+| `maxResults` silently ignored on list-events | Result set bounded only by the time window + connector default | Narrow the time window when the connector returns more than expected; do not assume the cap applies. |
 | Default `attendeeResponseStatus = ["accepted","tentative","needsAction"]` drops declined events | Declined meetings invisible | Pass `attendeeResponseStatus=["declined"]` or the full set explicitly when needed. |
 
-Canonical detail read (always GET-before-PATCH):
+Canonical detail read (always GET-before-PATCH): invoke the
+get-event function with `calendarId` and the `eventId` returned by
+list.
 
-```
-mcp_google-workspace_calendar.getEvent(
-  calendarId="primary",
-  eventId="<id>"
-)
-```
-
-### Destructive tools (require explicit user confirmation)
+### Destructive capabilities (require explicit user confirmation)
 
 Per the registry's
-`google_calendar.backendConnectors.gemini.destructiveTools`:
+`google_calendar.backendConnectors.gemini.destructiveTools`, the
+following capability classes are destructive in native:gemini mode:
 
-- `createEvent`
-- `updateEvent` — attendees whole-list replacement; see warning below.
-- `deleteEvent`
-- `respondToEvent` — dispatches RSVP.
+- **Create event** — adds a new event.
+- **Update event** — mutates an existing event (attendees whole-list
+  replacement; see warning below).
+- **Delete event** — removes the event.
+- **Respond to event** — dispatches an RSVP.
 
 Apply the destructive-confirm contract every time. The starter
 `deniedTools` list is enforced before the call lands.
 
-**ATTENDEES WARNING.** `updateEvent(attendees=[...])` replaces the
-list verbatim. To add one attendee:
+**ATTENDEES WARNING.** The update-event capability replaces the
+attendees array verbatim. To add one attendee:
 
-1. `getEvent(...)` → copy `attendees`.
+1. Read the event → copy `attendees`.
 2. Append the new attendee.
-3. `updateEvent(..., attendees=[<full list>])`.
+3. Update with the full attendees list.
 
 **Recurring events.** Single-instance edits require the instance id;
 master-id update shifts the whole series. Confirm scope.
@@ -112,7 +109,7 @@ master-id update shifts the whole series. Confirm scope.
 ### Time discipline
 
 ISO 8601 with TZ offset for timed events; `YYYY-MM-DD` for all-day.
-The extension rejects naked-ISO inputs.
+Connectors typically reject naked-ISO inputs.
 
 ### Imminent-event reminders (hourly_check)
 
@@ -194,26 +191,26 @@ from the session's integration state independently of Calendar.
 
 ## Persisting Calendar observations from native fetches
 
+**Batch when you have more than one event.** Use
+`POST /api/observations/batch` with up to 200 items in one
+`observations[]` array (see the `observations` skill for the envelope).
+The single-item form below is for the rare "one new event surfaced"
+case.
+
 ```bash
 curl -s -X POST http://localhost:8321/api/observations \
   -H 'Content-Type: application/json' \
   -d '{
-    "source": "google_calendar",
-    "type": "calendar:lifecycle",
+    "source": "google_calendar:<calendarId>",
     "ref": "<eventId>",
-    "actor": "user",
-    "receivedAt": "<ISO-8601 UTC>",
-    "summary_text": "<title — start..end>",
-    "refs": {
-      "eventId": "<id>",
-      "calendarId": "primary",
-      "windowKey": "primary:imminent"
-    },
-    "payload": <verbatim MCP event object>
+    "changeType": "created",
+    "actor": "agent",
+    "payload": <verbatim connector event object>
   }'
 ```
 
 The daemon computes `contentHash` server-side. Pass the raw `payload`.
+`actor` MUST be `"agent"` or `"system"` — the server rejects `"user"`.
 HTTP 409 indicates a mode-flip race window (§11.3.1); stop and re-read
 `<integration_modes>`.
 

package/agent-assets/skills/mail/SKILL.md

@@ -28,11 +28,11 @@ accordingly:
 <!-- mode:delegated-same:gmail -->
 - **Gmail when `gmail="delegated"` (same-backend):** the per-account
   gate returns `410 {"error": "integration_delegated"}`. Do NOT retry
-  via `/api/mail/*`. Use the connector tools your session already
-  holds natively — `mcp__claude_ai_Gmail__*` (Claude session),
-  `mcp__codex_apps__gmail._*` (Codex session), or
-  `mcp_google-workspace_gmail.*` (Gemini session, via the
-  `google-workspace` extension).
+  via `/api/mail/*`. Use the in-session Gmail connector your harness
+  exposes — your tool menu lists every available tool at session start.
+  The exact tool namespace depends on which Gmail connector your
+  harness has loaded (Claude / Codex / Gemini sessions each surface
+  Gmail under their own connector's namespace).
 <!-- /mode:delegated-same:gmail -->
 
 <!-- mode:delegated:outlook_mail -->