oncall-init

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 oncall setup (last run by <@U…>)" and edit that section in place at the end. Oncall memory found but no section for this team: say "Adding to the existing oncall setup (other teams already there: )" 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) instead of describing what you could do. Name the source next to each number so someone can check it.
• Stay at the altitude a reader can act on. Raw evidence (HTTP status codes, monitor ids, channel counts, per-search results) belongs in the oncall memory and in your own reasoning, not in the Slack messages. In Slack, say what works, what doesn't, and what to do about it.