A real Claude Code Skills walkthrough, problem to ship

Most writing about agents stays at the level of architecture diagrams. This post does the opposite. I want to walk one ordinary, slightly painful engineering task all the way through, from the moment it lands as a problem to the moment a verified change ships, using Claude Code, a hand-authored Agent Skill, an MCP connection, and a verification step. The task is unglamorous on purpose, because the unglamorous tasks are where agentic workflows earn their keep.

The scenario: a mid-size SaaS team has a recurring chore. Every time a customer reports that a webhook delivery failed, an engineer has to dig through logs, find the failed event, check why it failed, decide whether to replay it, and reply to the customer with an explanation. It takes twenty to forty minutes, it interrupts whatever the engineer was doing, and the quality of the reply depends on who picks it up. It is a perfect candidate to encode as a skill.

Step one: framing the problem so an agent can own it

Before writing anything, the team does the most important and most skipped step: they articulate the procedure a senior engineer actually follows. They sit with the person who handles these tickets best and write down, in order, what she does. Find the customer's account ID. Query the webhook delivery log for failures in the relevant window. Read the failure reason. If it was a transient network error, replay the event. If it was a 4xx from the customer's endpoint, do not replay, and explain that their server rejected it. Draft a reply in the company's voice.

That written procedure is the seed of the skill. Notice it already contains a real decision point, replay or not, which is exactly the kind of judgment that makes the task tedious for humans and valuable to encode well. Getting this articulation right is most of the work; the rest is plumbing.

Step two: wiring the tools through MCP

The agent cannot do anything useful without reach into real systems, and that reach comes through MCP. Model Context Protocol is an open standard that connects Claude to external tools and data through MCP servers, and here it is the bridge to the systems this task needs. The team exposes two narrow tools: a read-only query against the webhook delivery log, and a replay endpoint that re-sends a single event by ID. Critically, the replay tool is scoped to one event at a time and logs every call, so the agent cannot replay in bulk even if it wanted to.

flowchart TD
  A["Customer ticket: webhook failed"] --> B["Claude loads 'webhook-triage' skill"]
  B --> C["MCP: query delivery log"]
  C --> D{"Failure reason?"}
  D -->|Transient 5xx / timeout| E["MCP: replay single event"]
  D -->|Customer 4xx reject| F["Skip replay"]
  E --> G["Draft customer reply"]
  F --> G
  G --> H["Verification: reply + action reviewed"]
  H -->|Approved| I["Send reply, log outcome"]

This wiring is where the blast-radius thinking from good risk practice pays off. The query tool is read-only. The replay tool is single-event and audited. Even a confidently wrong agent can do limited damage, and every action it takes leaves a trace.

Step three: authoring the skill

The skill folder contains a clear instruction file written in plain prose: how to identify the account, which tool to call, how to interpret each failure class, and the explicit rule that a 4xx rejection must never be replayed. It includes a short reference of the company's reply tone with two example replies, one for a transient failure that was replayed and one for a customer-side rejection that was not. It also includes a small script that formats the final reply consistently so the agent does not have to reinvent the structure each time.

The description on the skill is deliberate, because the description is what tells Claude when to load it. It reads something like "Use when a customer reports a failed or missing webhook delivery and needs the event triaged, optionally replayed, and explained." That phrasing matters: if the description is vague, Claude either fails to load the skill when needed or loads it for unrelated tickets.

Step four: the first real runs and the inevitable gaps

The first run goes well on a clean case and reveals a gap on a messy one. A ticket comes in where the failure was a transient timeout, but the customer had also changed their endpoint URL in the meantime. Replaying to the old URL would fail again. The original procedure never covered this, because the human handling it just knew to check. The team reads the transcript, sees exactly where Claude proceeded without that check, and adds a step to the skill: confirm the current endpoint before replaying.

This is the loop that makes agentic workflows compound. Each real-world edge case that surfaces becomes a permanent improvement to the skill, so the agent's next run is better and the improvement is shared across everyone who triggers the skill. The senior engineer's hard-won instinct, the endpoint check, is now encoded knowledge rather than something locked in one person's head.

Step five: shipping with a verification gate

The team does not let the agent send replies or replay events unattended on day one. They run it with a human gate: Claude does the full triage, decides on the action, drafts the reply, and presents all of it for a one-click approval. The engineer reviews in roughly two minutes instead of doing twenty minutes of digging. Over a few weeks, as the approve-without-edit rate climbs and the audit log stays clean, the team relaxes the gate for the clear transient-failure case while keeping human review for anything involving a customer-side rejection or an unusual pattern.

The outcome is concrete. A chore that consumed half an hour of focused engineer time per ticket becomes a two-minute review, then for the common case becomes fully hands-off with monitoring. The customer replies are more consistent than when five different engineers wrote them. And the entire decision trail is logged, so an audit or a postmortem is trivial. That is the shape of a shipped agentic outcome: not a flashy demo, but a real chore retired with its judgment preserved and its risks bounded.

Frequently asked questions

How long does it take to build something like this?

The plumbing, MCP tools and the skill folder, is often a day or two. The longer part is articulating the procedure honestly and running enough real cases to find the edge cases. Budget for a few weeks of supervised operation before relaxing the human gate, not because the build is slow but because earning trust takes real runs.

Why use a skill instead of just a long prompt?

A skill is reusable, versioned, and loaded automatically when relevant, and it carries scripts and references a prompt cannot. The endpoint-check fix from this walkthrough lives in the skill permanently and helps every future run. A one-off prompt would lose that improvement the moment the conversation ended.

What if the agent makes the wrong replay decision?

The verification gate catches it during supervised operation, and the single-event, audited replay tool limits the damage even later. The combination of bounded tools and a human or policy checkpoint means a wrong decision is recoverable rather than catastrophic, which is what makes shipping responsibly possible.

Bringing this workflow to your phone lines

CallSphere runs the same problem-to-shipped pattern for voice and chat: agents that triage a caller's issue, take a scoped action mid-conversation, and resolve or escalate. See an end-to-end example at callsphere.ai.

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.