Case study — client-operated ai skill libraries

Client-Operated AI Skill Libraries

The hard part of AI adoption isn't using it yourself. It's handing a non-technical team AI they can run without breaking anything. I package agency capabilities as governed 'skills' a client's own staff run from the Claude desktop app: draft a blog post, a Klaviyo email, a social calendar, a landing page, a design. Every one is grounded in the brand's approved facts, gated on a human decision, and can only produce a draft: never send, never publish, never touch anything live.

operator skills

draft-only

every output

human

gate on every run

self-refining

via a polish skill

in practice

What it's actually like to use

Someone on the client's team, not an engineer, opens the Claude desktop app and types "draft an email" or "write a blog post." A skill runs the whole job: it reads the marketing calendar, pulls the brand's approved voice, claims, and red-lines from a reference doc, researches, drafts against a quality rubric, critiques its own work, and saves a draft in Klaviyo or Shopify. It never sends, never publishes, never posts. The person reviews it and ships it. I'm not in the loop.

That's the whole point. Anyone can prompt a chatbot; the value is a repeatable, safe way for a small team to get agency-quality work out of AI without knowing anything about prompting, and without a wrong click sending a half-finished email to the whole list. It's the same pattern deployed across more than one client, with a setup skill that onboards each new person and a polish skill that keeps the library sharp.

This is what AI adoption actually is: not a clever prompt, but the guardrails, grounding, and onboarding that turn a capability into something a non-technical team can run every day and trust.

The practical outcome: client teams ship their own weekly blog posts, emails, and social content with no engineer in the loop.

architecture

How a skill runs, and how it stays reliable

how a non-technical operator runs a skill

the operator

Types "write a blog post" in the Claude desktop app. No prompt-crafting, no setup.

the skill runs the whole job

1Read the topic sheet — pulls candidate topics + what’s already been done from a Google Sheet
⏸GATE — the operator picks — presents options and waits; does not start until a human chooses
2Research the web — keeps a source URL for every fact it intends to use
3Write under guardrails — brand facts locked; no stat without a source; no AI tells
→Save as a draft — pushes to Shopify as a draft — never publishes

The operator reviews the draft and clicks publish. The human ships; the skill never does.

how the skills stay reliable — the polish meta-skill

RUN→CRITIQUE→EDIT↺ ×3–5

RUNexecute the skill for real — but dry-run every irreversible step, and vary the inputs each round
CRITIQUEhunt broken links, wrong sheet/tab names, ambiguous steps, weak output
EDITtighten the skill’s instructions; hand back a hardened version + a changelog

▪ human-gated▪ draft-only — no irreversible action▪ self-refining, dry-run tested

Skills, not prompts

Each skill is a Markdown file with a name, trigger phrases, and a full procedure, packaged so a non-technical operator invokes it by plain request in the Claude desktop app. No prompt-crafting, no setup ritual; the skill runs the entire job end to end.

Draft-only, never irreversible

The load-bearing guardrail. Emails save as Klaviyo drafts: never sent, never scheduled. Blog posts and pages land as Shopify drafts. New theme sections go to a non-live theme. Social plans are drafts a human approves. A wrong click can't reach a customer.

Grounded in approved facts

Every content skill pulls the brand's voice, approved claims, and explicit red-lines from a source-of-truth reference doc, and copy has to trace back to those claims. It's the anti-hallucination spine: the skill can't invent a health claim or a statistic it wasn't given.

Self-critique before handoff

Skills study a gold-standard example, draft against an explicit rubric, then grade their own output before handing it over. The design skill literally renders to an image, looks at the pixels, critiques, and re-renders. It never ships its first attempt.

Onboarding built in

A setup skill walks a new team member through every dependency a skill needs (connectors, doc access, installs) using read-only probes. It never auto-installs or authenticates for you; it tells you exactly what to connect so the first run just works.

A skill that hardens skills

The polish skill runs another skill several times, dry-running every irreversible step and varying inputs, hunts broken references and weak output, and rewrites the skill tighter each round, so the library improves with use instead of quietly rotting.

the library

What a client team can run themselves

A library grows per client, but the shape is consistent: content, storefront, design, and the two meta-skills that onboard people and keep the rest reliable. Every one ends in a draft a human reviews.

Content drafting

