/oncall-init

name: oncall-init
description: >-
  Set up Claude Tag for oncall for a team, from that team's standing (public) oncall / monitoring channel. Two
  things: it sets the channel up for monitoring, so alerts and incident posts here (from a person or another
  Slack bot) get triaged and acted on automatically, and it finds and sets up the connectors, plugins and skills
  Claude uses for oncall. A workspace can have several such channels; run once in each, by anyone, and every run
  adds or updates that team's section in the one oncall memory in shared workspace memory. Use on "set up
  oncall", "init oncall", "configure Claude for on-call". Surveys the agent connectors an admin configured for
  Claude, proves one with a read-only pull so access is verified, explores tools, Slack, repos and docs to learn
  how oncall works here, then recommends what's missing and walks the team through setup. The result goes into
  the indexed oncall memory every channel reuses; the other skills (incident init, investigation, handoff) pick
  it up automatically.

Oncall init (per team, one oncall memory)

This sets up Claude Tag for oncall for the team whose monitoring channel it was asked in, and saves the result where the whole Slack workspace can use it. Anyone can run it. A workspace usually has several oncall / monitoring channels, one per team or rotation. Running this in each of them appends that team's section (its alert and incident channels, rotation, process, available connectors) to the same single oncall memory the whole workspace shares. It never overwrites another team's section. Running it again in the same channel merges into that team's section instead of starting over, and records who ran it when.

**Where this runs.** Two kinds of channels matter, and the user should hear this in plain words during setup and at the close ("Run me in your team's oncall or monitoring channel. Other teams do the same in theirs, and what I save is reused automatically in every incident channel."):

• **Oncall / monitoring channels**: a team's standing channel where alerts

land and the rotation talks day to day (`#payments-oncall`, `#db-alerts`). Run this init from each one that wants it. Besides its section in the oncall memory, the monitoring channel gets a short note of its own (team and rotation, which bots post here, how loud to be) in its memory.

• **Incident / alert channels**: short-lived channels opened per incident,

or a shared alerts feed (`#inc-…`). Nothing is set up there by hand; when Claude lands in one, `incident-init` reads the oncall memory and picks the section for the team the incident belongs to. `incident-investigate` works mainly there (and in the monitoring channel, in an alert's thread); `oncall-handoff` runs mainly in the monitoring channel, usually on a schedule. Both read the oncall memory the same way.

Before you start

• Read the shared workspace memory index and look for an existing oncall

entry, whatever it is named. If one exists, open it and look for a section for this team or this channel. Section found: this is a re-run; say "Updating the <team> oncall setup (last run <date> by <@U…>)" and edit that section in place at the end. Oncall memory found but no section for this team: say "Adding <team> to the existing oncall setup (other teams already there: <names>)" and append a new section at the end; leave every other team's section exactly as it is. Either way reuse the same file and its existing index line. Never create a second oncall memory or a second index line.

• **Skip what is already set up.** Most of this setup is workspace-wide: the

connectors, the repos, the paging and monitoring tools. If the oncall memory already records them (this requester ran setup in another channel, or another team did and the same tools serve both), do not walk anyone through them again. Say in one line what is already set up and where it came from, list only the items still open, and go straight to the channel-local part: which bots post here, how loud to be here, this channel's team and rotation, and its own note. One part is never skipped: connector availability. On every run, refresh included, redo step 1's inventory (the agent connectors and the agent's own tools) and exercise the read-only proving pull again rather than trusting the recorded table — connectors change between runs. Update the recorded table with what you find. The standing-instructions scan is never skipped either: on a re-run, check the recorded runbook docs and repos for standing instructions, and if you find some with no import decision recorded, ask step 2's one import question.

• If this is a private channel, workspace memory is read-only from here. Say

so in one line and ask them to run this from any public channel. Stop.

• If this channel looks like a per-incident channel rather than a monitoring

channel, say in one line that init is best run from the team's standing oncall / monitoring channel, then continue anyway (the oncall memory is the same either way; only the channel note is skipped).

• Keep every conversational Slack reply short: six lines or fewer, plain

sentences, no em dashes, no walls of text — the quoted templates and message formats in these steps are exempt and used as written, the closing message in step 6 (one bullet per behavior, pinned) included. Put a blank line between paragraphs and around lists: Slack collapses a single newline, so lines split only by one newline post as one fused paragraph.

• Keep every message this setup posts short; the formats in these steps are

upper bounds, not templates to fill, so drop any line you have nothing real for.

• Show, don't tell. Whenever you report something during setup, show the

real thing you found (the actual channels, bots, tools, people, numbers; a chart via the built-in `dataviz` skill when a trend says it better, e.g. pages per day) instea