The Skill Was the Product

Stores were about to run segmented incentive campaigns no channel could cleanly announce: third-party messages got lost or blocked. Unexpected, urgent — and the fix lived outside our roadmap.

That fix was a popup showing each store its own campaign image, on a frequency the business could control. Built in full, this is a big feature — screens for operations to create campaigns, upload images, assign stores, manage every cycle. Neither the timeline nor the mandate allowed for that: the brief was a lean MVP the owning team could extend later. So I cut the scope deliberately — the minimum a store needs to see, and none of the machinery operations would use to manage it.

I shipped that slice in three PRs. But the real work was hiding in the piece I cut: who configures the entangled campaigns?

A feature only its author can operate is a dependency, not infrastructure

Configuring one campaign looked like this: convert a batch of images to web formats and generate their placeholders, resolve every store name into its internal identifier across two systems, then build the targeting segments by hand in the feature flag platform — one per campaign, each pointing at exactly the right list of stores. Every step in a precise order, and most mistakes failed silently.

The standard answer to a process like this is an admin system — entities to store campaigns, APIs to manage them, UIs on top. An honest estimate put it at three weeks of work, at least. Nobody had those three weeks.

Which left the uncomfortable default: I run the process. The feature would work, but only through me: a bus factor of one, disguised as a shipped feature.

The skill replaced the UI, not the runbook

My first instinct was to write a runbook. But a runbook trusts the reader to catch what the author knows to fear — and the dangerous steps in this flow don’t look dangerous. The worst one looks like success: the platform accepts your configuration, everything reads valid — and stores open the app to a popup rendering undefined in their face.

What the flow actually needed was judgment at specific checkpoints. Validate inputs before touching anything — in this system, an image’s filename is a contract: its parts travel on as analytics properties that measure each campaign by variant and tier. Stop before every destructive step. Name the known traps at the moment the operator is about to walk into one. A document can describe all of that; it can’t enforce any of it.

So I wrote the process as a Claude skill — a small engineered package, not a prompt. A procedure file orchestrates the flow and defines every checkpoint. A set of scripts does the deterministic work — image conversion, placeholder generation, segment configuration — because anything with one correct output belongs in code. A layer of reference documents carries the domain knowledge: the naming contract, the identifier mappings, the traps.

store-campaigns-skill/
├── SKILL.md                  (the procedure — full flow, every checkpoint)
├── references/
│   ├── naming-contract.md    (filename grammar → routing + analytics)
│   ├── store-mappings.md     (store names → internal identifiers)
│   └── known-traps.md        (failure modes and when they appear)
└── scripts/
    ├── convert-images.py     (web formats + placeholders)
    └── configure-segments.py (segments per variant in the feature flag)

The split is the design: code where precision matters, language where judgment matters, and hard stops wherever a human must own the decision.

Proof: someone else ran it, live

A tool like this proves itself in exactly one way: someone who didn’t build it runs it, under real conditions, without you steering. So when the next campaign cycle arrived, I set up a call with the team that needed it. My introduction took a couple of minutes — what the skill does, where it lives, how to call it. Then a developer who had never touched the flow took over. In less than fifteen minutes he had configured the real campaign — images processed, stores resolved, segments generated — with the checkpoints stopping him exactly where a human decision was required.

His verdict at the end: this was easy enough that the operations team could run it without a developer. That was too optimistic — some steps still need access only engineers have — but the comment itself was the signal. Configuration had stopped being specialized knowledge and become a procedure.

And once running a campaign cost almost nothing, the feature outgrew its first client. Other teams realized they had the same need — a message, targeted per store, without building anything — and three have adopted it since, with five real campaigns configured and shipped through the skill. The lean MVP became a shared channel, because operating it no longer required me.

The part I keep coming back to

Here is the part I keep coming back to. The feature took three PRs. The skill took a few days. Yet the skill is the reason any of this mattered: without it, a working feature would have sat behind a flow only one person could run — and features like that don’t scale, they wait.

We tend to measure delivery by what we ship. This project convinced me to also measure it by what we can hand over. The admin system nobody had three weeks for never got built — and it wasn’t the missing piece after all. The missing piece was making the judgment portable. Once it was, the product stopped needing its author. That was the moment it became infrastructure.

Place your bet: does the admin system ever make it onto the roadmap — or has the skill made it permanently unnecessary? And if it’s the latter, how many of the admin tools being built right now are next?