›write-blog-post — researched SEO post → Shopify draft
›create-email-campaign — Klaviyo campaign saved as draft — never sends, never schedules
›plan-social-calendar — IG/FB/TikTok plan → drafts, approval-gated — never auto-posts

Site & storefront

›create-landing-page — composes existing theme sections into a pillar page — never writes new code
›add-theme-section — new section added to a non-live theme — never touches the live site

Design collateral

›design-card-or-onepager — renders to pixels, looks, critiques, re-renders — never ships v1

Enablement & upkeep

›setup — read-only dependency check so a new teammate can get running
›polish — self-refinement loop that hardens the other skills

self-referential skills

Two of the skills exist to maintain the other skills

Most of the library does client work. Two skills do work on the library itself. They're how it stays correct and keeps getting better without me babysitting it. It's a pattern I lean on everywhere: wrap the real work in a checking loop rather than trusting a single pass.

setup enforces correct tooling. Before a skill runs, it reads that skill's dependency list and probes every one (connectors, shared docs, local installs, tenant IDs) with read-only checks, then hands the operator the exact next click. It distinguishes a missing connector from a doc that simply isn't shared with that person's account, and it catches the failure in a 30-second probe instead of five minutes into a half-written post. It never fixes anything itself. It's "the diagnosis, not the cure."

polish increases quality. It improves a target skill by running it, critiquing it, and rewriting it over several rounds, dry-running every irreversible step so it can stress a skill without side effects. And the two compose into a self-maintaining loop: when setup finds a skill pointing at a doc or table that no longer resolves (skill drift), it refuses to green-check it and routes the fix to polish. polish tightens the skill, setup re-verifies. The library diagnoses and repairs itself.

A skill that improves other skills, and one that vets them

The same multi-pass, self-critiquing loop shows up across everything I build: the research engine re-synthesizes until a quality gate passes, the agent fleet grades its own output before it ships, the design skill renders and re-renders. Here it's turned inward: the tooling that keeps the tools honest is itself a skill, versioned and improvable like the rest.

engineering highlights

The parts I'm proud of

The dangerous verbs are banned in the skill's own header

Each skill's description (the first thing the model reads) states its hard limits in capitals, so the constraint is loaded before any work begins. The safety isn't a hopeful line buried in step 9; it's the skill's identity.

Fig. — from real skill headers

create-email-campaign:  "…saves it as a DRAFT. NEVER schedules. NEVER sends."
add-theme-section:      "…adds it as a draft to a non-live theme. NEVER writes to the live theme."
plan-social-calendar:   "…NEVER auto-posts. NEVER writes to Supabase without explicit user approval."
setup:                  "Read-only probes only. NEVER auto-installs, NEVER auto-auths."

Grounded in approved claims, not the model's imagination

For a supplement brand, an invented health claim is a legal problem, not a typo. So content skills are wired to a brand-reference doc and forbidden from stating anything that doesn't trace back to it, the same rule the blog skill enforces on statistics: no source found this session, no number in the post.

Fig. — anti-hallucination rule (blog skill)

Never state a statistic or specific claim you didn't find in research this session.
No source URL for a number → cut the number.
Everything about the brand (price, contents, claims) must match the reference exactly.

It refuses to ship its first draft

The design skill builds HTML, renders it to a real PNG with headless Chromium, then looks at the actual pixels, critiques the layout, and re-renders. A loop, not a one-shot. The email and page skills do the text-level equivalent: draft, self-grade against a rubric, revise, then hand off. "Never ship version 1" is written into the skills.

Enablement is the deliverable, not the model

The valuable artifacts here aren't clever prompts. They're the onboarding path (setup), the operating rhythm (a plain-English cadence guide: what to run daily, weekly, monthly), and the maintenance loop (polish). That's what makes a team independent of me, which is the actual goal of adoption work.

stack

Built with

Claude skills (Markdown definitions with trigger phrases, run in the Claude desktop app) · Shopify (draft posts, pages, non-live theme sections) · Klaviyo (draft campaigns) · Google Sheets & Docs (topic engine + source-of-truth brand reference) · Supabase (approval-gated social placements) · Playwright headless-Chromium render loop for design output · web search for research.

Deployed for real client teams; brand names are abstracted here, and the skill structure, guardrails, and excerpts are shown as built.

← All projects