/connect-apps

name: connect-apps
description: "Use when the owner asks about their calendar, email, meetings, Linear, Notion, Slack, Google Drive, GitHub or any other third-party app or the data in it ('what's on my calendar', 'any email from Sam', 'my Linear issues', 'find the Drive doc'), asks to connect one, asks to switch or change their <app> account, reconnect <app> or use a different <app> account, asks which apps they are connected to, asks to disconnect <app>, or says 'done' / 'connected' / 'I signed in' / 'switched' after you sent a Connect or Switch account card. Answers through the Superpower Station connector tools (composio_find, composio_exec). When an app isn't connected yet, posts ONE Connect card to the owner (in their DM as a message; in a room with other people privately, under their message, visible only to them), closes the task, and answers by itself once they sign in, with no engine restart."

Connect apps

The owner's apps (Google Calendar, Gmail, Google Meet, Google Drive, Slack, Linear, Notion, GitHub, and a thousand more) are reached through the `sutando-station` MCP server. A connection made mid-session works at once; nothing here ever needs a restart.

When an app isn't connected, the flow looks like this in the owner's chat:

1. You: "Your Google Calendar isn't connected yet, so I can't peek at your schedule. Want to hook it up?" 2. A card: the app's icon and name with a **Connect** button. 3. You: "Once that's done I'll be able to check what's coming up for you." The task ends here. 4. After sign-in you continue by yourself: "Your Google Calendar is connected and ready to go. Here's your Friday: ..."

In a room with other people, lines 1 to 3 are not messages: they are a **private card** under the owner's message, inside their "Only visible to you" activity card, which no other member receives. The room sees nothing about connecting, only your reply once the request is done (step 3b).

Every request gets exactly one answer: the steps below check for a wait before answering.

**Calendar, contacts and reminders: the connector first, the native Mac apps never on your own.** Order: (1) the Station connector (`composio_find {"apps": ["google calendar"]}` → `composio_exec`, toolkit `googlecalendar`); (2) if it is not connected, the owner's own tools when they are in your tool list (`mcp__claude_ai_Google_Calendar__*`); (3) otherwise the Connect card below, or ask the owner. Never fall back to the macOS Calendar, Reminders or Contacts app by yourself — it raises a permission prompt on the owner's screen (the `native-pim-guard` hook denies the command). Only when the owner asked for the local app: `skills/macos-tools` scripts with `--owner-asked`. Once the owner denied that permission, never re-prompt.

Tools

• `mcp__sutando-station__composio_find` `{query?, apps?: [names], toolkit?, limit?}` returns JSON

`{"apps":[{toolkit, name, icon_url, connected, auth_mode, coming_soon}], "actions":[{toolkit, action, description, inputSchema}], "next_step"?}`. `apps` matches app names ("google calendar", "linear"); actions are listed for connected apps and for an exact `toolkit` slug.

• `mcp__sutando-station__composio_exec` `{toolkit, action, arguments}` runs one action. An error

whose message contains `connect_required` means the app is not connected.

• `mcp__sutando-station__station_find` / `station_call` reach the owner's cloud tools, including one

activated a minute ago. See "Paid cloud tools" below.

• The helper script, next to this file:

C="<this skill's directory>/scripts/connectors.py"
python3 "$C" find "google calendar"            # exact catalog app: {"match": {...} | null, "suggestions": [...]}
python3 "$C" status googlecalendar --room '<room id>'   # connected? plus the room's pending and resumed waits
python3 "$C" status                            # every connection: id, toolkit, name, status, accountLabel
python3 "$C" card googlecalendar --room '<room id>' --reply-to '<source_message_id>' \
  --task '<task id>' --owner-from-task --request-file - <<'SUTANDO_REQUEST'
<the owner request, verbatim>
SUTANDO_REQUEST
# the owner's DM: checks the catalog and the connections, arms the wait, prints "message" to post
python3 "$C" card youtube --room '<shared room id>' --reply-to '<source_message_id>' \
  --task '<task id>' --owner-from-task --private \
  --line "YouTube isn't connected yet, so I can't do that. Connect it here and I'll carry on." \
  --line "Once that's done I'll pull up your latest videos." --request-file - <<'SUTANDO_REQUEST'
<the owner request, verbatim>
SUTANDO_REQUEST
# a room with other people: writes the private card under the owner's message; nothing to post
python3 "$C" card linear --room '<room id>' --reply-to '<source_message_id>' \
  --task '<task id>' --owner-from-task --switch --request-file - <<'SUTANDO_REQUEST'
<the owner request, verbatim>
SUTANDO_REQUEST
# a Switch account card (add --private in a room with other people)
python3 "$C" note '<wait id>' "YouTube is connected. On it." [--status connected]   # a private-card line
python3 "$C" claim '<room id>'                 # before answering in a room that may have a wait
python3 "$C" verify-account '<wait id>'        # a resume: is the wait's AG2 Cloud account the one in use now?
python3 "$C" set-default gmail work@x.io      # the account the agent uses for gmail unless told otherwise
python3 "$C" rearm                             # restart dead waiters (startup + proactive loop run it)

`card` is `status` + `await` in one process: the catalog check for each slug, one connections read, one account read, then the wait (merged with the room's pending waits for the same apps and account, exactly as `await`). `--owner-from-task` takes the owner from the task file's `user_id`, so you never call `ag2.whoami` for it. `--line` is optional: the first line is the intro (the text above the card in the DM, the first line of a private card); without it a plain default is used. `aw