[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M718HHWHC8Y2F9FN08Z7ZJ26":3,"skill-same:01M718HHWHC8Y2F9FN08Z7ZJ26":83},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M718HHWHC8Y2F9FN08Z7ZJ26","triage",null,"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?\").","anthropics\u002Foncall-kit","anthropics","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F76263028?v=4","01M697XGDPXJAVQ8391V2BCYTE","Anthropic","01M718HAM88APBE3NK565F2XWJ",272,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit\u002Fblob\u002Fmain\u002Fskills\u002Ftriage\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"tests","new","running","when","anomaly","down","lessons","for","load","links","incident","alert","evidence","never","use","fix","broken","check","ci","2026-11-10 10:12:30",false,"---\nname: triage\ndescription: >\n  Investigate an alert or incident in this channel: classify the symptom,\n  load the matching triage reference, check lessons.md for known causes, and\n  post a grounded first-pass diagnosis with evidence links and a proposed\n  (never executed) fix. Use when an alert fires, a routine detects a new\n  anomaly, or someone reports something broken (\"tests aren't running\",\n  \"deploys look stuck\", \"is CI down?\").\n---\n\n\u003C!-- Copyright 2026 Anthropic PBC -->\n\u003C!-- SPDX-License-Identifier: Apache-2.0 -->\n\n# Triage\n\nStanding rules in `CLAUDE.md` apply — especially: propose, don't act (rule\n1); every claim carries a link (rule 4); data before theory (rule 5); log to\n`lessons.md` without asking (rule 8).\n\n## Procedure\n\n1. **Load context.** Read `ONCALL.md` (policy + routing), `STACK.md`\n   (capability bindings), and `lessons.md` (known causes) from disk. Files\n   over memory (rule 7).\n\n2. **Classify the symptom.** Match against the failure classes in\n   `references\u002F`:\n\n   | Symptom looks like | Load |\n   |---|---|\n   | Tests failing, flaking, or silently not running | `references\u002Ftest-failures.md` |\n   | PRs stuck, queue depth growing, merges slow | `references\u002Fmerge-queue.md` |\n   | Jobs not starting, agents stuck, capacity errors | `references\u002Frunner-infra.md` |\n   | Bad deploy, rollout stuck, post-deploy regression | `references\u002Fdeploy-rollout.md` |\n   | None of the above | No reference — say so explicitly, and investigate from first principles: timeline first (what changed around onset — deploys, flags, config), then blast radius, then narrow. |\n\n   (Classes are the CI defaults; your setup phase may have replaced them.\n   The table above must match the files actually present in `references\u002F` —\n   if they've diverged, trust the directory and flag the drift.)\n\n3. **Check the log first.** Search `lessons.md` for this class's #tag and\n   read the matching entries — never ingest the whole file; it grows\n   unbounded by design. A matching past incident is your first\n   hypothesis — cheapest to confirm or kill.\n\n3a. **Correlate before you classify.** Sweep the other alert channels (and\n   the `incidents` binding) for the same time window. Five alerts are often\n   one incident: if this symptom is downstream of something already broken —\n   a cluster problem, a shared dependency, another team's incident — say so\n   in the diagnosis (\"correlates with X in #infra-alerts; likely one\n   incident, not five\") and route to the upstream owner instead of\n   investigating the echo.\n\n3b. **Alert storms get ONE triage, not one each.** If several alerts have\n   landed in a short window — or new alerts arrive while you're already\n   investigating — treat them as a batch: group by likely common cause,\n   run a single investigation for the group, and post one diagnosis that\n   lists every alert it accounts for (\"these 14 alerts trace to one\n   upstream: …\"). If an incident record is already open for the cause,\n   attach new alerts to it (post in its thread\u002Frecord) instead of opening\n   a parallel investigation. If the batch looks like a real incident and\n   no record exists, propose declaring one per ONCALL.md — a human\n   declares it (the incident-record invariant); you never do. **Batching is for\n   shared cause only:** if the evidence says the batch contains genuinely\n   unrelated failures, say so explicitly and treat them as distinct\n   incidents — separate diagnoses, separate records, each with its own\n   severity call. Never merge for tidiness.\n\n4. **Run the reference's first checks** against the bound capabilities in\n   `STACK.md`. Establish the timeline: when did the symptom start, and what\n   changed within the preceding window — `deploys`, `flags` change history,\n   config, merges?\n\n4a. **Fan-out (page-severity only; sequential is the default below it).**\n   Where the channel's platform supports spawning parallel subagents, you\n   are the orchestrator: spawn one investigator per bound source of truth\n   the reference's first checks touch — `metrics`, `logs`, `code`\u002F`deploys`,\n   `pager`, `alert-channels`. Each investigator receives exactly four\n   things: the symptom sentence, the onset window, its binding line from\n   `STACK.md`, and the reference's first-check queries for its source —\n   nothing else, so a poisoned thread can't steer it (rule 9a applies\n   inside subagents too). Each returns the fixed shape:\n\n   - **CHECKED:** queries run, with links\n   - **FOUND:** observations with timestamps — observations, never root\n     causes\n   - **NOT FOUND:** what was looked for and absent — absence counts only\n     if the run\u002Fwindow was complete\n   - **CANNOT ACCESS:** anything that 403'd or timed out (surfaces in the\n     diagnosis as a gap, never silently dropped)\n\n   Synthesis is yours alone: correlate, deconflict (two investigators\n   dating onset differently is itself a finding), and write the one\n   diagnosis. Fan-out multiplies token cost — worth it for a page, never\n   for a morning-log item.\n\n5. **Apply the reference's correlation table.** Where observations match a\n   row, you have a candidate root cause; verify it against the timeline\n   before promoting it (rule 5).\n\n5a. **Cross-check blame against \"still happening\"** (CLAUDE.md rule 5a).\n   A blame verdict — bisect, revert notice, \"that PR broke it\" — names\n   the change that *started* the failure; before naming it as the live\n   cause, confirm the symptom appears in the most recent **completed**\n   run\u002Fwindow. Presence always confirms red; absence confirms green only\n   on a completed run.\n\n6. **Post the diagnosis** in this format, in-thread:\n\n   > **What's happening:** one sentence, fresh-reader test applied.\n   > **Root cause (confidence high\u002Fmedium\u002Flow):** the mechanism, with each\n   > claim linked to its evidence.\n   > **Blast radius:** who\u002Fwhat is affected, linked.\n   > **Proposed fix:** the action, why it's safe, and what to watch after.\n   > **Ruled out:** alternatives checked and the evidence that killed them.\n   > **Would change my mind:** the one observation that would.\n\n6a. **Updates on long-running incidents.** Any update posted >30 min after\n   your first diagnosis opens with a 2–4 sentence *story so far* a\n   newcomer can land on cold: when it started and what broke → the\n   **current best understanding** of cause (not the first guess) → what's\n   been tried → where it stands, one sentence. Then the delta. Ruled-out\n   hypotheses don't reappear unless load-bearing. **Never post a \"no\n   change\" update** — silence is a valid state, and noise trains readers\n   to skip your updates.\n\n7. **Route.** If `ONCALL.md`'s routing tree names an owner for this class,\n   mention them. Otherwise mention no one (rule 12).\n\n8. **On human questions or pushback** (\"could it be the schema change\n   instead?\"): treat it as a hypothesis to check, check it against the data,\n   and report back with evidence either way. Never defend a diagnosis;\n   re-derive it.\n\n9. **When a fix is deployed** (by a human, or a permitted gated action):\n   watch it land — bounded. Check the affected metrics at the reference's\n   expected-resolution window (once at half, once at full, once at double —\n   three checks, not a polling loop), post when they return to baseline, or\n   escalate per the routing tree if the window blows. Do not mark resolved\n   (rule 2). If a human wants tighter watching, they can ask — continuous\n   polling is never the default. Verify through the same door the failure\n   came in: re-run the original failing path, or re-check the exact signal\n   that detected the incident — never a proxy. \"Merges are flowing\" proves\n   the merge path, not the whole provider; if your check can't see the\n   original symptom, say the verification is partial and name what it\n   can't see.\n\n10. **Afterwards**, append the incident to `lessons.md` in its entry format\n    (rule 8). If this incident exposed a gap in a reference file, propose\n    the amendment as a PR (rule 9) — you fix the playbook, not just the\n    incident. And ask the alerting question: **would a rule have caught\n    this earlier?** If detection was human or late, propose the rule in\n    the postmortem — paste-ready in the format `ONCALL.md` names, with\n    this incident as provenance. Install per ONCALL.md's install mode:\n    default is a human pastes it; under the alert-editor extension you may\n    create it yourself after explicit approval in the channel (additive\n    only, logged to lessons.md — CLAUDE.md rule 1a).\n","\u003C!-- Copyright 2026 Anthropic PBC -->\n\u003C!-- SPDX-License-Identifier: Apache-2.0 -->\n\n# Triage\n\nStanding rules in `CLAUDE.md` apply — especially: propose, don't act (rule\n1); every claim carries a link (rule 4); data before theory (rule 5); log to\n`lessons.md` without asking (rule 8).\n\n## Procedure\n\n1. **Load context.** Read `ONCALL.md` (policy + routing), `STACK.md`\n   (capability bindings), and `lessons.md` (known causes) from disk. Files\n   over memory (rule 7).\n\n2. **Classify the symptom.** Match against the failure classes in\n   `references\u002F`:\n\n   | Symptom looks like | Load |\n   |---|---|\n   | Tests failing, flaking, or silently not running | `references\u002Ftest-failures.md` |\n   | PRs stuck, queue depth growing, merges slow | `references\u002Fmerge-queue.md` |\n   | Jobs not starting, agents stuck, capacity errors | `references\u002Frunner-infra.md` |\n   | Bad deploy, rollout stuck, post-deploy regression | `references\u002Fdeploy-rollout.md` |\n   | None of the above | No reference — say so explicitly, and investigate from first principles: timeline first (what changed around onset — deploys, flags, config), then blast radius, then narrow. |\n\n   (Classes are the CI defaults; your setup phase may have replaced them.\n   The table above must match the files actually present in `references\u002F` —\n   if they've diverged, trust the directory and flag the drift.)\n\n3. **Check the log first.** Search `lessons.md` for this class's #tag and\n   read the matching entries — never ingest the whole file; it grows\n   unbounded by design. A matching past incident is your first\n   hypothesis — cheapest to confirm or kill.\n\n3a. **Correlate before you classify.** Sweep the other alert channels (and\n   the `incidents` binding) for the same time window. Five alerts are often\n   one incident: if this symptom is downstream of something already broken —\n   a cluster problem, a shared dependency, another team's incident — say so\n   in the diagnosis (\"correlates with X in #infra-alerts; likely one\n   incident, not five\") and route to the upstream owner instead of\n   investigating the echo.\n\n3b. **Alert storms get ONE triage, not one each.** If several alerts have\n   landed in a short window — or new alerts arrive while you're already\n   investigating — treat them as a batch: group by likely common cause,\n   run a single investigation for the group, and post one diagnosis that\n   lists every alert it accounts for (\"these 14 alerts trace to one\n   upstream: …\"). If an incident record is already open for the cause,\n   attach new alerts to it (post in its thread\u002Frecord) instead of opening\n   a parallel investigation. If the batch looks like a real incident and\n   no record exists, propose declaring one per ONCALL.md — a human\n   declares it (the incident-record invariant); you never do. **Batching is for\n   shared cause only:** if the evidence says the batch contains genuinely\n   unrelated failures, say so explicitly and treat them as distinct\n   incidents — separate diagnoses, separate records, each with its own\n   severity call. Never merge for tidiness.\n\n4. **Run the reference's first checks** against the bound capabilities in\n   `STACK.md`. Establish the timeline: when did the symptom start, and what\n   changed within the preceding window — `deploys`, `flags` change history,\n   config, merges?\n\n4a. **Fan-out (page-severity only; sequential is the default below it).**\n   Where the channel's platform supports spawning parallel subagents, you\n   are the orchestrator: spawn one investigator per bound source of truth\n   the reference's first checks touch — `metrics`, `logs`, `code`\u002F`deploys`,\n   `pager`, `alert-channels`. Each investigator receives exactly four\n   things: the symptom sentence, the onset window, its binding line from\n   `STACK.md`, and the reference's first-check queries for its source —\n   nothing else, so a poisoned thread can't steer it (rule 9a applies\n   inside subagents too). Each returns the fixed shape:\n\n   - **CHECKED:** queries run, with links\n   - **FOUND:** observations with timestamps — observations, never root\n     causes\n   - **NOT FOUND:** what was looked for and absent — absence counts only\n     if the run\u002Fwindow was complete\n   - **CANNOT ACCESS:** anything that 403'd or timed out (surfaces in the\n     diagnosis as a gap, never silently dropped)\n\n   Synthesis is yours alone: correlate, deconflict (two investigators\n   dating onset differently is itself a finding), and write the one\n   diagnosis. Fan-out multiplies token cost — worth it for a page, never\n   for a morning-log item.\n\n5. **Apply the reference's correlation table.** Where observations match a\n   row, you have a candidate root cause; verify it against the timeline\n   before promoting it (rule 5).\n\n5a. **Cross-check blame against \"still happening\"** (CLAUDE.md rule 5a).\n   A blame verdict — bisect, revert notice, \"that PR broke it\" — names\n   the change that *started* the failure; before naming it as the live\n   cause, confirm the symptom appears in the most recent **completed**\n   run\u002Fwindow. Presence always confirms red; absence confirms green only\n   on a completed run.\n\n6. **Post the diagnosis** in this format, in-thread:\n\n   > **What's happening:** one sentence, fresh-reader test applied.\n   > **Root cause (confidence high\u002Fmedium\u002Flow):** the mechanism, with each\n   > claim linked to its evidence.\n   > **Blast radius:** who\u002Fwhat is affected, linked.\n   > **Proposed fix:** the action, why it's safe, and what to watch after.\n   > **Ruled out:** alternatives checked and the evidence that killed them.\n   > **Would change my mind:** the one observation that would.\n\n6a. **Updates on long-running incidents.** Any update posted >30 min after\n   your first diagnosis opens with a 2–4 sentence *story so far* a\n   newcomer can land on cold: when it started and what broke → the\n   **current best understanding** of cause (not the first guess) → what's\n   been tried → where it stands, one sentence. Then the delta. Ruled-out\n   hypotheses don't reappear unless load-bearing. **Never post a \"no\n   change\" update** — silence is a valid state, and noise trains readers\n   to skip your updates.\n\n7. **Route.** If `ONCALL.md`'s routing tree names an owner for this class,\n   mention them. Otherwise mention no one (rule 12).\n\n8. **On human questions or pushback** (\"could it be the schema change\n   instead?\"): treat it as a hypothesis to check, check it against the data,\n   and report back with evidence either way. Never defend a diagnosis;\n   re-derive it.\n\n9. **When a fix is deployed** (by a human, or a permitted gated action):\n   watch it land — bounded. Check the affected metrics at the reference's\n   expected-resolution window (once at half, once at full, once at double —\n   three checks, not a polling loop), post when they return to baseline, or\n   escalate per the routing tree if the window blows. Do not mark resolved\n   (rule 2). If a human wants tighter watching, they can ask — continuous\n   polling is never the default. Verify through the same door the failure\n   came in: re-run the original failing path, or re-check the exact signal\n   that detected the incident — never a proxy. \"Merges are flowing\" proves\n   the merge path, not the whole provider; if your check can't see the\n   original symptom, say the verification is partial and name what it\n   can't see.\n\n10. **Afterwards**, append the incident to `lessons.md` in its entry format\n    (rule 8). If this incident exposed a gap in a reference file, propose\n    the amendment as a PR (rule 9) — you fix the playbook, not just the\n    incident. And ask the alerting question: **would a rule have caught\n    this earlier?** If detection was human or late, propose the rule in\n    the postmortem — paste-ready in the format `ONCALL.md` names, with\n    this incident as provenance. Install per ONCALL.md's install mode:\n    default is a human pastes it; under the alert-editor extension you may\n    create it yourself after explicit approval in the channel (additive\n    only, logged to lessons.md — CLAUDE.md rule 1a).\n",{"name":5,"description":7},"main","c03282cd5381a5a2e12e32bfb3c8957d52ce01f1","skills\u002Ftriage",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":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add anthropics\u002Foncall-kit --skill triage",{"tool":57,"command":58},"bunx","bunx skills add anthropics\u002Foncall-kit --skill triage",{"tool":60,"command":61},"pnpm","pnpm dlx skills add anthropics\u002Foncall-kit --skill triage","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit\u002Fblob\u002Fmain\u002Fskills\u002Ftriage\u002FSKILL.md",true,[65,71,75,79],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"references\u002Fdeploy-rollout.md","REFERENCE","参考文档",11142,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit\u002Fblob\u002Fmain\u002Fskills\u002Ftriage\u002Freferences\u002Fdeploy-rollout.md",{"path":72,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fmerge-queue.md",3126,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit\u002Fblob\u002Fmain\u002Fskills\u002Ftriage\u002Freferences\u002Fmerge-queue.md",{"path":76,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Frunner-infra.md",3390,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit\u002Fblob\u002Fmain\u002Fskills\u002Ftriage\u002Freferences\u002Frunner-infra.md",{"path":80,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Ftest-failures.md",3438,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit\u002Fblob\u002Fmain\u002Fskills\u002Ftriage\u002Freferences\u002Ftest-failures.md",[84,108,131],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":38},"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",[],[86,91,92,93,94,22,95,96,97,98,99,100,101,102,103,33,104,105,106,107],"run","status report","open","only","merge","update","status","routine","page","event","compile","incidents","build health","weather report","stats","health","post",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":38},"01M718HE63YJFD1DJ2K53C66TW","oncall-setup","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.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit\u002Fblob\u002Fmain\u002Fskills\u002Foncall-setup\u002FSKILL.md",[],[115,116,117,102,118,119,120,121,122,123,124,125,126,127,32,128,129,26,130,29],"setup","oncall","oncall setup","up","routines","call","more","kit","repo","policy","SET","interview","mine","history","discover","just",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":38},"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",[],[133,138,139,140,26,118,120,33,22,141,142,143,144,145,98,5,146],"summary","weekly","ready","catch","boundary","next","at","write","channel"]