The stack
- Tooling
- a Claude plan that supports Skills
- First Skill
- about half a day to package one play well
- Per use
- a normal Claude request; no per-run tooling bill
- The payoff
- every rep runs your best play at your best quality
The problem
Every GTM team has a few plays that one person runs brilliantly: the account brief that actually preps a call, the battlecard that wins the bake-off, the follow-up that gets replies. And every team has the same problem: that play lives in one person's head and one clever prompt saved in their personal notes. When they are out, or when a new hire needs it, the quality falls off a cliff. Call it prompt debt, every sharp one-off prompt your team cannot reproduce next quarter.
The usual fix is a wiki page titled 'How to write a good account brief', and it dies the same death every wiki dies: nobody reads it in the moment they need it, and it drifts out of date the week after it is written. A document describing the play is not the play. What you want is the play itself, executable, on hand the second a rep needs it, producing the same structured output every time.
A Claude Skill is exactly that: a packaged, reusable capability, the instructions, the format, the examples, the guardrails, that Claude loads when the task calls for it. You encode your best account-brief play once, as a Skill, and now every rep's Claude runs your version, not their improvised one. The good prompt stops being tribal knowledge and becomes shared infrastructure, versioned like anything else that matters.
How it works
- 01 Find the play Yourepeatable, high-value, done well by one person
- 02 Write the SKILL.md Claude Skillssteps, output shape, example
- 03 Encode the judgment Youthe instincts a new hire lacks
- 04 Bake in guardrails Claude Skillsvoice, banned words, verify flags
- 05 Share to the team Every rep's Claudetriggers on demand, same every time
- 06 Version it Youimprove once, ships to everyone
- Find the play worth packaging: repeatable, high-value, and run well by your best person today
- Write it as a Skill: the instructions, the output format, a worked example, and the guardrails
- Encode the non-obvious judgment, the things your best rep does that a new hire would not
- Bake in the voice and format rules so every output is consistent and on-brand
- Share the Skill with the team so everyone triggers the same play on demand
- Version it as the play evolves, so an improvement ships to everyone at once
The playbook
Find the play worth packaging
Look for the work that is repeatable, high-value, and currently done well by exactly one or two people. The account brief before a first call, the competitive battlecard, the post-call follow-up, the discovery-question set for a segment: these are plays with a right way to do them that most of the team does inconsistently. That gap between your best person and the median is exactly what a Skill closes.
Skip the one-offs. A Skill earns its keep on work that recurs across the team; a task you do once a quarter is not worth packaging. The question is not 'is this useful', it is 'do many people do this often, and badly'.
Grab the raw material: the best existing prompt for it, a couple of genuinely good past outputs, and whatever format or checklist your strong performer uses in their head. That is the seed of the Skill.
TipThe best Skill candidates are the plays where you can already point at one person and say 'do it the way they do it'. You are bottling that person's version, not inventing a new one.
Write the play as a Skill
A Claude Skill is a folder with a short instruction file (a SKILL.md) plus any supporting assets, that Claude loads on demand when the task is relevant. Write the SKILL.md as the play: what the task is, the exact steps, the output structure, and a worked example of a great result. The example does a lot of the teaching; show, do not only tell.
Structure the output explicitly, because consistency is half the value. If the account-brief Skill always returns the same sections, snapshot, priorities, where-we-fit, people, openers, then every rep's brief is comparable and scannable, and a manager can read any of them in ninety seconds. Pin the shape.
Keep the SKILL.md tight and let progressive disclosure do its job: the short description sits in context, and Claude reads the full detail only when the task calls for it. You are writing a sharp brief, not a manual.
---
name: account-brief
description: Turn a company name or URL into a first-call account brief. Use when a rep is prepping for a discovery or first sales call.
---
# Account Brief
When the user gives you a company (name or URL), produce a first-call brief.
## Steps
1. Use web search to gather current, cited facts: what they do, size, HQ, most recent funding, news from the last 6 months, stated priorities, and leaders relevant to {{DEPARTMENT_WE_SELL_TO}}.
2. Map their likely pains to OUR product (see product-context.md).
3. Produce the brief in the exact structure below. Use ONLY cited facts; mark inferences [inference] and gaps 'unknown'.
## Output structure (always these sections, under 350 words)
- Snapshot (what/size/most recent dated event)
- Likely priorities (3 bullets, each tied to a cited fact)
- Where we fit (map their pains to our product; if not a fit, say so)
- People to know (only names found in the facts)
- Three opener angles (each on a real dated fact)
## Guardrails
- Never invent an executive name. Flag any name to verify with [verify].
- No hype words: unlock, leverage, supercharge, seamless, game-changer.TipPut the shared context (your product description, your ICP, your voice rules) in a file the Skill references, so you update it in one place and every play that uses it stays current.
Encode the judgment and the guardrails
The reason your best rep's brief is better is judgment: they know twelve open AE roles implies a ramp problem you can speak to, and they know never to say an executive's name they have not verified. Write those moves into the Skill explicitly. A Skill that only lists steps produces a mechanical output; a Skill that encodes the judgment produces your best person's output.
Bake in the guardrails that keep the output safe and on-brand: the banned hype words, the 'mark anything you are unsure about', the 'if it is not a fit, say so honestly'. These are the rules your strong performer follows by instinct and a new hire does not know yet. The Skill is where instinct becomes a rule everyone inherits.
Include one or two real, great outputs as examples in the Skill. Models learn the bar from a concrete example faster than from a paragraph of description, and the example silently carries your standard for 'good'.
Share it, then version it
Publish the Skill to the team so it is available in everyone's Claude, and it triggers automatically when the task is relevant, no one has to remember a prompt. The play stops being something a rep reconstructs from memory and becomes something their Claude just does, the same way every time.
Version it like the asset it is. When you learn something, a sharper opener structure, a new guardrail, a better example, update the Skill once and the improvement ships to the whole team at their next use. Compare that to a wiki edit nobody sees, or a better prompt that stays in one person's notes.
Keep an owner. A Skill is shared infrastructure, so someone owns 'what good looks like' for that play and shepherds its versions, exactly as they would own a battlecard or an email template. The difference is this one runs itself.
What you get
Before and after: the same account-brief play as tribal knowledge, then as a shared Skill.
BEFORE (prompt debt):
- Priya writes brilliant account briefs from a 600-word prompt saved in her personal notes.
- Everyone else writes theirs from scratch, inconsistently, or skips it.
- Priya is out for a week -> brief quality falls off a cliff.
- A new SDR has no idea the good prompt exists.
AFTER (a shared 'account-brief' Skill):
- Every rep types 'brief me on Northbeam Data' and their Claude runs Priya's play: web-searches, maps to product, returns the same five sections, flags unverified names, obeys the voice rules.
- New hire on day one produces a brief at the team's standard.
- Priya improves the opener structure once; the Skill ships it to everyone.
- The play is now infrastructure, not tribal knowledge.Pitfalls to avoid
Packaging a one-offA Skill earns its keep on work many people do often. Bottling a task you run once a quarter is effort with no payoff. Package the plays with a real gap between your best person and the median.
Steps without judgmentA Skill that only lists mechanical steps produces mechanical output. The value is encoding what your best rep actually knows, the inferences and the instincts, not just the sequence. Write the judgment down.
No worked exampleDescribing 'a good brief' in prose teaches the model less than showing it one. Put a real, great output in the Skill; the example carries your standard for good more reliably than any instruction.
Set it and let it rotAn unversioned Skill drifts out of date like any asset. Give it an owner and update it as the play improves, so a better version ships to everyone instead of dying in one person's notes.
Skipping the guardrailsWithout the voice rules and the 'verify this' flags, a shared Skill scales your mistakes as fast as your wins. Bake in the banned words, the fact-checking flags, and the honesty rules that your strong performer follows by instinct.
Questions people ask
- What is a Claude Skill, in plain terms?
- A packaged, reusable capability: a short instruction file plus any supporting assets that Claude loads on demand when a task is relevant. Instead of a rep pasting a clever prompt they may or may not have, their Claude just knows how to run the play, the account brief, the battlecard, the follow-up, at your team's standard. There is a fuller walkthrough in the Skills section at /skills/.
- How is a Skill different from a saved prompt or a Claude Project?
- A saved prompt lives with one person and gets pasted by hand. A Project is a persistent workspace for one person's ongoing work. A Skill is shared infrastructure: it packages a play, triggers automatically when the task fits, ships to the whole team, and is versioned so an improvement reaches everyone at once. The point is to move a play out of one person's head and make it the team's.
- Which GTM plays are worth turning into Skills first?
- The ones with the biggest gap between your best performer and the median, and that recur across the team: account briefs, competitive battlecards, post-call follow-ups, segment-specific discovery questions. If one person does it brilliantly and everyone else fumbles or skips it, that is your first Skill. One-off tasks are not worth packaging.
- Do I need to be technical to build one?
- No more than writing a good, structured prompt. A Skill is mostly a clear instruction file: the steps, the output shape, a worked example, and the guardrails. The hard part is not technical, it is the same hard part as good enablement, being precise about what 'good' means and writing down the judgment your best rep applies without thinking.