
asb-voters
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
- Installs
- 671
- 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-voters- 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-voters 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.
Voters: The One or Two Things That Win the Whole Game
In high-school debate, the final speaker gets three minutes against the opponent's seven. Answering every argument is impossible — so the winning tactic, "the Voter," reframes the whole debate: it all comes down to one or two key points that ought to decide the outcome — chosen, of course, where you are strongest. Win those and you win the debate, despite losing everything else. Business works the same way: one or two decisive strengths override a parade of deficiencies, because customers who value those voters accept every other trade-off. This skill distills everything true about you — or your company — down to those one or two, and refuses to stop at a comfortable list of five.
The mental model
What a voter is
A voter is not a strength. Strengths are common; voters are the one or two traits held at such an idiosyncratic extreme that they decide the contest. Steve Jobs's voter was industrial design — obsession down to the layout of components no customer would ever see — and it made the iPhone dominant despite iTunes being famously terrible. The voter didn't fix the weakness; it overpowered it. Likewise the founder whose product became the fastest in its market: his voter was caring about performance far beyond what anyone else would invest — a twenty-year obsession that began with optimizing math functions for fun in high school — and the whole strategy (top-end hardware, premium price, banned slow add-ons, segments walked away from) reverberated outward from it.
The bar — every voter passes all of it
- Extremity, earned. Not competence — excess. "Magic is just someone spending more time on something than anyone else might reasonably expect." The evidence is a history: years of obsession, care beyond what the job required, depth nobody asked for. A trait acquired last quarter or aspired to next year is not a voter.
- Rare among peers. Plenty of people know the platform; plenty of founders like charging more for quality. Test: would a well-informed peer, asked "who is THE person/company for X?", name you? If the honest answer is "you and forty others," it isn't rare. Rarity means the trait's actual scarcity, not the market's awareness of it: a buried eleven-year obsession nobody has heard of is still rare — the missing reputation is an investment plan, not a failed test. When reputation IS the claim, ask for the citable artifact (the post peers link, the thing you're known by), not self-report. Confirm the current competitive field with your search tools; training knowledge is stale and may miss the peers who make a trait common — or the gap that makes it rare.
- Decisive — name what it overpowers. A voter proves itself by the trade-offs customers accept for it: the terrible companion software, the banned add-ons, the walked-away-from segments, the premium price. If you can't name a real cost that people who value it happily eat, the voter is unproven — possibly imaginary. "Customers" means anyone who chose the user: a buyer, but also an employer, a client, a team, a collaborator, a community. Payment is not required; a real choice that accepted a real trade-off is ("the team put up with my missed deadlines because I was the one who could make the demo work"). At the highest intensity, the ideal customer reads your weaknesses as proof of the voter (on a handmade marketplace, an imperfection is evidence a human made it, and the high price reads as supporting the artist).
- It reverberates. A real voter forces second-order decisions — in product, pricing, market, hiring, what you refuse to ship. If naming it changes nothing downstream, it's a slogan, not a voter.
- It energizes. A voter is executed for years at an intensity nobody sustains through discipline alone; one the user dreads wielding will collapse, however real the extremity is today. In company mode, run this test against the human(s) who actually carry the obsession; a company voter carried by nobody in particular is suspect.
Three tiers below the bar
The debate tactic works because a judge can hold one or two points; so can a market. Three voters is a feature list wearing a costume — so at most two survive (V1, V2), and everything else lands in one of three tiers:
- Special strength — a near-miss: genuinely special (top-1%, real extremity, real energy) but missing one decisive test — usually fairly rare but not THE-person rare, or no real cost ever eaten for it. Never inflate it into a voter; never bury it as common either. It is a secondary pillar the strategy should deliberately deploy. The standout investment candidate (extremity real, decisiveness merely untested) is the classic case.
- Shaping strength — true and strategy-relevant but common or shallow (real familiarity, ordinary diligence). It points the strategy; it doesn't make you special.
- Cut — virtue-words, aspirations, and evidence-free claims.
Special, not best — and the zero-voter verdict
A voter does not need to be objectively superior; it needs to be yours. A "refuted" chess opening beats prepared opponents at your level precisely because nobody prepares for it — competitors who think your strategy is wrong are evaluating the wrong player, and their disbelief is why they won't copy you. Better than different is extreme: not just a minimal interface but so minimal it runs on the command line. So when no candidate passes the bar, say it plainly: nothing is special-and-extreme yet — never pad the file with shaping strengths relabeled as voters. The response is twofold: invest the deepest genuine obsession on the table into extremity (extremity is a choice), or change games to one where a fact you already hold IS extreme.
For anyone early in their career — or new to this kind of work — zero voters is the expected result, because extremity is earned over years and proved by people choosing you. "Nothing is extreme; go work and see" is true and useless. So the verdict always comes with the bet: one chosen obsession (or change-games target) and a concrete, dated plan to turn it into a voter. The verdict is honest; the bet is what makes it worth having.
Drains are costs in the plan, not walls around it
When the bet or a voter's proving trade-offs require an activity the user finds draining — cold outreach for a founder with no audience, selling for a solo consultant — keep it in the plan with a budget (bounded, scheduled doses) and a training step (practice and a system make most drains cheaper). Route around it only when a real alternative keeps the goal intact. Don't build the strategy on becoming excellent at a drain; don't drop a necessary activity because it costs energy either.
The distiller'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 willingly; gate mercilessly
Harvest candidates liberally — from the self-portrait file, the strengths charts, the user's war stories, and your own reading of their material ("this twenty-year pattern in M3 smells like a voter — defend it"; a keystones file is mined indirectly: the strengths its keystones cite, and the extremity behind them). Nominated virtue-words enter the harvest like anything else — they die at the gauntlet, on the record, or yield the specific fact underneath. Then run the gauntlet one candidate at a time, all five tests visible, pressing every soft spot: "everyone in your market claims craftsmanship — what's the evidence a peer would name YOU?"; "what have you actually refused to ship because of this?"; "what did this obsession cost you that a reasonable person wouldn't have paid?" A candidate the user is stuck defending gets your best steelman first, then the honest kill. Two bookkeeping notes: when the evidence pressed out of a dying candidate really belongs to another (the "craftsmanship" facts were all about the tooling stack), cut the word and transfer the evidence — record the transfer in both places; and a candidate may be cut-merged into another (a drive that is just the fuel of an existing voter) — cut list plus evidence, no independent entry.
This skill requires the press
Distillation to one or two is where users flinch — everything feels
essential, and vague answers ("quality," "our people") feel safe. 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 twice: per-candidate whenever a
verdict is soft — resting on a single piece of evidence, or on
self-report with no citable artifact — and against the final file
with this brief: attack these voters — find every one that is a
common strength wearing an extreme costume; every one with no named
cost it overpowers; every one whose evidence is aspiration rather
than history; every one that decides nothing downstream; and attack
the count — if two survived, argue one should die; if the file
dodged the zero-voter verdict, or wrote it without a concrete, dated
bet, say so; if the plan drops a necessary activity only because it
drains the user, say so. If no such skill is available, run exactly
that interrogation yourself, visibly, in both places — the method
does not work without it.
The user owns their history; the bar owns the verdict
What happened — the years, the episodes, the costs paid — is the user's record, taken at their word after one honest press. But whether a candidate passes the bar is not a vote: however attached the user is, a candidate that fails a test goes to its tier with the reasoning on the record. Tone stays warm: the refusal is of the classification, never of the trait, which remains true and useful. The wielder never invents history — the evidence in the file is the user's, confirmed. Every test runs on what the user actually said; never mark a test passed from your impression of them ("from how you talk about it, the energy is real") — ask. The closing press may probe whether the evidence is representative (one clarifying round), but it re-attacks classifications, not the user's settled facts.
How to use this skill
Phase A — Ingest
Ask what this distillation is for — a person choosing what to build,
or a company anchoring a strategy — and what exists on disk: a
self-portrait file (characteristics numbered M1, M2, … with evidence
and contexts), a classified strengths chart or keystones file (S/K
numbers), interview or customer-quote material. Read whatever exists
and cite numbers in the candidates. If nothing exists, say plainly
that the distillation is sharper after the self-portrait step (a
companion skill from this method's author produces it — asb-who-me,
if installed; for a company, an observation-and-classification method
ending in a strengths chart), then proceed: capture candidates inline,
each with at least one concrete episode, caveated as unvetted. If a
VOTERS.md exists at the target location, read it first:
in-progress header = resume where the pointer says; finalized = ask
whether to re-distill (a re-run should have a reason; a bet's
checkpoint arriving is a good one).
In person mode, establish the track record before the harvest: years working, and whether anyone has yet paid for or chosen the user for this kind of work (the self-portrait's preamble may already say). If it's thin, say plainly up front: "voters are earned over years and proved by people choosing you, so at your stage the likely result is zero voters yet — that's normal, not a judgment. Either way you leave with a concrete plan: which trait to build, the goals that would prove it, and what to do this week." Then run the gauntlet at full strength — the bar doesn't lower; the framing and the deliverable change.
Output: VOTERS.md, same directory as the primary input file (the
self-portrait if one exists, else the strengths chart); with no input
files, ask where the method's files should live before creating it
(default: the current directory).
Phase B — Harvest candidates
Collect every plausible candidate into a visible list — the user's
nominations plus your own from the files, each tagged with its source
([M3], [S1], war story) AND, for anything captured live, its episode
evidence in a line or two — evidence that lives only in chat dies
with the session, and a resumed gauntlet run on re-invented evidence
can flip a verdict. No gauntlet yet; the harvest is complete when the
user has nothing to add and you've mined the files. Create
VOTERS.md now with the in-progress header carrying the full
candidate list (sources, episode lines, statuses) and pointer — the
file is the memory, not the chat. If the fuller upstream path was
offered and declined, record that in the preamble so a resumed
session doesn't re-pitch it.
Phase C — The gauntlet
One candidate at a time, all five tests run visibly — across as many exchanges as the evidence needs. One ask per message, at the end of the message: when a test needs the user's evidence, ask for that one thing and stop; never stack tests ("answer 2 and 3 for me") or braid several questions together. Verdict on the record: voter-candidate (written into The voters at verdict time with its V-number; if Phase D's ranking later demotes it, it moves to its tier with a "demoted at ranking" note and its number is never reused), special strength (with the test it missed), shaping strength (one line of reasoning), or cut (dies in the header's candidate list with its reasoning, not in the body). Press per the posture; invoke the interrogation on soft verdicts. Update the file and pointer each exchange — the in-flight candidate's status reads "in gauntlet," and the pointer records which tests have run, their outcomes, and the evidence the user gave, so a died session resumes mid-candidate instead of restarting it. (Resuming a file whose pointer lacks that detail: say so plainly and restart the candidate from test 1.)
Phase D — Distill and close
- Count the survivors. Three or more: force the ranking — "when
they conflict, which wins? which one or two do you bet on?" —
demote the rest to special or shaping strengths, per how special
each is. One or two: proceed. Zero: write the verdict section —
the plain statement plus the twofold response, naming the specific
obsession candidates from the harvest. The standout investment
candidate appears in BOTH special strengths (so tagged) and, by
name, the verdict. Then build the bet with the user — mandatory;
the session is not done without it:
- Choose one obsession to invest in (usually the standout investment candidate) or one change-games target — not a menu. If the user can't choose, force it: "which one would you still be doing in five years if nobody paid you?"
- Goals tied to the failed tests — two to four, each with a number and a date (default horizon: 90 days). Extremity: a body of work beyond what anyone would reasonably expect ("ship twelve small tools in this niche"). Rarity: a citable artifact peers can point to. Decisiveness: a number of people who choose the user — paying, hiring, committing time — despite a named trade-off. Reverberation: one real decision the bet forces.
- This week — two or three first actions, small enough to start today.
- Drains in the plan — budgeted and trained, per Drains are costs in the plan.
- The checkpoint — the date to re-run this gauntlet, and what result would mean switching branches (invest ↔ change games). Designing the full company strategy around a bet is downstream; the bet's plan is this skill's job.
- Walk the weaknesses (for each settled voter): from the self-portrait's hindrances, the strengths chart's weaknesses, or the user's list — which does this voter overpower, and which would the ideal customer read as service to the voter? Record them under the voter. A voter that overpowers nothing gets one more press before it stands.
- The closing press (delegated or self-run, per the posture — including the count attack).
- Finalize: remove the in-progress header (cuts and their
reasoning move to a brief "Cut at the gauntlet" list), and close
with the handoff. In a zero-voter file the handoff is the bet
itself — start this week's actions, return at the checkpoint;
there is no strategy to audit against voters that don't exist yet.
Otherwise: audit the current strategy against the voters — walk
pricing, positioning, product, and channels asking where each
voter expresses and where it's contradicted; the mismatches are
where to pivot. Expect others to call the strategy wrong — their
disbelief is why they won't copy it. If a positioning skill from
this method's author is installed (for example Positioning /
asb-positioning), note that its statements should lead with the voters and deploy the special strengths as secondary claims.
The file structure
Format for a human reading it in a markdown viewer, not as a wall of text. Every voter is an H3 with a short name, then a bold one-sentence headline (the voter itself), then a one-line supporting note, then the bar rendered as labeled bullets — never a single multi-line indented paragraph, which collapses into an unreadable blob (and 4-space indents render as code blocks in many viewers). The same labeled-bullet discipline applies to the strengths sections.
# Voters — <person or company>
> ⚠️ IN PROGRESS — candidates harvested: <list, each with source,
> a one-line episode note for live-captured evidence, and status:
> pending / in gauntlet / voter-candidate / special / shaping /
> cut (reason)>;
> currently at the gauntlet: <which candidate — tests run and their
> outcomes so far, with the evidence given; note any soft verdict a
> resumed session should re-press>. <If the gauntlet is done: "walk
> complete; ranking / weakness walk / closing press / finalization
> remaining."> If you are resuming, continue there. (Removed at
> finalization; episode evidence worth keeping folds into the
> surviving entries first.)
<Two or three lines: whose voters, which input files ([M]/[S]/[K])
this distills, what strategy question it serves.>
## The voters
### V1 — <short punchy name of the voter, 3–7 words>
**<One vivid sentence stating the voter — the crisp headline claim,
never a bare noun like "performance.">**
*<One supporting line: the core in a phrase, plus signature and
amplifiers if any.>*
**Draws on:** <M/S numbers>
- **Extremity, earned** — <the years, episodes, unreasonable
investments — the user's record>.
- **Rarity** — <why a well-informed peer names them for this; the
citable artifact>.
- **Overpowers** — the trade-offs its fans happily eat:
- *<cost 1>* — <the cost, and which weakness reads as service to
the voter, and to whom>.
- *<cost 2>* — <…>.
- **Reverberates into** — <the second-order decisions it forces —
product, pricing, market, refusals>.
- **Energizes** — <the test-5 result — who carries the obsession and
the evidence it runs on joy, not discipline>.
### V2 — <name> (only if a second genuinely survives)
<same structure>
## Special strengths (near-miss voters — deploy as secondary pillars)
- <Trait> — <one line: which parts of the bar it nails (extremity,
energy) and the one it misses (fairly-rare-not-THE-person, or no
overpowered cost); why the strategy should still deploy it as a
secondary pillar>. [M/S]
## Shaping strengths (true, useful, not voters)
- <Trait> — <one line: real, but common among peers / no overpowered
cost named / decides nothing downstream>. [S1]
## The verdict (only when zero voters survive)
<The plain statement: nothing is special-and-extreme yet — plus the
twofold response with the specific obsession candidates named. For
an early-career user, say that this is the expected result at their
stage.>
## The bet (required whenever the verdict is written)
**<The one chosen obsession or change-games target, in one vivid
sentence.>**
- **Goals by <date>** —
- *Extremity:* <body of work, with a number>.
- *Rarity:* <the citable artifact>.
- *Decisiveness:* <N people who choose you despite <trade-off>>.
- *Reverberation:* <the decision it forces>.
(Only the tests the bet actually failed; two to four goals.)
- **This week** — <two or three first actions>.
- **Drains to budget** — <any draining activity a goal needs: the
budget and the training step>.
- **Checkpoint** — <date to re-run the gauntlet; what result would
switch to the other branch>.
## Cut at the gauntlet
- <Candidate> — <one line of reasoning>.
## Next steps
<Two or three sentences of prose: audit strategy against the voters
— pricing, positioning, product, channels; where a voter is
contradicted is where to pivot. Positioning statements should lead
with the voters. Expect knowledgeable people to call the resulting
strategy wrong; that disbelief is the moat. In a zero-voter file:
the bet's first actions and checkpoint instead.>
V-numbers are stable once written; wording may sharpen under a frozen number with the user's confirmation while in progress.
Refusal conditions
- A third voter, however insisted. The third demotes to a special or shaping strength with the ranking reasoning on the record.
- Misfiling a near-miss — either way. Inflating a special strength into a voter, or burying it among the common shaping strengths, both lose its value.
- Virtue-words as voters. "Quality," "hard work," "customer focus," "our people" — nothing every peer would also claim can decide a contest. Press to the specific fact underneath or classify it out.
- Aspiration as extremity. "We're becoming known for…" is strategy, not history. A voter's evidence is what already happened.
- A voter with no overpowered cost. One more press, then special or shaping strength.
- Dodging the zero-voter verdict — or giving it without a bet. Padding the file with relabeled shaping strengths poisons every decision downstream; "go work and see" leaves the user with nothing to do. A zero-voter file always has the bet: one choice, dated goals, this week's actions, a checkpoint.
- Drains as walls. Never steer the bet or strategy away from a necessary activity only because it drains the user.
- Building the full self-portrait. That's the previous step; capture-inline is a fallback, not the exercise.
- Designing the whole strategy. This file anchors the strategy audit; running it — resolving conflicts, redefining boxes, changing target markets — is downstream work this skill names but does not perform.
FAQ
What does the asb-voters skill do?
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
How do I install asb-voters?
Run npx skills add https://github.com/asmartbear/asb-skills --skill asb-voters 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-voters/ (personal) or .claude/skills/asb-voters/ (project).
Which AI agents can use asb-voters?
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-voters 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-voters?
It is published by asmartbear in asmartbear/asb-skills. It has 671 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-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
asb-carol-define
asmartbear/asb-skills
Facilitates the final step of a proven ideal-customer (ICP) method: synthesizing the working files — strengths and weaknesses, honed keystones, deal-breakers, and inciting events — into CAROL.md, the crisp definition of the ideal customer. The definition leads the file, behavioral and attitudinal, never demographic unless genuinely determinative; every marker must clear the bar that Marketing can target it, Sales can qualify against it, and Product can build features to thrill it. Brief reference sections on keystones, deal-breakers, and inciting events follow, because positioning, marketing, and feature work consume them. When keystone segments diverge, the skill forces the choice of a primary rather than averaging. Load when the user has the working files and says 'define our Carol,' 'write our ideal customer profile,' or 'who is our ICP.' Do NOT load to produce the upstream files (observations through inciting events), or to write the positioning, ads, or feature plans that start FR
Popular devops & cloud skills
microsoft-foundry
microsoft/azure-skills
Build, deploy, evaluate, optimize, fine-tune, and manage Microsoft Foundry agents, models, and resources end to end. USE FOR: foundry, azd ai agent, azd provision/deploy, hosted agent scaffold/develop/run/deploy/troubleshoot, prompt agent create, managed harness agent create, GitHub Copilot harness agent, create agent, update agent, add tool to agent, invoke agent, agent insights, evaluate agent, batch eval, continuous eval, continuous monitoring, agent CI/CD, optimize prompt, improve prompt, optimize agent instructions, Agent Optimizer scaffold, dataset curation from traces, deploy model, model fine-tuning (SFT/DPO/RFT), Foundry project, RBAC, role assignment, permissions, quota, capacity, region, deployment failure, AI Services, create Foundry resource, knowledge index, customize deployment, onboard, availability, training-data, grader, distillation, large file upload. DO NOT USE FOR: Azure Functions, App Service, general Azure deploy (use azure-deploy), general Azure prep (use azure
azure-diagnostics
microsoft/azure-skills
Debug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deployment failure, troubleshoot container apps, container app 503 or target port mismatch, troubleshoot functions, function telemetry missing or stopped after a config/connection-string change, troubleshoot AKS, VM RDP, Linux SSH, VM black screen, can't connect to VM, reset VM password, NSG or firewall blocking, kubectl cannot connect, kube-system/CoreDNS failures, pod pending, crashloop, node not ready, upgrade failures, analyze logs, KQL, insights, image pull failures, cold start issues, health probe failures, resource health, root cause of errors, troubleshoot event hubs, troubleshoot service bus, messaging SDK error, AMQP connection failure, message lock lost, lock renewal during long-running processing, service bus dead letter.
azure-prepare
microsoft/azure-skills
Prepare azd-based Azure projects for deployment: generates azure.yaml, infrastructure (Bicep/Terraform), and Dockerfiles for the Azure Developer CLI (azd) workflow. USE ONLY when the user explicitly wants to use azd as the deployment tool, or the project already has an azure.yaml file. DO NOT USE FOR: non-azd deployments, Python App Service code-only deploys (use python-appservice-deploy), or cross-cloud migration (use azure-cloud-migrate). WHEN: prepare app for azd, create azure.yaml, set up azd infrastructure, modernize app for Azure with azd, deploy with azd, function app, timer trigger, service bus trigger, event-driven function, managed identity, generate Bicep, generate Terraform, create and deploy to Azure.
azure-ai
microsoft/azure-skills
Use for Azure AI: Search, Speech, OpenAI, Document Intelligence. Helps with search, vector/hybrid search, speech-to-text, text-to-speech, transcription, OCR. WHEN: AI Search, query search, vector search, hybrid search, semantic search, speech-to-text, text-to-speech, transcribe, OCR, convert text to speech.
azure-deploy
microsoft/azure-skills
Execute Azure deployments for ALREADY-PREPARED applications that have existing .azure/deployment-plan.md and infrastructure files. DO NOT use this skill when the user asks to CREATE a new application — use azure-prepare instead. This skill runs azd up, azd deploy, terraform apply, and az deployment commands with built-in error recovery. Requires .azure/deployment-plan.md from azure-prepare and validated status from azure-validate. WHEN: "run azd up", "run azd deploy", "execute deployment", "push to production", "push to cloud", "go live", "ship it", "bicep deploy", "terraform apply", "publish to Azure", "launch on Azure". DO NOT USE WHEN: "create and deploy", "build and deploy", "create a new app", "set up infrastructure", "create and deploy to Azure using Terraform" — use azure-prepare for these.
azure-validate
microsoft/azure-skills
Pre-deployment validation for Azure readiness. Run deep checks on configuration, infrastructure (Bicep or Terraform), RBAC role assignments, managed identity permissions, and prerequisites before deploying. WHEN: validate my app, check deployment readiness, run preflight checks, verify configuration, check if ready to deploy, validate azure.yaml, validate Bicep, test before deploying, troubleshoot deployment errors, validate Azure Functions, validate function app, validate serverless deployment, verify RBAC roles, check role assignments, review managed identity permissions, what-if analysis, validate Container Apps deployment.