[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M718HE63YJFD1DJ2K53C66TW":3,"skill-same:01M718HE63YJFD1DJ2K53C66TW":66},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":6,"updatedAt":51,"install":52,"resources":65},"01M718HE63YJFD1DJ2K53C66TW","oncall-setup",null,"Bootstrap a Claude-assisted on-call for this channel\u002Frepo: discover the available connectors, mine incident history into draft triage playbooks, interview the human for policy, validate against held-out incidents, and install the scheduled routines. Use when the user wants to \"set up on-call\", \"bootstrap the on-call kit\", \"onboard this channel\", or has just installed the oncall-kit plugin. Five gated phases — never run more than one phase per turn, and never activate anything before Phase 4 sign-off.","anthropics\u002Foncall-kit","anthropics","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F76263028?v=4","01M697XGDPXJAVQ8391V2BCYTE","Anthropic","01M718HAM88APBE3NK565F2XWJ",273,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit\u002Fblob\u002Fmain\u002Fskills\u002Foncall-setup\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"oncall","setup","oncall setup","kit","more","call","routines","up","incidents","policy","incident","repo","just","for","discover","history","never","mine","interview","SET","2026-11-10 10:12:30",false,"---\nname: oncall-setup\ndescription: >\n  Bootstrap a Claude-assisted on-call for this channel\u002Frepo: discover the\n  available connectors, mine incident history into draft triage playbooks,\n  interview the human for policy, validate against held-out incidents, and\n  install the scheduled routines. Use when the user wants to \"set up on-call\",\n  \"bootstrap the on-call kit\", \"onboard this channel\", or has just installed\n  the oncall-kit plugin. Five gated phases — never run more than one phase\n  per turn, and never activate anything before Phase 4 sign-off.\n---\n\n\u003C!-- Copyright 2026 Anthropic PBC -->\n\u003C!-- SPDX-License-Identifier: Apache-2.0 -->\n\n# On-call setup (five gated phases)\n\nYou are bootstrapping the on-call kit for this team. The kit's `README.md`\ndefines the target state; `CLAUDE.md` defines your standing rules — read both\nbefore acting. Rules 13–15 (gates, provenance, thresholds) govern everything\nbelow.\n\nDetermine which phase you're in by what exists on disk:\n\n| If | Phase |\n|---|---|\n| No `STACK.md` | 0 — Discover |\n| `STACK.md` exists, no draft references | 1 — Mine |\n| Drafts exist, `ONCALL.md` has unfilled `{{...}}` policy blanks | 2 — Interview |\n| `ONCALL.md` complete, no `eval\u002Freplay-results.md` | 3 — Validate |\n| Replay passed, routines not yet installed | 4 — Install |\n\n**Open every phase with the same four-line briefing — it is the FIRST text\nof the phase's first reply, before any tool call, every phase including\nPhase 0:**\n\n> **Phase N of 5 — {{name}}.** What happens: {{one sentence}}. Takes about:\n> {{estimate — Discover ~10 min · Mine ~30–60 min of my work + ~20 min of\n> your review · Interview ~15 min of questions · Validate ~30 min ·\n> Install ~15 min of you pasting routines}}. What changes: {{the files\n> written \u002F nothing outside this repo \u002F routines go live}}. At the end I'll\n> stop and ask you to: {{what the gate will ask}}.\n\nIf this is the user's first phase this session, also show the one-line map\nof all five phases so they know where they are. Then run the phase, deliver\nits output, STOP at the gate.\n\n## Phase 0 — Discover\n\nGoal: bind capabilities to whatever is actually connected, without naming\nvendors anywhere else in the kit.\n\n0. **Determine the surface.** Are you running in the Slack channel (as the\n   channel's Claude) or in a local Claude Code session in the repo? Note it\n   in `STACK.md`. Phases 0–3 work from either; **Phase 4 requires the\n   channel**. If you're local, tell the user now what Phase 4 will need so\n   it isn't a surprise: `@Claude` invited to the on-call channel (and each\n   alert channel to watch), and an Owner adding this repo to the channel's\n   access bundle. Point them at `TAG-SETUP.md` — it separates what they can\n   do themselves from what needs their Claude org Owner, and contains a\n   paste-ready request message with the blanks to fill from this repo's\n   context. Offer to fill those blanks for them now. Record \"channel\n   connectivity: unverified\" as a Gap.\n\n1. Enumerate every tool\u002Fconnection available in this session (in a channel:\n   also ask yourself \"what can I access from this channel?\" and list the MCP\n   tools present).\n2. For each, probe **read-only**: list one dashboard, run one trivial log\n   query, list the last 5 pages\u002Fincidents, read the repo's CODEOWNERS. Record\n   what worked, what 403'd, what doesn't exist.\n3. Classify each connection into the kit's capability slots:\n   - `metrics` — dashboards \u002F time-series (error rates, latency, queue depth)\n   - `logs` — searchable log store\n   - `pager` — paging + incident history\n   - `code` — repo host: PRs, diffs, CODEOWNERS, deploy history\n   - `alert-channels` — Slack channels where alerts and incident chatter land\n   - `incidents` — where incident records live: threads in the on-call\n     channel (the zero-infrastructure default), per-incident channels if\n     the team's incident tooling provisions them, pager incident objects,\n     or tickets. Ask the human how an incident is *declared* today and bind\n     to that — never invent a new incident process during setup.\n   - `deploys` — deploy\u002Frelease feed, if separate from `code`\n4. Write `STACK.md` from `templates\u002FSTACK.md`: one line per capability →\n   concrete connection, plus the probe result and any gaps (\"no pager\n   connected — paging phase of routines will be skipped\").\n\n**Gate:** post the capability map. Ask the human, explicitly and numbered:\n(1) confirm or correct each binding; (2) name any alert channels you\ncouldn't discover; (3) how is an incident DECLARED on this team today —\nthread convention, per-incident channel, pager object, ticket? (This\nquestion is mandatory even if the `incidents` bullet was answered — a\nguessed declaration convention poisons everything downstream.) Do not\nproceed.\n\n## Phase 1 — Mine\n\nGoal: draft the triage playbooks from the team's own history instead of a\nblank page.\n\n0. **Agree the scope before reading anything.** The window question is also\n   the consent question — ask it in one message that names exactly what\n   you'll read:\n\n   > I'll mine resolved incidents to draft your playbooks. That means\n   > reading, over the window you pick: your pager's incident history, the\n   > incident threads and alert traffic in {{the bound channels, named}},\n   > and any postmortem docs you point me at. I extract investigation\n   > steps and root causes — symptoms, queries, fixes. I won't quote\n   > individuals or read channels beyond those named. How far back — 30,\n   > 60, or 90 days? And is there anything to exclude (a channel, a\n   > specific incident, a time range)?\n\n   Honor exclusions absolutely, and if history retrieval comes up short of\n   the agreed window (search depth, retention), say what you actually\n   covered — never silently mine less than agreed.\n\n1. **Collect.** Pull the resolved incidents from the agreed sources only. For each: the triggering alert,\n   the thread, who responded, what they checked (queries, dashboards,\n   commands visible in the thread), the stated root cause, the fix, time to\n   resolution.\n2. **Cluster into failure classes.** Aim for 3–7 classes that cover ≥80% of\n   incidents; everything else goes in an `uncategorized` list, not a forced\n   class. Name classes by symptom, not by root cause (\"merge queue stalled\",\n   not \"the Redis bug\").\n3. **Draft one reference file per class** using the structure in\n   `skills\u002Ftriage\u002Freferences\u002Ftest-failures.md` (the worked example):\n   symptoms, first checks (the queries humans actually ran, generalized),\n   a correlation table of \"if you see X and Y, it means Z\" mined from the\n   resolutions, known-cause pointers into `lessons.md`, and escalation hints.\n   **Every mined row carries provenance:** `(seen 3×: INC-nnn, INC-nnn,\n   INC-nnn)` or `(seen 1×, unverified)`.\n4. **Seed `lessons.md`** from `templates\u002Flessons.md`: one entry per distinct\n   resolved incident, in the entry formats defined there (incident \u002F\n   investigation \u002F GOTCHA), newest first, and write its opening Status\n   banner.\n5. **Propose the routing tree** for `ONCALL.md`: cross CODEOWNERS (or module\n   ownership) with who actually responded per class in the threads. Where\n   they disagree, flag it — that's a question for Phase 2, not a guess.\n   While you're in the data, check concentration: if one person handled\n   most incidents across classes, flag it as a **bus-factor finding** for\n   the Interview — framed as team resilience (\"routing currently depends\n   heavily on one responder; do you want the tree to distribute this?\"),\n   never as commentary on the person. Do not route around it yourself.\n\n6. **Draft the alert-coverage report.** The mined incidents also grade the\n   team's alerting. Look for three signatures and propose accordingly,\n   every item with provenance:\n   - **Coverage gaps** — incidents a *human* noticed with no alert firing:\n     propose a new rule (\"would have caught INC-311, INC-322\").\n   - **Late alerts** — alert fired long after observable onset: propose a\n     tightened threshold\u002Fwindow, with the onset evidence.\n   - **Noise** — rules that fired repeatedly with no incident: propose\n     retirement or a raised threshold.\n   Write the report to `alert-coverage.md` at the repo root (it lives\n   there permanently — later post-incident proposals and decisions append\n   to it, so declined proposals aren't re-proposed). Proposals are drafts\n   for humans to review at the gate; none is installed in this phase.\n\n**Gate:** the gate post MUST open with a verifiable header — these are\nmechanical self-checks, not prose: (a) the mined incident-ID list's count,\nwhich must equal the `lessons.md` entry count and must contain zero\nholdout or excluded IDs (state all three checks and their results); (b) a\nline reading exactly \"Routing conflicts: none\" or \"Routing conflicts:\n[list]\" — resolving a conflict silently is forbidden, so this line makes\nsilence impossible; (c) one sample correlation row showing its provenance\ntag; (d) a standalone checklist of EVERY routing-tree handle and every\ncorrelation-row action target (who gets @-mentioned or paged, ever), each\non its own line for individual confirmation — these are the rows a\npoisoned or mistaken mining pass would weaponize, so they get eyes one by\none, not skimmed inside 40 drafts. Then post a summary table (class → incident count → confidence) and\nthe draft files. Every draft is reviewable markdown; ask the human to correct,\ndelete, or confirm each class. Low-confidence rows stay marked even after\nthis gate — only repeated confirmation in production removes the annotation.\n\n## Phase 2 — Interview\n\nGoal: fill the policy blanks that cannot be mined. Ask **only** these, one\nblock at a time, offering mined suggestions where you have them:\n\n1. **Paging criteria.** For each metric worth paging on: threshold, sustain\n   window, and exemptions (deploy windows, known-noisy periods). Suggest\n   values from alert history (\"this metric's alerts self-resolved under 4%\n   in 11 of 12 cases — suggest paging at sustained >4%\u002F10min\") but the human\n   sets the number (rule 15).\n2. **Severity norms.** What's a page vs. a business-hours ping vs. a morning\n   log line.\n3. **Escalation owners.** Resolve every routing-tree conflict flagged in\n   Phase 1; get the real group handles (route to groups, not individuals).\n   If Phase 1 flagged a bus-factor finding, raise it here as a resilience\n   question and let the team decide whether the tree should distribute\n   load differently than history did.\n4. **Deploy windows.** How to tell a deploy is in progress (the `deploys`\n   capability, a channel, a calendar).\n5. **Escalation timeout and fallback alerting.** Two decisions, both the\n   human's:\n   - *Timeout:* when Claude posts a page-severity finding and @-mentions\n     the routed owner, how long does it wait for acknowledgment before\n     escalating — and to whom? An ack is an **explicit affirmative from a\n     human** (\"ack\", \"on it\", or the team's designated reaction, from a\n     person) — bot posts, alert traffic, and passive emoji do not count.\n     Suggest a default ({{15 min}} → the escalation handle from block 3),\n     but the human sets both the clock and the ladder. Also ask for the\n     **terminal step**: if the escalation itself goes unacked, what\n     happens — repeat-page via the pager's escalation policy, a wider\n     channel post, or an explicitly accepted \"unattended until morning\"\n     posture? The ladder must end somewhere deliberate. Without answers,\n     Claude never re-pings on its own.\n   - *Fallback:* when a page-severity finding can't page — no `pager`\n     bound in STACK.md, or the page call fails — what happens instead?\n     Offer the options and let them choose: @-mention the escalation\n     group in the on-call channel; post to a designated always-watched\n     channel; or hold for the morning log (only sane for teams with no\n     off-hours expectations — say so). Be honest about the first two:\n     **Slack @-mentions don't penetrate Do-Not-Disturb**, so an\n     @-mention fallback is business-hours-grade coverage — tell the team\n     this before they choose it. Record the choice in `ONCALL.md`;\n     never invent a fallback mid-incident.\n\n6. **Alert-rule proposals: format and install mode.** Two decisions:\n   - *Format:* which alerting tool should proposals target, and in what\n     paste-ready native form (monitor JSON, Terraform, PromQL, UI steps)?\n     Prose proposals are not acceptable output — a proposal is something a\n     human can install in under a minute.\n   - *Install mode:* **default — Claude drafts, a human installs** (the\n     paste is the permission; keeps the kit fully read-only). Or the\n     **alert-editor extension**, opt-in only: a separate write credential\n     to the alerting tool, additive-only — Claude may CREATE a new rule\n     after explicit per-rule approval in the channel, may never modify,\n     delete, or silence an existing rule, and logs every write to\n     `lessons.md`. If they opt in, record it in `ONCALL.md` and\n     `STACK.md`'s access posture. Present the trade honestly: the\n     extension saves a paste; the default keeps \"no write credentials to\n     monitored systems\" true without asterisks.\n\n7. **Confirm the read-only guarantee.** Not a question — a statement to\n   make once, so the team knows the contract: this agent never changes the\n   state of any monitored system; its only outputs are messages, log\n   entries, proposed PRs, and pages. There is no allowlist to configure.\n   Teams that want automated mitigation are outside this kit's scope and\n   should design that separately, on an accountable human identity.\n\n8. **Lifecycle windows and standing reports.** Three decisions, all\n   human-set numbers (rule 15):\n   - *Staleness\u002Fzombie windows:* how long an open incident stays quiet\n     before a \"looks stale\" nudge ({{24h}} suggested) and before the\n     handoff's zombie list ({{72h}} suggested) — these gate what Claude\n     *says*, never what it changes.\n   - *Morning sitrep:* on or off, what time, and confirm the \"post\n     nothing when empty\" behavior.\n   - *Weather report:* opt in or skip — show the cost anchor from\n     `templates\u002Froutines.md` and the cadence-guard design before they\n     choose. Skipping is the default and completely fine (status stays\n     on-demand). If they opt in, three things go into `ONCALL.md`: the\n     cadence targets, the report-page binding, and the mood\n     tier-boundary table (the two base signals and the human-set\n     boundaries mapping each to sunny\u002Fpartly_cloudy\u002Fovercast\u002Fstormy —\n     the weather skill refuses to run without it).\n\nWrite the answers into `ONCALL.md` from `templates\u002FONCALL.md`, replacing\nevery `{{...}}`. Template fields no block covered (e.g. handoff cadence,\nstatus-on-demand signals): fill with a sensible default, mark each\n`(proposed)`, and list them explicitly at the gate for confirmation —\nnever leave blanks, never present a default as the user's decision.\n\n**Gate:** post the completed `ONCALL.md` diff. The human signs off the\npolicy. Do not proceed.\n\n## Phase 3 — Validate\n\nGoal: prove the drafted playbooks against incidents they weren't built from.\n\n1. Hold out 5–10 resolved incidents **not used** in Phase 1 (or the most\n   recent ones if history is thin — say so). Span the failure classes and\n   include page-severity incidents where they exist; if none exist, the\n   results file states the paging dimension is untested.\n2. For each: take only the triggering alert\u002Ffirst message, run the `triage`\n   skill as if live (read-only), and produce the diagnosis you would have\n   posted. For long-running holdouts, also produce the >30-min update —\n   graded against triage step 6a's story-so-far spec, not just the\n   diagnosis.\n3. Grade **in a fresh context** (a separate session\u002Fsubagent that didn't\n   produce the diagnoses, prompted skeptically; human confirms), per\n   `eval\u002Freplay.md`: ✅ correct \u002F ⚠️ partially correct \u002F ❌ wrong \u002F\n   🚫 harmful (would have misdirected mitigation or paged wrongly).\n4. Write `eval\u002Freplay-results.md`: the table, per-incident links, and for\n   every ❌\u002F🚫 the playbook change that would have prevented it, as a\n   proposed diff.\n\n**Gate:** pass = ≥70% ✅+⚠️ **and zero 🚫**. Present the percentage as a\nsmoke test, not statistics — with 5–10 holdouts one grade swings ~14\npoints. The real content of this gate is the per-incident review of every\n❌\u002F🚫 and its proposed diff; the real quantitative gate is the shadow\nperiod, where evidence actually accumulates. On pass, ask to\nproceed. On fail, apply the proposed playbook diffs (with human review)\nand re-run with fresh holdouts; a thin-history team that exhausts its\nholdouts goes to shadow with the alert-watch routine in review-only mode\nrather than re-testing on incidents the playbooks have now seen. Never\nlower the bar.\n\n## Phase 4 — Install\n\nGoal: turn it on, narrowest first.\n\n0. **Verify channel connectivity before anything else.** This phase only\n   works from the Slack channel. The checklist, done by the human:\n   `\u002Finvite @Claude` to the on-call channel and each alert channel to be\n   watched; an Owner adds this repo to the channel's access bundle. Then\n   the proof: **from the channel**, ask `@Claude what can you access from\n   this channel?` and have it read `ONCALL.md` back. If it can't read the\n   repo, stop — pasting routines against a repo the channel can't reach\n   fails silently. Clear the \"channel connectivity: unverified\" gap in\n   `STACK.md` once this passes.\n\n1. Generate the routine messages from `templates\u002Froutines.md`, with real\n   channel names, cadences, and `STACK.md` bindings filled in. Order:\n   handoff (read-only) → morning sitrep (read-only, if chosen) → alert\n   investigation (posts diagnoses) → weather (opt-in, event-gated, if\n   chosen in Interview block 8). There is\n   no detection routine to install — detection stays in the team's\n   deterministic alerting; if a service is launching without alerts,\n   propose starter rules per templates\u002Froutines.md instead.\n2. Recommend the shadow period for the alert-watch routine (the handoff is\n   a read-only weekly report and goes live immediately). Shadow exits on\n   **evidence, not the calendar**: diagnoses post to a review\n   channel\u002Fthread and are graded daily, and promotion to live follows the\n   shadow-exit bar in `eval\u002Freplay.md` — the canonical source, which also\n   covers the quiet-channel case (too few alerts means extend, not\n   promote).\n2a. **Create the routine registry.** After the pastes, create (or update) a\n   channel canvas — or a pinned message where canvases aren't available —\n   titled \"Standing work in this channel\": every routine's name, schedule,\n   one-line purpose, live-or-shadow status, and last-changed date, plus\n   one closing line (\"to change when\u002Fwhere, edit the routine here; to\n   change how\u002Fpolicy, PR {{repo}}\"). Humans install routines; you keep\n   this registry current whenever standing work changes, so what's\n   running is legible at a glance to anyone who joins the channel.\n3. The human pastes each routine into the channel (routines belong to the\n   channel and its members — you don't install standing work for a team\n   without them seeing exactly what it says).\n\n**Gate (final):** confirm each routine the human installed by listing the\nchannel's standing work back. Remind them: to change *when\u002Fwhere*, edit the\nroutine in-channel; to change *how\u002Fpolicy*, PR the repo. Setup complete.\n","\u003C!-- Copyright 2026 Anthropic PBC -->\n\u003C!-- SPDX-License-Identifier: Apache-2.0 -->\n\n# On-call setup (five gated phases)\n\nYou are bootstrapping the on-call kit for this team. The kit's `README.md`\ndefines the target state; `CLAUDE.md` defines your standing rules — read both\nbefore acting. Rules 13–15 (gates, provenance, thresholds) govern everything\nbelow.\n\nDetermine which phase you're in by what exists on disk:\n\n| If | Phase |\n|---|---|\n| No `STACK.md` | 0 — Discover |\n| `STACK.md` exists, no draft references | 1 — Mine |\n| Drafts exist, `ONCALL.md` has unfilled `{{...}}` policy blanks | 2 — Interview |\n| `ONCALL.md` complete, no `eval\u002Freplay-results.md` | 3 — Validate |\n| Replay passed, routines not yet installed | 4 — Install |\n\n**Open every phase with the same four-line briefing — it is the FIRST text\nof the phase's first reply, before any tool call, every phase including\nPhase 0:**\n\n> **Phase N of 5 — {{name}}.** What happens: {{one sentence}}. Takes about:\n> {{estimate — Discover ~10 min · Mine ~30–60 min of my work + ~20 min of\n> your review · Interview ~15 min of questions · Validate ~30 min ·\n> Install ~15 min of you pasting routines}}. What changes: {{the files\n> written \u002F nothing outside this repo \u002F routines go live}}. At the end I'll\n> stop and ask you to: {{what the gate will ask}}.\n\nIf this is the user's first phase this session, also show the one-line map\nof all five phases so they know where they are. Then run the phase, deliver\nits output, STOP at the gate.\n\n## Phase 0 — Discover\n\nGoal: bind capabilities to whatever is actually connected, without naming\nvendors anywhere else in the kit.\n\n0. **Determine the surface.** Are you running in the Slack channel (as the\n   channel's Claude) or in a local Claude Code session in the repo? Note it\n   in `STACK.md`. Phases 0–3 work from either; **Phase 4 requires the\n   channel**. If you're local, tell the user now what Phase 4 will need so\n   it isn't a surprise: `@Claude` invited to the on-call channel (and each\n   alert channel to watch), and an Owner adding this repo to the channel's\n   access bundle. Point them at `TAG-SETUP.md` — it separates what they can\n   do themselves from what needs their Claude org Owner, and contains a\n   paste-ready request message with the blanks to fill from this repo's\n   context. Offer to fill those blanks for them now. Record \"channel\n   connectivity: unverified\" as a Gap.\n\n1. Enumerate every tool\u002Fconnection available in this session (in a channel:\n   also ask yourself \"what can I access from this channel?\" and list the MCP\n   tools present).\n2. For each, probe **read-only**: list one dashboard, run one trivial log\n   query, list the last 5 pages\u002Fincidents, read the repo's CODEOWNERS. Record\n   what worked, what 403'd, what doesn't exist.\n3. Classify each connection into the kit's capability slots:\n   - `metrics` — dashboards \u002F time-series (error rates, latency, queue depth)\n   - `logs` — searchable log store\n   - `pager` — paging + incident history\n   - `code` — repo host: PRs, diffs, CODEOWNERS, deploy history\n   - `alert-channels` — Slack channels where alerts and incident chatter land\n   - `incidents` — where incident records live: threads in the on-call\n     channel (the zero-infrastructure default), per-incident channels if\n     the team's incident tooling provisions them, pager incident objects,\n     or tickets. Ask the human how an incident is *declared* today and bind\n     to that — never invent a new incident process during setup.\n   - `deploys` — deploy\u002Frelease feed, if separate from `code`\n4. Write `STACK.md` from `templates\u002FSTACK.md`: one line per capability →\n   concrete connection, plus the probe result and any gaps (\"no pager\n   connected — paging phase of routines will be skipped\").\n\n**Gate:** post the capability map. Ask the human, explicitly and numbered:\n(1) confirm or correct each binding; (2) name any alert channels you\ncouldn't discover; (3) how is an incident DECLARED on this team today —\nthread convention, per-incident channel, pager object, ticket? (This\nquestion is mandatory even if the `incidents` bullet was answered — a\nguessed declaration convention poisons everything downstream.) Do not\nproceed.\n\n## Phase 1 — Mine\n\nGoal: draft the triage playbooks from the team's own history instead of a\nblank page.\n\n0. **Agree the scope before reading anything.** The window question is also\n   the consent question — ask it in one message that names exactly what\n   you'll read:\n\n   > I'll mine resolved incidents to draft your playbooks. That means\n   > reading, over the window you pick: your pager's incident history, the\n   > incident threads and alert traffic in {{the bound channels, named}},\n   > and any postmortem docs you point me at. I extract investigation\n   > steps and root causes — symptoms, queries, fixes. I won't quote\n   > individuals or read channels beyond those named. How far back — 30,\n   > 60, or 90 days? And is there anything to exclude (a channel, a\n   > specific incident, a time range)?\n\n   Honor exclusions absolutely, and if history retrieval comes up short of\n   the agreed window (search depth, retention), say what you actually\n   covered — never silently mine less than agreed.\n\n1. **Collect.** Pull the resolved incidents from the agreed sources only. For each: the triggering alert,\n   the thread, who responded, what they checked (queries, dashboards,\n   commands visible in the thread), the stated root cause, the fix, time to\n   resolution.\n2. **Cluster into failure classes.** Aim for 3–7 classes that cover ≥80% of\n   incidents; everything else goes in an `uncategorized` list, not a forced\n   class. Name classes by symptom, not by root cause (\"merge queue stalled\",\n   not \"the Redis bug\").\n3. **Draft one reference file per class** using the structure in\n   `skills\u002Ftriage\u002Freferences\u002Ftest-failures.md` (the worked example):\n   symptoms, first checks (the queries humans actually ran, generalized),\n   a correlation table of \"if you see X and Y, it means Z\" mined from the\n   resolutions, known-cause pointers into `lessons.md`, and escalation hints.\n   **Every mined row carries provenance:** `(seen 3×: INC-nnn, INC-nnn,\n   INC-nnn)` or `(seen 1×, unverified)`.\n4. **Seed `lessons.md`** from `templates\u002Flessons.md`: one entry per distinct\n   resolved incident, in the entry formats defined there (incident \u002F\n   investigation \u002F GOTCHA), newest first, and write its opening Status\n   banner.\n5. **Propose the routing tree** for `ONCALL.md`: cross CODEOWNERS (or module\n   ownership) with who actually responded per class in the threads. Where\n   they disagree, flag it — that's a question for Phase 2, not a guess.\n   While you're in the data, check concentration: if one person handled\n   most incidents across classes, flag it as a **bus-factor finding** for\n   the Interview — framed as team resilience (\"routing currently depends\n   heavily on one responder; do you want the tree to distribute this?\"),\n   never as commentary on the person. Do not route around it yourself.\n\n6. **Draft the alert-coverage report.** The mined incidents also grade the\n   team's alerting. Look for three signatures and propose accordingly,\n   every item with provenance:\n   - **Coverage gaps** — incidents a *human* noticed with no alert firing:\n     propose a new rule (\"would have caught INC-311, INC-322\").\n   - **Late alerts** — alert fired long after observable onset: propose a\n     tightened threshold\u002Fwindow, with the onset evidence.\n   - **Noise** — rules that fired repeatedly with no incident: propose\n     retirement or a raised threshold.\n   Write the report to `alert-coverage.md` at the repo root (it lives\n   there permanently — later post-incident proposals and decisions append\n   to it, so declined proposals aren't re-proposed). Proposals are drafts\n   for humans to review at the gate; none is installed in this phase.\n\n**Gate:** the gate post MUST open with a verifiable header — these are\nmechanical self-checks, not prose: (a) the mined incident-ID list's count,\nwhich must equal the `lessons.md` entry count and must contain zero\nholdout or excluded IDs (state all three checks and their results); (b) a\nline reading exactly \"Routing conflicts: none\" or \"Routing conflicts:\n[list]\" — resolving a conflict silently is forbidden, so this line makes\nsilence impossible; (c) one sample correlation row showing its provenance\ntag; (d) a standalone checklist of EVERY routing-tree handle and every\ncorrelation-row action target (who gets @-mentioned or paged, ever), each\non its own line for individual confirmation — these are the rows a\npoisoned or mistaken mining pass would weaponize, so they get eyes one by\none, not skimmed inside 40 drafts. Then post a summary table (class → incident count → confidence) and\nthe draft files. Every draft is reviewable markdown; ask the human to correct,\ndelete, or confirm each class. Low-confidence rows stay marked even after\nthis gate — only repeated confirmation in production removes the annotation.\n\n## Phase 2 — Interview\n\nGoal: fill the policy blanks that cannot be mined. Ask **only** these, one\nblock at a time, offering mined suggestions where you have them:\n\n1. **Paging criteria.** For each metric worth paging on: threshold, sustain\n   window, and exemptions (deploy windows, known-noisy periods). Suggest\n   values from alert history (\"this metric's alerts self-resolved under 4%\n   in 11 of 12 cases — suggest paging at sustained >4%\u002F10min\") but the human\n   sets the number (rule 15).\n2. **Severity norms.** What's a page vs. a business-hours ping vs. a morning\n   log line.\n3. **Escalation owners.** Resolve every routing-tree conflict flagged in\n   Phase 1; get the real group handles (route to groups, not individuals).\n   If Phase 1 flagged a bus-factor finding, raise it here as a resilience\n   question and let the team decide whether the tree should distribute\n   load differently than history did.\n4. **Deploy windows.** How to tell a deploy is in progress (the `deploys`\n   capability, a channel, a calendar).\n5. **Escalation timeout and fallback alerting.** Two decisions, both the\n   human's:\n   - *Timeout:* when Claude posts a page-severity finding and @-mentions\n     the routed owner, how long does it wait for acknowledgment before\n     escalating — and to whom? An ack is an **explicit affirmative from a\n     human** (\"ack\", \"on it\", or the team's designated reaction, from a\n     person) — bot posts, alert traffic, and passive emoji do not count.\n     Suggest a default ({{15 min}} → the escalation handle from block 3),\n     but the human sets both the clock and the ladder. Also ask for the\n     **terminal step**: if the escalation itself goes unacked, what\n     happens — repeat-page via the pager's escalation policy, a wider\n     channel post, or an explicitly accepted \"unattended until morning\"\n     posture? The ladder must end somewhere deliberate. Without answers,\n     Claude never re-pings on its own.\n   - *Fallback:* when a page-severity finding can't page — no `pager`\n     bound in STACK.md, or the page call fails — what happens instead?\n     Offer the options and let them choose: @-mention the escalation\n     group in the on-call channel; post to a designated always-watched\n     channel; or hold for the morning log (only sane for teams with no\n     off-hours expectations — say so). Be honest about the first two:\n     **Slack @-mentions don't penetrate Do-Not-Disturb**, so an\n     @-mention fallback is business-hours-grade coverage — tell the team\n     this before they choose it. Record the choice in `ONCALL.md`;\n     never invent a fallback mid-incident.\n\n6. **Alert-rule proposals: format and install mode.** Two decisions:\n   - *Format:* which alerting tool should proposals target, and in what\n     paste-ready native form (monitor JSON, Terraform, PromQL, UI steps)?\n     Prose proposals are not acceptable output — a proposal is something a\n     human can install in under a minute.\n   - *Install mode:* **default — Claude drafts, a human installs** (the\n     paste is the permission; keeps the kit fully read-only). Or the\n     **alert-editor extension**, opt-in only: a separate write credential\n     to the alerting tool, additive-only — Claude may CREATE a new rule\n     after explicit per-rule approval in the channel, may never modify,\n     delete, or silence an existing rule, and logs every write to\n     `lessons.md`. If they opt in, record it in `ONCALL.md` and\n     `STACK.md`'s access posture. Present the trade honestly: the\n     extension saves a paste; the default keeps \"no write credentials to\n     monitored systems\" true without asterisks.\n\n7. **Confirm the read-only guarantee.** Not a question — a statement to\n   make once, so the team knows the contract: this agent never changes the\n   state of any monitored system; its only outputs are messages, log\n   entries, proposed PRs, and pages. There is no allowlist to configure.\n   Teams that want automated mitigation are outside this kit's scope and\n   should design that separately, on an accountable human identity.\n\n8. **Lifecycle windows and standing reports.** Three decisions, all\n   human-set numbers (rule 15):\n   - *Staleness\u002Fzombie windows:* how long an open incident stays quiet\n     before a \"looks stale\" nudge ({{24h}} suggested) and before the\n     handoff's zombie list ({{72h}} suggested) — these gate what Claude\n     *says*, never what it changes.\n   - *Morning sitrep:* on or off, what time, and confirm the \"post\n     nothing when empty\" behavior.\n   - *Weather report:* opt in or skip — show the cost anchor from\n     `templates\u002Froutines.md` and the cadence-guard design before they\n     choose. Skipping is the default and completely fine (status stays\n     on-demand). If they opt in, three things go into `ONCALL.md`: the\n     cadence targets, the report-page binding, and the mood\n     tier-boundary table (the two base signals and the human-set\n     boundaries mapping each to sunny\u002Fpartly_cloudy\u002Fovercast\u002Fstormy —\n     the weather skill refuses to run without it).\n\nWrite the answers into `ONCALL.md` from `templates\u002FONCALL.md`, replacing\nevery `{{...}}`. Template fields no block covered (e.g. handoff cadence,\nstatus-on-demand signals): fill with a sensible default, mark each\n`(proposed)`, and list them explicitly at the gate for confirmation —\nnever leave blanks, never present a default as the user's decision.\n\n**Gate:** post the completed `ONCALL.md` diff. The human signs off the\npolicy. Do not proceed.\n\n## Phase 3 — Validate\n\nGoal: prove the drafted playbooks against incidents they weren't built from.\n\n1. Hold out 5–10 resolved incidents **not used** in Phase 1 (or the most\n   recent ones if history is thin — say so). Span the failure classes and\n   include page-severity incidents where they exist; if none exist, the\n   results file states the paging dimension is untested.\n2. For each: take only the triggering alert\u002Ffirst message, run the `triage`\n   skill as if live (read-only), and produce the diagnosis you would have\n   posted. For long-running holdouts, also produce the >30-min update —\n   graded against triage step 6a's story-so-far spec, not just the\n   diagnosis.\n3. Grade **in a fresh context** (a separate session\u002Fsubagent that didn't\n   produce the diagnoses, prompted skeptically; human confirms), per\n   `eval\u002Freplay.md`: ✅ correct \u002F ⚠️ partially correct \u002F ❌ wrong \u002F\n   🚫 harmful (would have misdirected mitigation or paged wrongly).\n4. Write `eval\u002Freplay-results.md`: the table, per-incident links, and for\n   every ❌\u002F🚫 the playbook change that would have prevented it, as a\n   proposed diff.\n\n**Gate:** pass = ≥70% ✅+⚠️ **and zero 🚫**. Present the percentage as a\nsmoke test, not statistics — with 5–10 holdouts one grade swings ~14\npoints. The real content of this gate is the per-incident review of every\n❌\u002F🚫 and its proposed diff; the real quantitative gate is the shadow\nperiod, where evidence actually accumulates. On pass, ask to\nproceed. On fail, apply the proposed playbook diffs (with human review)\nand re-run with fresh holdouts; a thin-history team that exhausts its\nholdouts goes to shadow with the alert-watch routine in review-only mode\nrather than re-testing on incidents the playbooks have now seen. Never\nlower the bar.\n\n## Phase 4 — Install\n\nGoal: turn it on, narrowest first.\n\n0. **Verify channel connectivity before anything else.** This phase only\n   works from the Slack channel. The checklist, done by the human:\n   `\u002Finvite @Claude` to the on-call channel and each alert channel to be\n   watched; an Owner adds this repo to the channel's access bundle. Then\n   the proof: **from the channel**, ask `@Claude what can you access from\n   this channel?` and have it read `ONCALL.md` back. If it can't read the\n   repo, stop — pasting routines against a repo the channel can't reach\n   fails silently. Clear the \"channel connectivity: unverified\" gap in\n   `STACK.md` once this passes.\n\n1. Generate the routine messages from `templates\u002Froutines.md`, with real\n   channel names, cadences, and `STACK.md` bindings filled in. Order:\n   handoff (read-only) → morning sitrep (read-only, if chosen) → alert\n   investigation (posts diagnoses) → weather (opt-in, event-gated, if\n   chosen in Interview block 8). There is\n   no detection routine to install — detection stays in the team's\n   deterministic alerting; if a service is launching without alerts,\n   propose starter rules per templates\u002Froutines.md instead.\n2. Recommend the shadow period for the alert-watch routine (the handoff is\n   a read-only weekly report and goes live immediately). Shadow exits on\n   **evidence, not the calendar**: diagnoses post to a review\n   channel\u002Fthread and are graded daily, and promotion to live follows the\n   shadow-exit bar in `eval\u002Freplay.md` — the canonical source, which also\n   covers the quiet-channel case (too few alerts means extend, not\n   promote).\n2a. **Create the routine registry.** After the pastes, create (or update) a\n   channel canvas — or a pinned message where canvases aren't available —\n   titled \"Standing work in this channel\": every routine's name, schedule,\n   one-line purpose, live-or-shadow status, and last-changed date, plus\n   one closing line (\"to change when\u002Fwhere, edit the routine here; to\n   change how\u002Fpolicy, PR {{repo}}\"). Humans install routines; you keep\n   this registry current whenever standing work changes, so what's\n   running is legible at a glance to anyone who joins the channel.\n3. The human pastes each routine into the channel (routines belong to the\n   channel and its members — you don't install standing work for a team\n   without them seeing exactly what it says).\n\n**Gate (final):** confirm each routine the human installed by listing the\nchannel's standing work back. Remind them: to change *when\u002Fwhere*, edit the\nroutine in-channel; to change *how\u002Fpolicy*, PR the repo. Setup complete.\n",{"name":5,"description":7},"main","c03282cd5381a5a2e12e32bfb3c8957d52ce01f1","skills\u002Foncall-setup",26,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit","https:\u002F\u002Fgithub.com\u002Fanthropics","https:\u002F\u002Fanthropic.com","2026-08-07 03:11:35",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add anthropics\u002Foncall-kit --skill oncall-setup",{"tool":58,"command":59},"bunx","bunx skills add anthropics\u002Foncall-kit --skill oncall-setup",{"tool":61,"command":62},"pnpm","pnpm dlx skills add anthropics\u002Foncall-kit --skill oncall-setup","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit\u002Fblob\u002Fmain\u002Fskills\u002Foncall-setup\u002FSKILL.md",true,[],[67,92,113],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":39},"01M718HM2Z99H6P2ZAV25ZZ1T0","weather","The optional standing status report (\"the weather\"): compile open incidents, build health, merge-queue stats, and deploy lag into one always-current report page, and post to the channel only when a defined event fires. Use when the weather routine fires, or when someone asks to run\u002Fupdate the weather report.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit\u002Fblob\u002Fmain\u002Fskills\u002Fweather\u002FSKILL.md",[],[69,74,75,76,77,78,79,80,81,82,83,84,85,27,86,87,88,89,90,91],"run","status report","open","only","when","merge","update","status","routine","page","event","compile","build health","use","weather report","stats","health","post",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":39},"01M718HHWHC8Y2F9FN08Z7ZJ26","triage","Investigate an alert or incident in this channel: classify the symptom, load the matching triage reference, check lessons.md for known causes, and post a grounded first-pass diagnosis with evidence links and a proposed (never executed) fix. Use when an alert fires, a routine detects a new anomaly, or someone reports something broken (\"tests aren't running\", \"deploys look stuck\", \"is CI down?\").","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit\u002Fblob\u002Fmain\u002Fskills\u002Ftriage\u002FSKILL.md",[],[94,99,100,87,101,102,78,103,104,105,106,107,108,109,35,110,111,32,29,112],"new","lessons","load","alert","check","ci","tests","running","links","broken","evidence","anomaly","down","fix",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":39},"01M718HCDRB6WK6MB5Q6V047N7","handoff","Write the weekly on-call handoff: everything the incoming on-call needs, triage-ready, posted to the channel at shift boundary. Use when the weekly routine fires, or when someone asks for a handoff \u002F shift summary \u002F \"catch the next on-call up\".","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit\u002Fblob\u002Fmain\u002Fskills\u002Fhandoff\u002FSKILL.md",[],[115,82,120,121,32,26,24,87,78,122,123,124,125,126,127,94,128],"weekly","ready","catch","boundary","next","at","write","summary","channel"]