What this guide is, and is not
This is a field guide for operators thinking about Claude Skills inside their business. It tells you what a Skill is, what categories of task become Skills first, where Skills go wrong, and what to demand of anyone (Gibson included) building them for you.
This is not a build playbook. The actual prompts, configs, model-selection logic, and deployment pattern that Gibson uses internally are proprietary. You won't finish this guide with a clone of our work. You will finish with the diagnostic to evaluate any Skill build, including the one you might pay us for.
What a Skill actually is
A Skill is a packaged, repeatable capability that Claude can invoke against your business. Not a prompt. Not a chat. A Skill has a defined input, a defined output, a defined permission surface, and lives inside your workflows the way a member of staff would.
The difference matters. A prompt is a conversation, owned by whoever types it. A Skill is an asset, owned by the business. Skills get versioned, evaluated, deployed, and rolled back. Prompts get forgotten in someone's chat history.
Which categories of task Skill up well
Not every task is a Skill candidate. The good ones share four traits.
- +Repeatable. Same shape of input, same shape of output, dozens of times a week.
- +Reviewable. A human can tell at a glance whether the Skill got it right.
- +Reversible. If the Skill gets it wrong, the cost of fixing it is small.
- +Boring. Operators don't want to do it, and humans do it inconsistently.
Where Skills go wrong
Most Skill projects fail in one of four ways. None of them are a Claude problem. All of them are a build problem.
- +Wrong task. The team picks a creative, judgment-heavy task as their first Skill. It produces output nobody trusts. The whole programme gets tarred.
- +Wrong permissions. The Skill is given write access on day one. It writes something wrong. Trust dies before it was earned.
- +No evaluation harness. The Skill ships without a way to measure whether it's getting better or worse over time. After a month nobody knows if it's helping.
- +No fallback. The Skill becomes a single point of failure. When it breaks, the team has no manual recovery path.
What to demand of any Skill build
If you commission a Skill build from Gibson, an agency, or an internal team, these are the non-negotiables.
- +A read-only first week. The Skill drafts, the operator reviews and ships. Trust before automation.
- +An evaluation set. A set of 20+ real examples with known good outputs. The Skill is graded against this set before any deploy.
- +A reversal path. A clear, fast way to undo anything the Skill writes back to your systems.
- +A cost ceiling. A monthly spend cap, enforced at the API layer, so a runaway loop can't cost you thousands.
- +A handover document. A description of what the Skill does, how to monitor it, and what to do when it breaks.
Where the value flows
A well-built Skill stack changes the shape of the business, not just the inbox.
- +Operations: the owner stops doing the repeatable work that drains the day.
- +Data quality: every Skill interaction becomes a logged event the rest of the business can read.
- +Sales: faster response on high-intent enquiries because the triage Skill caught them.
- +Customer engagement: dormant signals that humans would miss surface as inputs to Reignite.
Want us to build it for you?
If reading this you've spotted the bottleneck in your business but you don't want to learn the toolchain, we run the build. From $1,000 for the 48-hour working prototype. Production-grade engagement scoped after the diagnose call.
Book a 30-min diagnose call from the Sandbox page.