The prompt library is the new battle card
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 — and then it decays, exactly the way battle cards decay. Someone updates the product; the prompts don't notice. Someone improves a prompt in their own chat window; the doc never hears about it. Six months in, nobody can say which version is current, and everyone is quietly back to improvising.
The problem is not the prompts. It is the format. A prompt is text you carry to the tool, every time, by hand. It has no version, no owner, no guardrails, and no memory of what good output looks like. It is advice, wearing an AI costume.
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. The difference between a prompt library and a skill stack is the difference between a stack of sticky notes and running infrastructure.
I spent the last three years building AI systems that run 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.
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
The through-line: none of these will invent what they do not know. Facts in, work out, unknowns escalated to humans. That discipline is what makes the output usable in front of a buyer, an engineer, or a customer's legal team.
The deal's battle card, generated honestly
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).
What the buyer actually said they need
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.
Release notes a reader can act on
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.
Case studies that survive the skeptical read
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.
Install once, about a minute
No engineering help needed. Each repo contains the same three things: the skill, a worked example, and a packaged file for upload.
Claude Code
- 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.
Claude.ai
- Download the
.skillfile from the repo (it is a packaged copy of the same skill). - Upload it where packaged skills are accepted in your workspace's capabilities settings.
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.
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.