Claude Code: automating my support rotation

On my team we run a weekly support rotation. Whoever's on duty spends a chunk of every day triaging new issues in the error tracker and clearing support tickets off the task board, with one eye on a Slack channel for anything that's started misbehaving.

None of it is hard. It's just tedious — the kind of thing you half-do at 4pm on a Thursday. Different tools, different mental models, and the real work doesn't start until everything's collected: is this new, or is it an old issue suddenly spiking?

So I handed the collecting to Claude Code.

One command, one digest

The shape that worked is not "one giant prompt." It's one orchestrator skill that knows the daily routine, delegating to small specialist skills that each do exactly one thing.

The orchestrator is dumb on purpose. It says, in effect:

1. Pull unresolved issues assigned to my team from the error tracker (last 14 days), and flag anything new or spiking.
2. List support tickets created since the last check, grouped by status.
3. Read the alerts channel since yesterday, one line per alert, each ending in a concrete next action.
4. Stitch the lot into one dated digest, newest and loudest first.

Each step points at a specialist that owns the messy details: a ticket reader, an order-debugger, and so on. The orchestrator just sequences them and formats the result. When I say "do the support check", it runs the whole routine top-to-bottom and hands me one digest instead of a fan of browser tabs.

Why split it into many small skills

The temptation is to cram everything into one mega-skill. Don't. The split pays off because:

• A small skill is easy to trust. One that only reads a ticket and renders it as clean markdown is easy to get right, and the same ticket-reader feeds both the daily support check and a monthly "group these tickets and find patterns" pass. Write it once, call it everywhere.
• The orchestrator reads like a checklist. Anyone on the team can open it and see what "support duty" means this week. It's documentation that happens to execute.

This is the bit worth stealing even if you never touch support tickets: an orchestrator skill that fans out to single-purpose specialist skills. It's the same instinct as small functions and one job per module, just pointed at your daily ops.

Checking the runbooks

We keep L1 support runbooks in Notion: the documented first response for the failures that keep coming back. So the orchestrator points one more specialist at them. Once everything's gathered, it reads the runbooks and, for each issue, checks whether one already covers it.

When something matches, the digest links the runbook and quotes the first step it prescribes. Most of what lands on support duty isn't novel; it's the same known failures wearing fresh timestamps, and the playbook for each already exists. Surfacing the match turns "what even is this?" into "we have a page for that," which matters most for whoever's new to the rotation.

What I did not automate

The agent gathers and drafts, matching runbooks included. It does not get to decide. A runbook match is a suggestion, not a green light. It tags each issue (act on it, or let it ride) and drafts a "today's focus" shortlist, but a human still makes the call on what's a real bug versus expected noise. The win is that I show up to the judgment part with everything already collected and deduplicated.

Automate the gathering. Keep the judgment. That line is where this stays useful instead of dangerous.