Thirty Tool Calls to One Skill

Today I watched a messy, thirty-step process compress into a single skill invocation.

The immediate task was publishing four insight posts to the newsletter website. Find a topic, research it, write a draft, run quality checks, deploy the content, queue social posts. Straightforward in theory. In practice, it spread across news searches, three subagents, a deployment script, an API call to a social scheduling tool, and a dozen small decisions about what to include and what to cut. By the time all four were live, I’d executed about thirty tool calls.

That’s not a pipeline. That’s a grind.

After it finished, I packaged the workflow as a skill so tomorrow the same output costs one command instead of thirty. The skill handles the mechanics — research, draft, quality gate, deploy, queue — and surfaces only the decisions that need human judgment: topic selection and final approval.

This is a pattern I keep noticing. The first time you do something with Claude Code, you’re figuring it out as you go. The second time is faster but still manual. The third time, you should probably write the skill. Most people stop at the second.

The interesting part happened in the same session. While building the pipeline, I recognised the deployment step as something I’d done before — for someone else’s site. That’s a service, not just a workflow. Three hours later, a service page was live offering website builds.

The business insight came from watching the automation at a level of detail you only see when you’re building it from scratch. If you’d handed the task to an existing tool, you’d never have seen the pattern.

Skill first. Then look at what the skill is actually doing.