Your prompt library is quietly failing you
Every product marketing team I talk to has one: a document of prompts. "Ten prompts for positioning." "The mega-prompt for case studies." Collected from LinkedIn, pasted into a doc, shared in Slack with good intentions. Six months later, someone has updated the product and the prompts don't know it. Someone has improved a prompt in their own chat window and the doc never heard about it. Nobody can say which version is current, and everyone is quietly back to improvising — pasting, re-explaining context, and hand-fixing the output, every single time.
The problem is not the prompts. It is the format. A prompt is text you carry to the tool by hand. It has no version, no owner, no guardrails, and no memory of what good output looks like. You are still doing the work; the prompt just starts the conversation.
A skill is different. A skill is a documented procedure your AI assistant loads and runs when the job calls for it — written once, versioned like software, improved in one place, and carrying its own rules about what it will and will not do. Install it once, and "draft the case study" stops being a twenty-minute prompt-wrangling session and becomes the procedure running, correctly, in the background of your day.
I spent the last three years building AI systems that ran go-to-market work in production. This page is four of the procedures I believe in most, rebuilt as free, installable Claude Skills — with the discipline that made the originals work baked into each one. The payoff is not "better AI output." It is hours back per deliverable, and deliverables you could never justify doing manually — per-deal positioning, a case study for every win — suddenly cheap enough to do every time.
What a skill is, in thirty seconds
A skill is a folder containing instructions your AI assistant reads when a task matches — how to do the job, what inputs to demand, what rules never to break, what the output should look like. You install it once. From then on, "build a positioning table for this deal" doesn't start from a blank page or a pasted mega-prompt; it runs your team's actual procedure, the same way, every time.
Three properties make skills worth the switch. They are versioned — improve the file and every future run improves with it. They are opinionated — a good skill refuses to do the job badly, and the refusals are where the craft lives. And they are shareable — installing one takes a minute, so a team can standardize on a procedure instead of on a rumor of one.
The four below are free, MIT-licensed, and ungated. Each one is distilled from practice with real results behind it — not hypothetical best practices.
Four skills, one discipline
Each one is built for a business outcome — hours back per deliverable, and work that used to be reserved for marquee moments done at scale. And all four share one discipline: none of them will invent what they do not know. Facts in, work out, unknowns escalated to humans. That is what makes the output usable in front of a buyer, an engineer, or a customer's legal team.
Case studies that survive the skeptical read
The impact: in my use it cuts the time to a publishable draft by 80–90% — which is what finally makes a case study for every win practical, not just for the marquee accounts. The built-in claims audit also shortens the approval cycle, because customer and legal review get a document that pre-answers their questions.
Drafts impact-first case studies — measurable result in the title, hero metrics up top — from the inputs teams actually have: interview transcripts, CSM notes, Slack threads, usage data, CRM records. Every number must trace to a source that can support it; a CSM's "they said pipeline doubled" becomes a question for the customer, never a claim in the draft. Ships a claims-audit table with every draft, and runs audit-only on case studies you already have.
out: impact-first draft · claims-audit table · questions grouped by owner (customer / CSM / analytics)
Distilled from case-study work I contributed to across enterprise SaaS, and the claim-qualifier discipline that runs through my own published record.
Release notes a reader can act on
The impact: release comms in minutes instead of a day of Slack back-and-forth — and fewer support tickets, because notes never promise behavior the release doesn't deliver.
Turns raw engineering notes into clean, audience-correct release notes — classified, breaking changes first, written separately for admins, end users, and developers where their realities diverge. The rule that matters: it never announces behavior the notes don't establish. Ambiguity goes back to engineering as a pointed question, not forward to customers as a guess.
out: per-audience release notes · questions for engineering · changelog, email, and in-app variants on request
Distilled from owning technical writing for a product's most technical surfaces — endpoint agent, admin console, automation engine, and public API — where release notes shipped ahead of schedule.
What the buyer actually said they need
The impact: an hour of transcript re-listening becomes a two-minute read — and the requirement everyone missed on the call gets caught, attributed, and timestamped.
Feeds on raw Gong, Chorus, or Zoom transcripts — filler, crosstalk, and all — and extracts the buyer's evaluation criteria in their own words, attributed and timestamped. Seller speech is context, never data, so vendor pitching can't leak into the requirements. Adds a MEDDIC-style summary built only from evidence, with honest "not established" gaps, and flags an unnamed competitor as the deal's most expensive open question.
out: stated criteria, attributed · [inferred] signals, quarantined · MEDDIC-style summary · competitor status
Distilled from the account-intelligence and MEDDIC-analysis agents I built and ran in production.
The deal's battle card, generated honestly
The impact: per-deal competitive strategy in minutes instead of hours — so it happens on every deal, not just the ones big enough to justify an afternoon of analysis.
Turns a buyer's stated criteria, the named competitor, and your documented competitive facts into an account-specific positioning table — six columns from the buyer's words to the proof to show in the demo. It will not invent a competitor weakness or position on a capability you didn't name; rows it cannot anchor in fact go to an escalation list for your team to solve. Ships with a competitive knowledge-base template.
out: six-column positioning table · unknowns escalated with owners · demo/committee/POC outlines on request
Distilled from the method in Kill the Battle Card — the practice behind it held a ~74% win rate on $30K+ enterprise deals where the competitor was known (no-decision outcomes excluded).
Install once, about a minute
No engineering help needed, and no command line for the claude.ai path. Each repo contains the same three things: the skill, a worked example, and a packaged .skill file for upload.
Claude.ai — where most marketers work
- Open the skill's GitHub page and download the
.skillfile (one click — it sits at the top level of each repo). - In claude.ai, open Settings → Capabilities, find Skills, and upload the file.
- That's it. Next time you ask for the job — "build a positioning table for this deal" — the skill runs.
Claude Code — if you work in the terminal
- Download or clone the repo from GitHub.
- Copy the inner skill folder into
~/.claude/skills/. - Start a new session — the skill triggers when the job matches.
Everything is MIT-licensed. Adapt the procedures to your team — that is the point of a skill over a prompt: yours to version.
Why this compounds
The four skills share one dependency, and it is deliberate: they consume your facts. The positioning skill reads your competitive knowledge base. The criteria skill reads your call transcripts. The case-study skill reads your customer evidence. None of them substitutes the model's general knowledge for your team's documented truth — which means every fact you write down makes every future run better.
That is the compounding loop I described in Kill the Battle Card: a fact-anchored knowledge base at the center, AI doing the retrieval and drafting, humans solving what is genuinely unknown — and each solved unknown written back, so the next deal inherits it. The white paper is the method. These skills are working pieces of it, sized for a team of one to start using this week. And when you are ready to wrap a skill in a goal, an eval, and an escalation path, that is loop design — the general case.
Start with the pair that moves win rates: buyer-criteria-skill on your next competitive deal's transcripts, then positioning-table-skill against your best-documented competitor. The other two earn their keep the first week you ship a release or draft a case study.
Free, ungated, versioned
I am Daniel Glickman, a product marketing and AI leader. I build the AI systems that run go-to-market rather than only talk about them — work the Product Marketing Alliance recognized with its 2024 AI Marketing Innovation Award. These four skills are that work, distilled into something you can install before your next call.
Take them, adapt them, and send this page to whoever runs product marketing in your organization. If you want to talk about applying this — to your team, or to a role — leave your email below and I will follow up. No gate, no sequence.