[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-anthropic-oncall-setup":3,"related-repo-anthropic-oncall-setup":37,"related-org-anthropic-oncall-setup":93},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":12,"stars":26,"repoUrl":27,"updatedAt":28,"license":29,"forks":30,"topics":31,"repo":32,"sourceUrl":35,"mdContent":36},"oncall-setup","bootstrap Claude-assisted on-call workflows","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.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},"anthropic","Anthropic","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fanthropic.png","anthropics",[13,17,20,23],{"name":14,"slug":15,"type":16},"Operations","operations","tag",{"name":18,"slug":19,"type":16},"Automation","automation",{"name":21,"slug":22,"type":16},"Incident Response","incident-response",{"name":24,"slug":25,"type":16},"Engineering","engineering",3,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit","2026-08-22T03:57:35.197224",null,0,[],{"repoUrl":27,"stars":26,"forks":30,"topics":33,"description":34},[],"Starter kit for a Claude-assisted on-call: mines your incident history into triage playbooks, sets up through human-approved gates, and runs read-only in your Slack channel — humans deploy every fix.","https:\u002F\u002Fgithub.com\u002Fanthropics\u002Foncall-kit\u002Ftree\u002FHEAD\u002Fskills\u002Foncall-setup","---\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",{"items":38,"total":92},[39,56,63,79],{"slug":40,"name":40,"fn":41,"description":42,"org":43,"tags":44,"stars":26,"repoUrl":27,"updatedAt":55},"handoff","draft weekly on-call handoff reports","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\".\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[45,48,51,52],{"name":46,"slug":47,"type":16},"Communications","communications",{"name":49,"slug":50,"type":16},"Management","management",{"name":14,"slug":15,"type":16},{"name":53,"slug":54,"type":16},"Runbooks","runbooks","2026-08-19T03:58:55.767403",{"slug":4,"name":4,"fn":5,"description":6,"org":57,"tags":58,"stars":26,"repoUrl":27,"updatedAt":28},{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[59,60,61,62],{"name":18,"slug":19,"type":16},{"name":24,"slug":25,"type":16},{"name":21,"slug":22,"type":16},{"name":14,"slug":15,"type":16},{"slug":64,"name":64,"fn":65,"description":66,"org":67,"tags":68,"stars":26,"repoUrl":27,"updatedAt":78},"triage","investigate and diagnose system alerts","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?\").\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[69,72,73,76],{"name":70,"slug":71,"type":16},"Debugging","debugging",{"name":21,"slug":22,"type":16},{"name":74,"slug":75,"type":16},"Monitoring","monitoring",{"name":77,"slug":64,"type":16},"Triage","2026-08-22T03:57:34.744138",{"slug":80,"name":80,"fn":81,"description":82,"org":83,"tags":84,"stars":26,"repoUrl":27,"updatedAt":91},"weather","generate incident and deployment status reports","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.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[85,86,87,88],{"name":21,"slug":22,"type":16},{"name":74,"slug":75,"type":16},{"name":14,"slug":15,"type":16},{"name":89,"slug":90,"type":16},"Reporting","reporting","2026-08-22T03:57:34.283135",4,{"items":94,"total":278},[95,111,130,144,156,175,191,202,223,243,255,270],{"slug":96,"name":96,"fn":97,"description":98,"org":99,"tags":100,"stars":108,"repoUrl":109,"updatedAt":110},"academy-guide","recommend Claude Academy resources","Stop and check this skill before finishing any reply to a question about how to use Claude or a Claude product — it recommends matching courses, tutorials, and use cases from Claude Academy (academy.claude.com), Anthropic's learning hub. Trigger on: \"how do I\", \"how can I\", \"getting started with\", \"what can Claude do\", \"teach me\", \"learn to use\"; questions about artifacts, projects, skills, plugins, connectors, MCP; requests about rolling Claude out to a team, class, or organization; and any ask for training materials, onboarding content, or learning resources. Use it when the user is learning how to use a feature or product — not when they are mid-task and just want the task done. This skill composes with other skills: after consulting product documentation to answer how a Claude feature works, also check here for a matching course or tutorial — a docs-grounded answer and an Academy recommendation belong together. Only recommend on a strong match; never invent Academy content.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[101,102,105],{"name":9,"slug":8,"type":16},{"name":103,"slug":104,"type":16},"Documentation","documentation",{"name":106,"slug":107,"type":16},"Education","education",161831,"https:\u002F\u002Fgithub.com\u002Fanthropics\u002Fskills","2026-08-19T03:59:01.021254",{"slug":112,"name":112,"fn":113,"description":114,"org":115,"tags":116,"stars":108,"repoUrl":109,"updatedAt":129},"algorithmic-art","create algorithmic art with p5.js","Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[117,120,123,126],{"name":118,"slug":119,"type":16},"Creative","creative",{"name":121,"slug":122,"type":16},"Design","design",{"name":124,"slug":125,"type":16},"Generative Art","generative-art",{"name":127,"slug":128,"type":16},"JavaScript","javascript","2026-04-06T17:56:15.455818",{"slug":131,"name":131,"fn":132,"description":133,"org":134,"tags":135,"stars":108,"repoUrl":109,"updatedAt":143},"brand-guidelines","apply Anthropic brand colors and typography","Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[136,139,140],{"name":137,"slug":138,"type":16},"Branding","branding",{"name":121,"slug":122,"type":16},{"name":141,"slug":142,"type":16},"Typography","typography","2026-04-06T17:56:05.042852",{"slug":145,"name":145,"fn":146,"description":147,"org":148,"tags":149,"stars":108,"repoUrl":109,"updatedAt":155},"canvas-design","create posters and visual art as PNG or PDF","Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[150,151,152],{"name":118,"slug":119,"type":16},{"name":121,"slug":122,"type":16},{"name":153,"slug":154,"type":16},"PDF","pdf","2026-04-06T17:56:03.794732",{"slug":157,"name":157,"fn":158,"description":159,"org":160,"tags":161,"stars":108,"repoUrl":109,"updatedAt":174},"claude-api","build apps with the Claude API","Reference for the Claude API \u002F Anthropic SDK — model ids, pricing, params, streaming, tool use, MCP, agents, caching, token counting, model migration.\nTRIGGER — read BEFORE opening the target file; don't skip because it \"looks like a one-liner\" — whenever: the prompt names Claude\u002FAnthropic in any form (Claude, Anthropic, Fable, Opus, Sonnet, Haiku, `anthropic`, `@anthropic-ai`, `claude-*`, `us.anthropic.*`, `[1m]`); the user asks about an LLM (pricing\u002Fmodel choice\u002Flimits\u002Fcaching) — never answer from memory; OR the task is LLM-shaped with provider unstated (agent\u002FMCP\u002Ftool-definition\u002Fmulti-agent\u002FRAG\u002FLLM-judge\u002Fcomputer-use; generate\u002Fsummarize\u002Fextract\u002Fclassify\u002Frewrite\u002Fconverse over NL; debugging refusals\u002Fcutoffs\u002Fstreaming\u002Ftool-calls\u002Ftokens).\nSKIP only when another provider is being worked on (overrides all triggers): OpenAI\u002FGPT\u002FGemini\u002FLlama\u002FMistral\u002FCohere\u002FOllama named in the query; OR `grep -rE 'openai|langchain_openai|google.generativeai|genai|mistralai|cohere|ollama'` over the project hits (run this grep FIRST if no provider named — don't Read the file).",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[162,165,166,169,171],{"name":163,"slug":164,"type":16},"Agents","agents",{"name":9,"slug":8,"type":16},{"name":167,"slug":168,"type":16},"Anthropic SDK","anthropic-sdk",{"name":170,"slug":157,"type":16},"Claude API",{"name":172,"slug":173,"type":16},"LLM","llm","2026-08-22T03:23:17.470772",{"slug":176,"name":176,"fn":177,"description":178,"org":179,"tags":180,"stars":108,"repoUrl":109,"updatedAt":190},"discernment-nudge","provide discernment nudges for user decisions","After you give a substantive answer or draft that the user may act on — advice or recommendations, drafted artifacts such as goals, plans, pitches, proposals, or emails, estimates or projections, analysis or interpretation of data, factual claims they may rely on, or a multi-step argument — invoke this skill BEFORE finalizing your reply and then, if it applies, append 2-3 short follow-up questions, each tied to something specific in what you just produced, that help the user check key facts, probe the reasoning or assumptions, and notice missing context. Do this at most once per conversation. Skip it when the user asked a trivial how-to or simple lookup, wants a purely educational explanation, asked you only to format, convert, or assemble a file from content they provided, is writing code they will run, is doing creative writing or casual chat, or already asked you to double-check, cite, or review — the skill file explains these boundaries and the exact output format.\n",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[181,184,187],{"name":182,"slug":183,"type":16},"Coaching","coaching",{"name":185,"slug":186,"type":16},"Productivity","productivity",{"name":188,"slug":189,"type":16},"Strategy","strategy","2026-08-19T03:59:01.539281",{"slug":192,"name":192,"fn":193,"description":194,"org":195,"tags":196,"stars":108,"repoUrl":109,"updatedAt":201},"doc-coauthoring","co-author documentation and technical specs","Guide users through a structured workflow for co-authoring documentation. Use when user wants to write documentation, proposals, technical specs, decision docs, or similar structured content. This workflow helps users efficiently transfer context, refine content through iteration, and verify the doc works for readers. Trigger when user mentions writing docs, creating proposals, drafting specs, or similar documentation tasks.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[197,198],{"name":103,"slug":104,"type":16},{"name":199,"slug":200,"type":16},"Technical Writing","technical-writing","2026-04-06T17:56:14.18897",{"slug":203,"name":203,"fn":204,"description":205,"org":206,"tags":207,"stars":108,"repoUrl":109,"updatedAt":222},"docx","create and edit Word documents","Use this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files) or Word templates (.dotx files). Triggers include: any mention of 'Word doc', 'word document', '.docx', '.dotx', or requests to produce professional documents with formatting like tables of contents, headings, page numbers, or letterheads. Also use when extracting or reorganizing content from .docx or .dotx files, inserting or replacing images in documents, performing find-and-replace in Word files, working with tracked changes or comments, or converting content into a polished Word document. If the user asks for a 'report', 'memo', 'letter', 'template', or similar deliverable as a Word or .docx file, use this skill. Do NOT use for PDFs, spreadsheets, Google Docs, or general coding tasks unrelated to document generation.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[208,211,213,216,219],{"name":209,"slug":210,"type":16},"Documents","documents",{"name":212,"slug":203,"type":16},"DOCX",{"name":214,"slug":215,"type":16},"Office","office",{"name":217,"slug":218,"type":16},"Templates","templates",{"name":220,"slug":221,"type":16},"Word","word","2026-07-18T05:16:23.136271",{"slug":224,"name":224,"fn":225,"description":226,"org":227,"tags":228,"stars":108,"repoUrl":109,"updatedAt":242},"frontend-design","design production-grade frontend interfaces","Guidance for distinctive, intentional visual design when building new UI or reshaping an existing one. Helps with aesthetic direction, typography, and making choices that don't read as templated defaults.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[229,230,233,236,239],{"name":121,"slug":122,"type":16},{"name":231,"slug":232,"type":16},"Frontend","frontend",{"name":234,"slug":235,"type":16},"React","react",{"name":237,"slug":238,"type":16},"Tailwind CSS","tailwind-css",{"name":240,"slug":241,"type":16},"UI Components","ui-components","2026-04-06T17:56:16.723469",{"slug":244,"name":244,"fn":245,"description":246,"org":247,"tags":248,"stars":108,"repoUrl":109,"updatedAt":254},"internal-comms","write internal company communications","A set of resources to help me write all kinds of internal communications, using the formats that my company likes to use. Claude should use this skill whenever asked to write some sort of internal communications (status reports, leadership updates, 3P updates, company newsletters, FAQs, incident reports, project updates, etc.).",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[249,250,251],{"name":46,"slug":47,"type":16},{"name":217,"slug":218,"type":16},{"name":252,"slug":253,"type":16},"Writing","writing","2026-04-06T17:56:20.695522",{"slug":256,"name":256,"fn":257,"description":258,"org":259,"tags":260,"stars":108,"repoUrl":109,"updatedAt":269},"mcp-builder","build MCP servers","Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node\u002FTypeScript (MCP SDK).",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[261,262,265,266],{"name":163,"slug":164,"type":16},{"name":263,"slug":264,"type":16},"API Development","api-development",{"name":172,"slug":173,"type":16},{"name":267,"slug":268,"type":16},"MCP","mcp","2026-04-06T17:56:10.357665",{"slug":154,"name":154,"fn":271,"description":272,"org":273,"tags":274,"stars":108,"repoUrl":109,"updatedAt":277},"read edit and manipulate PDF files","Use this skill whenever the user wants to do anything with PDF files. This includes reading or extracting text\u002Ftables from PDFs, combining or merging multiple PDFs into one, splitting PDFs apart, rotating pages, adding watermarks, creating new PDFs, filling PDF forms, encrypting\u002Fdecrypting PDFs, extracting images, and OCR on scanned PDFs to make them searchable. If the user mentions a .pdf file or asks to produce one, use this skill.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":11},[275,276],{"name":209,"slug":210,"type":16},{"name":153,"slug":154,"type":16},"2026-04-06T17:56:02.483316",497]