
asb-carol-keystones
Facilitates the third step of a proven ideal-customer (ICP) method: refining classified strengths into keystones — the specific characteristics, behaviors, or circumstances that make a customer NEED an extreme version of a strength, badly enough to drive the purchase alone. Takes a strengths chart (S1, S2, … — file or pasted), walks the strengths one at a time asking who requires an extreme version of each, gates every candidate on naming a real market segment that typifies it (no segment = table stakes, cut), and records survivors in KEYSTONES.md (K1, K2, … with [S] references and example segments). Delivers the strategic verdict when few or none survive: the product isn't compelling yet. Load when the user has classified strengths and asks who needs them, who their target market is, or 'turn our strengths into keystones.' Do NOT load to classify strengths and weaknesses (the previous step), to derive deal-breakers or the anti-market (the next step), or to write the final ideal-custom
- Installs
- 637
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/asmartbear/asb-skills --skill asb-carol-keystones- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads asb-carol-keystones automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Keystones: Who Needs an Extreme Version of What You're Best At
Passionate purchase decisions don't come from sort-of liking a few features. They come from an overwhelming pull toward one of your strengths — something specific about the customer's circumstances that makes them think "I've got to make this work for us." That pull is a keystone, and mapping your keystones is how a strengths chart becomes a target market. This skill walks the strengths one at a time, generates keystone candidates with the user, and holds each to the gate that separates keystones from wishful thinking: a real market segment must typify it.
The mental model
What a keystone is
A keystone is the critical characteristic that drives a customer's desire for the product — the thing that grabs their attention even in a noisy world, even while other trade-offs are in flux. It is not the strength itself; it is the customer circumstance that makes the strength critical. "Fast website" is a strength. "Has a website where even 0.1 seconds faster directly results in more revenue" is a keystone — and it immediately names its market: e-commerce stores, where studies put conversion of fast sites at multiples of slow ones, and where the giants have measured revenue loss per tenth of a second of load time. Same pattern across a real keystone chart: "scalable" becomes has traffic spikes at unpredictable times (news sites whose story can break any moment); "secure" becomes just got hacked and is still terrified or has a legal mandate for vendor certifications (the regulated industries); "inexpensive to build on" becomes big plans, limited budget (every small business, every "do more with less" marketing department).
The generative question
For each strength, ask: what characteristics, behaviors, or circumstances REQUIRE an extreme version of this strength? Imagine the customer for whom this strength is absolutely critical to their strategy — or so delightful it pulls them in through pure joy. Require is the operative word: a circumstance that merely prefers the strength generates a trade-off shopper — a buyer who weighs your strength against a competitor's and picks whoever wins the spreadsheet — not a keystone that drives a sale by itself. (Trade-off shoppers are a fine, large audience; the method's point is that targeting the keystone customer is what wins them too.)
The gate: no segment, no keystone
After naming a keystone candidate, describe real-world examples of companies or people who embody it. If you cannot name a significant market segment that typifies the keystone, it isn't a keystone — the strength is probably table stakes: true, useful, not compelling enough to drive a purchase alone. That's fine — that's why it's called brainstorming — but the candidate is cut, on the record, not recorded hopefully. The segments named should be described by circumstance and behavior ("e-commerce stores where speed measurably moves revenue"), not raw demographics; the sharper the description, the more useful every downstream step becomes.
Keystones concentrate in the head, not everywhere
You won't find keystones by asking what your best customers have in common — most of that is common to all your customers, including the worst. A trait that describes everyone predicts nothing about buying, paying, or staying. The right keystones concentrate in the best customers and show up weakly, or not at all, in the bad ones. If the strengths chart carries a best-vs-worst differential, mine it: the differences are where keystones live.
The one-keystone verdict
If the walk ends with one keystone — or none — that is not a failed exercise; it is the most valuable strategic lesson available: the product isn't compelling yet. Say it plainly, because learning it now is a multiplier — fixing it increases sales, and it was hidden. The twofold response, from the source: (a) increase marketing spend in the markets where keystones DO exist (with zero keystones, this half is empty and the verdict says so), and (b) use market and customer research to determine what to build next that would address a real keystone. Don't pad the chart to avoid the verdict — and don't pick what to build yourself: a feature chosen from inside the strengths chart is an invented keystone, exactly the wishful thinking the gate kills. With one survivor, phrase it precisely: compelling to that one segment only.
Why this is worth doing at all
The customers keystones find are the head of the profit distribution — in the canonical case, roughly 5% of customers producing 40% of profit, which justifies spending many times more to acquire each one. The keystone chart is the map to exactly those customers.
Vocabulary
- Keystone (K1, K2, …) — a customer characteristic, behavior, or circumstance that requires an extreme version of a strength; cites its [S-number].
- Example segments — the real-world companies or people who typify the keystone; the gate every keystone must pass.
- Table stakes — a true, useful strength that compels no one by itself; recorded as a cut, not a keystone.
- Requires vs. prefers — the bar: a keystone circumstance makes the strength critical, not merely nice.
The refiner's posture
Be clear, not clever
Write to be understood, not admired. The work here wrestles with hard concepts, and clever metaphors, wordplay, or cute turns of phrase make them harder to grasp, not easier. Say plainly what you mean. If a sentence reads more clearly without a flourish, cut the flourish. State the actual point rather than gesturing wittily at it.
Restate references; never cite a bare token
When you mention a numbered or lettered item to the user — K4, W2, O17, H3, and the like — add a few plain words on what it actually is ("K4 — the owner whose career rides on the site"). A bare token is unreadable to a human who saw it defined hours or days ago: the tag is for traceability, the gloss is for comprehension. Keep the tag for accuracy; always add the gloss.
Generate freely; gate ruthlessly
Keystone-finding is brainstorming — propose candidates yourself,
liberally, alongside the user's: the imaginative leap from "strength"
to "whose circumstance requires this" is exactly where an outside
perspective helps. But every candidate, yours or theirs, faces the
same two tests before recording: does the circumstance require the
extreme version (not merely benefit from it), and can a significant
real segment be named that typifies it? Run both visibly. A
predefined way to press harder: if a devil's-advocate interrogation
skill is installed in the environment (for example Rude Q&A /
asb-rude-qa, from the same author as this method), invoke it
against the draft keystone chart with this brief: attack these
keystones — find every one whose segment is vague, tiny, or invented;
every one where the circumstance merely prefers the strength rather
than requiring it; every segment described so broadly it describes
everyone. Don't accept wishful or hand-wavy defenses. If no such
skill is available, run that interrogation yourself, visibly — the
per-candidate tests inline, the batch attack at the closing sweep.
Press segment descriptions into specifics
"Small businesses" is not a segment description; "e-commerce stores processing enough revenue that a measurable conversion lift pays for premium hosting" is. When the user names a vague segment, ask for the example companies — actual names, or a description sharp enough that a salesperson could qualify against it. Generic words (many, serious, growing, quality-focused) get pressed into numbers, behaviors, and circumstances. A keystone whose segment can't be made specific after pressing fails the gate.
The user owns the market knowledge
Whether a named segment is significant, whether those customers really exist, whether the circumstance actually occurs — the user knows their market and their call stands, after one honest press ("you said the head of your customer base is 3+-location groups; this keystone describes single-location shops — who's it for?"). What their call cannot do is skip the gate: a keystone with no segment attached doesn't enter the file no matter whose idea it was.
One strength per exchange
Walk the strengths in order, one per exchange; a strength may yield zero, one, or several keystones, and candidate variants within one strength are one exchange's work. The opening move is small: what was read, which strengths look most keystone-rich, then the first strength. Compress ceremony on request, never structure.
How to use this skill
Phase A — Ingest
Read the strengths chart (default: STRENGTHS-WEAKNESSES.md in the
current directory; or pasted). Both-classified attributes participate
on their strength reading — the weakness half belongs to the next
step. Note the best-vs-worst differential if the chart (or its
observations file, if present) carries one; it seeds keystone
candidates. If no strengths chart exists, don't refine from nothing:
offer the on-ramp — run the classification step first (if a
classification skill from this method's author is installed, for
example Strengths & Weaknesses / asb-carol-strengths, name it),
or capture a defensible strengths list in chat now with the caveat
that unvetted strengths yield unvetted keystones. For the quick
capture: hold each claimed strength to a mini genericness test (would
any competitor claim the same words? then press for the mechanism or
the measured gap behind it), assign S-numbers as they settle, grab
the worst-customer picture too (the closing concentration check needs
it), and create the KEYSTONES.md immediately — captured strengths
recorded in its preamble, caveat included — so a died session loses
nothing and a resume finds the strengths on disk. Note in Next steps
that no weaknesses were captured, so the deal-breakers step must
capture or classify them first. If a KEYSTONES.md
already exists at the target location, read it: in-progress header
means resume — pick up at the strength the header names, don't
re-litigate settled keystones. Complete means ask whether to revise.
Output: KEYSTONES.md in the same directory as the input file. If the input was pasted and no path is known, ask where the method's files should live before creating anything (default: the current directory) — never scatter files silently.
Phase B — Walk the strengths
Open small: what you read, which strengths look keystone-rich, any best-vs-worst differential worth mining — then the first strength. Per strength:
- Ask the generative question — who requires an extreme version of this? Offer your own candidates alongside the user's; the best-vs-worst differences are prime material.
- Test each candidate: requires-not-prefers, then the segment gate — name the real-world examples. Press vague segments into specifics.
- Record survivors with [S-number] references and their example segments. A strength that yields no keystone is recorded in the file's table-stakes section with one line of reasoning; a failed candidate under a strength that did yield keystones dies in chat with its reasoning — no file entry needed.
- Move to the next strength.
Record to the file as you go. Create KEYSTONES.md at the first
settled keystone; append after each; keep the header pointer current
(strengths walked, current strength). The file is the memory, not
the chat. If files aren't accessible, re-emit the full draft in a
fenced block every strength or two.
Phase C — Sweep and close
- Concentration check — for each keystone: would this show up weakly or not at all in your worst customers? A keystone that describes everyone is re-tested and usually dies; one that's partially present in the worst survives with a "prioritize for honing" flag — the deal-breakers step tightens it.
- Segment reality check — the batch press (delegated or self-run, per the posture): segments real, significant, specific.
- Count the survivors. Two or more solid keystones: proceed. One or zero: deliver the verdict plainly — the product isn't compelling yet — with the twofold response recorded in the file (spend where keystones exist; research what to build that addresses a real keystone). This is a finding to act on, not a failure to soften.
Finalize: remove the in-progress header and close with the handoff.
The next step mirrors this one on the weaknesses — deal-breakers and
the anti-market — and then hones these keystone segments by
appending the qualifiers the deal-breakers force; if a deal-breakers
skill from this method's author is installed (for example
Deal-Breakers / asb-carol-dealbreakers), name it: "when you're
ready, run asb-carol-dealbreakers — it works on the weaknesses and
then sharpens this file's segment descriptions."
The file structure
# Keystones — <company / project name>
> ⚠️ IN PROGRESS — the walk is not complete. Strengths walked: <which
> S-numbers>; currently on: <S-number>. If you are resuming, continue
> there. (This note is removed at finalization.)
<Two or three lines: which strengths chart this refines (name it) and
the company context carried over. Keystones are customer
circumstances that REQUIRE an extreme version of a strength; each
names the real-world segments that typify it. Segment descriptions
here are pre-honing — the deal-breakers step appends qualifiers.>
## Keystones
**K1.** <The circumstance that requires the extreme version — specific,
behavioral.> [S1]
Example segments: <real-world companies/people who typify it —
named or described sharply enough to qualify against.>
**K2.** <…> [S3]
Example segments: <…>
## Table stakes (true, but compels no one — cut)
- <Strength> — no significant segment requires an extreme version:
<one line of reasoning>. [S2]
## Verdict (only when one or zero keystones survive)
<The plain statement — the product is compelling only to <the one
segment>, or to no one yet — plus the twofold response: (a) spend
where the keystone exists, (b) research what to build that would
address a real keystone.>
## Next steps
<Two or three sentences of prose: do the mirror work on the
weaknesses — deal-breakers and the anti-market segments they
disqualify — then use those deal-breakers to hone each keystone
segment above with qualifiers ("…processing at least $X/mo," "…already
built on Y"). That's the next step of the method, and it works
directly from this file and the strengths chart.>
K-numbers are stable once written — later steps cite them and the deal-breakers step edits this file's segment lines under them. Never renumber.
Refusal conditions
- No strengths chart. Keystones derived from unvetted strengths inherit their vagueness. Offer the classification step or a quick defensible capture first, caveated.
- A keystone with no segment, however insisted. The gate is the method: no significant real-world segment typifies it = table stakes, recorded as a cut. The refusal is of recording it as a keystone, never of the strength — which stays true and useful, just not compelling alone.
- Vague segments. "SMBs," "growing companies," "people who care about quality" — pressed into circumstance and behavior until a salesperson could qualify against the description, or the keystone fails the gate.
- Padding to avoid the verdict. When one or zero keystones survive, that verdict is the deliverable. Inventing weak keystones to make the chart look healthy defeats the exercise and poisons every downstream step.
- Picking the target segment. Which keystone market to pursue is strategy, made later with deal-breakers, inciting events, and the full definition in hand. This file maps the options; it doesn't choose.
- Deal-breakers or the anti-market. The weakness side is the next step's job — including the honing of this file's segments.
FAQ
What does the asb-carol-keystones skill do?
Facilitates the third step of a proven ideal-customer (ICP) method: refining classified strengths into keystones — the specific characteristics, behaviors, or circumstances that make a customer NEED an extreme version of a strength, badly enough to drive the purchase alone. Takes a strengths chart (S1, S2, … — file or pasted), walks the strengths one at a time asking who requires an extreme version of each, gates every candidate on naming a real market segment that typifies it (no segment = table stakes, cut), and records survivors in KEYSTONES.md (K1, K2, … with [S] references and example segments). Delivers the strategic verdict when few or none survive: the product isn't compelling yet. Load when the user has classified strengths and asks who needs them, who their target market is, or 'turn our strengths into keystones.' Do NOT load to classify strengths and weaknesses (the previous step), to derive deal-breakers or the anti-market (the next step), or to write the final ideal-custom
How do I install asb-carol-keystones?
Run npx skills add https://github.com/asmartbear/asb-skills --skill asb-carol-keystones in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/asb-carol-keystones/ (personal) or .claude/skills/asb-carol-keystones/ (project).
Which AI agents can use asb-carol-keystones?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is asb-carol-keystones safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains asb-carol-keystones?
It is published by asmartbear in asmartbear/asb-skills. It has 637 recorded installs.
More from asmartbear/asb-skills
asb-who-me
asmartbear/asb-skills
Interrogates the user to discover who they actually are — what drives them, what drains them, and the natural strengths they can't see because they come so easily — using proven self-discovery prompts (even-as-a-kid, lost-in-the-work, pit-of-my-stomach dread), the anti-questions, and outside-in questions given as homework to people who know them (perfect scenario, personal hell, invisible strengths). Presses every self-flattering label into concrete episodes, welcomes socially unacceptable motives (money, fame, proving a point), and records each finding in WHO-ME.md as a non-judgmental fact — a strength in some contexts, a hindrance in others — with the contexts where it helps and hurts. Load when the user asks who they really are, what work fits them, what drives or drains them, why they keep burning out, or what to build given who they are. Do NOT load to inventory a company's or product's strengths or to distill the one or two decisive personal advantages — the voters step, which co
asb-voters
asmartbear/asb-skills
Distills a person's or company's strengths, experiences, and obsessions down to their one or two VOTERS — the decisive, idiosyncratically extreme traits that win the contest because customers who value them accept every other trade-off. Runs each candidate through a hard gauntlet: extremity earned through obsession (not mere competence), rarity among peers, decisiveness (name the weaknesses it overpowers), and reverberation (it must force decisions in product, pricing, and market). Caps the answer at two, records survivors in VOTERS.md — plus the near-miss 'special strengths' to deploy — and delivers the honest zero-voter verdict when nothing is extreme yet. Takes a self-portrait file (M-numbered), strengths or keystones charts, or a live capture. Load when the user asks what makes them special, what to bet the strategy on, their unfair advantage or superpower, or to 'find our voters.' Do NOT load to build the full self-portrait (the previous step) or to design the whole strategy — thi
asb-positioning
asmartbear/asb-skills
Converts marketing copy — headlines, ads, homepage claims, pitches, positioning statements — into value-first, vivid language: reframes save-time/save-money pitches as create-more-value pitches in the currency the customer measures value, fits each claim to the right level of the customer's needs (features at your level, the promise one level up, aspirations referenced but never promised, obviated steps bragged about), keeps every claim consistent with the declared pricing strategy (More for More, More for Less, or Less for Less), and forces specificity — no generic words, no clichés, show-don't-tell, real numbers only, claims passing the Opposite Test. Works one message at a time, recording survivors in POSITIONING.md. Sharper with an ideal-customer definition and a needs stack; works without. Load when the user wants marketing copy, positioning, headlines, or a pitch rewritten, sharpened, or audited. Do NOT load to build the needs stack or define the ideal customer — upstream steps t
asb-rude-qa
asmartbear/asb-skills
Interrogates a user's decision, plan, pitch, positioning, target market, pricing, or still-forming idea with sharp, unsparing questions — extended when useful to hostile or even unfair framings — until the plan sharpens into defensible decisions, or the user concludes it isn't a good idea after all. Acts as the constructive devil's advocate that the user cannot be for themselves. Load when the user wants to stress-test, attack, pressure-test, find holes in, or play devil's advocate against something they're attached to; when they ask to be "grilled," "beat up," or told "why I'm wrong"; when they suspect their plan contains wishful thinking, fluffy language, or an unnamed elephant in the room; or when they need to convert vague aspirations into real strategic decisions (with consequences accepted). Do NOT load for ordinary code review, prose editing, or general feedback requests without an adversarial frame.
asb-problem
asmartbear/asb-skills
Scores whether a business idea can become a viable business, walking the path from 'The Problem' to 'Viable Business Model': one specific target market is Fermi-scored on seven multiplying criteria (Plausible, Self-Aware, Lucrative, Liquid, Eager ×2, Enduring), every optimistic number is challenged unless evidence backs it, and when the verdict is bad, narrower niches are re-scored side by side. Load when the user asks whether their startup or product idea is viable, whether a market really exists for what they want to build, why a product that solves a real problem isn't selling, which of several target markets to pursue, whether to persevere or give up on a product, or says 'score my idea.' Do NOT load for general devil's-advocate stress-testing of plans or pitches without the viability question, for building a full ideal-customer profile, for writing customer-interview questions, or for execution problems like funnel optimization, hiring, or fundraising.
asb-needs-stack
asmartbear/asb-skills
Builds a customer Needs Stack — the ladder in which every need is a means to the end one level up (buy infrastructure → set up a WordPress site → have a personal website → get a book deal). Anchors the level the user's product satisfies, phrased as the customer's own goal in the customer's own words, then walks downward (the steps the product makes obsolete) and upward (what the customer really wants), crystallizing every level — specific wording, a true means-to-an-end link, named real-world occupants — before moving on. Records the stack in NEEDS-STACK.md with the user's level marked and each level's positioning role: what you do, promise, reference as aspiration, or brag about obviating. Load when the user asks what their customer really wants, what level their product operates at, who their real alternatives (not just competitors) are, or to 'build our needs stack.' Do NOT load to rewrite marketing copy from a finished stack — that is a separate positioning task that consumes this
Popular other skills
hyperframes-cli
heygen-com/hyperframes
The HyperFrames CLI by job - scaffold, check, look at frames, edit the timeline, preview, render locally or in the cloud, publish, project history - plus reading its JSON and recovering from build or render failures.
triage
mattpocock/skills
Move issues and external PRs through a state machine of triage roles, categorise, verify, grill if needed, and write agent-ready briefs.
ask-matt
mattpocock/skills
Ask which skill or flow fits your situation. A router over the skills in this repo.
to-questionnaire
mattpocock/skills
Turn a decision you can't fully answer into a questionnaire for someone else to fill in.
loop-me
mattpocock/skills
Grill me about specs for the workflows I want to build, within this workspace.