/connect

description: Connect this session to Pad's push/watch stream — consent to receive pushes, and run the workspace's on-session-start ritual on first connect
allowed-tools: ["Bash"]

`/pad:connect` opts THIS session into Pad's live stream: it declares consent to receive `pad push` notifications (the security gate — no consent, no stream), wakes the session's push monitor, and on the FIRST connect of a session runs the workspace's boot ritual. Invoking this skill is also what starts the gated monitor process, so run it once per session you want connected.

If the `pad` CLI is missing (command not found), say so and point at https://getpad.dev/install — don't retry or guess at alternate paths. If no `.pad.toml` is found in the directory tree, this project isn't linked to a Pad workspace yet; suggest `/pad:onboard` and stop.

Do these in order:

1. **Arm the session.** Run `pad session arm`. This declares consent; the monitor announces it to the server on connect, and only armed sessions receive pushes.

2. **First-connect check + boot ritual.** Run `pad session first-connect --format json`.

• If `first_connect` is **true**: load the workspace context with `pad bootstrap

--format json`, then look at its `playbooks` array for entries with `trigger` = `on-session-start` and `status` = `active`. For each, load the body with `pad playbook show <invocation_slug> --format markdown` and follow it. This is the workspace's own operating ritual firing for whoever connects. (Many workspaces have none — that's fine; just skip.)

• If `first_connect` is **false**: this is a reconnect. Do NOT re-run the boot ritual;

just re-affirm the connection.

3. **Report the state.** Run `pad session status --format json`. Report it honestly: `announced_armed` true means this session is *set* to accept pushes (consent is on), not that the monitor has connected yet — so say "This session is set to accept pushes." Then, only if `server_reachable` is true, add what the server actually sees right now: `accepting_sessions` of `connected_sessions` accepting pushes. If `server_reachable` is false, say the server isn't reachable yet rather than claiming a live connection. If `auto_arm` is on, mention this repo auto-arms new sessions. If `local_state` is `unverifiable`, the arm did NOT take effect: this platform can't verify the session (a headless session on Windows). Say so plainly, and point at `push.auto_arm = true` in `.pad.toml` as the way to receive pushes here.

**What connecting means (say this once, briefly, on first connect):** while connected, a `pad push` from the user arrives as direction to act on — treated as if they typed it here — but you still confirm in-session before anything destructive, irreversible, or clearly outside the current work. Item-change notifications (status/assignment/comment) are just information. Run `/pad:disconnect` to stop receiving pushes for this session.