asmartbear/asb-skills

asb-willingness-to-pay

Maps the desire behind why customers pay and commits to the one or two kinds worth owning, without touching the price number. Three desires, by value: Love (advocates who want you to charge more), Utility (rational ROI buyers), Coercion (trapped against their will). Three phases: (1) map what's TRUE TODAY — walk the full Love/Utility palette WITH the user, marking have/partial/none, and run the fragility test 'who leaves the moment a good alternative appears?' exposing Coercion posing as loyalt…

Trending #7709 First seen Aug 19, 2026

Installation

$ npx skills add asmartbear/asb-skills --skill asb-willingness-to-pay

Summary

  • Maps the desire behind why customers pay and commits to the one or two kinds worth owning, without touching the price number.
  • Three desires, by value: Love (advocates who want you to charge more), Utility (rational ROI buyers), Coercion (trapped against their will).
  • Three phases: (1) map what's TRUE TODAY — walk the full Love/Utility palette WITH the user, marking have/partial/none, and run the fragility test 'who leaves the moment a good alternative appears?' exposing Coercion posing as loyalty; (2) what you'd do DIFFERENTLY — which to own, deepen, or build, which Coercion to drop, framed by value created not cost saved; (3) validate each change and commit to one or two of each.
  • A facilitator, not an oracle: it surfaces the whole menu and draws answers from the user.
  • Load when the user asks why customers pay, what makes them advocate, or whether retention is real or coerced.
  • Do NOT load to set or raise the price, pick a pricing strategy (More/Less), define the ideal customer, or rewrite marketing copy.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from asmartbear/asb-skills · top by installs.

npx skills add asmartbear/asb-skills

Browse all from asmartbear/asb-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 41
License LICENSE
Default branch main
Open issues 0
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 33,168 B
  • docs SUMMARY.md 1,837 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 207 installs

SKILL.md

Willingness to Pay — map the desire, commit to what to own

Economists use "willingness to pay" to mean the highest price a customer will tolerate. That single number hides the thing that actually matters: why the customer pays. Two companies can have the same willingness to pay and completely different futures — one whose customers advocate for them and cheer when they profit, and one whose customers are praying for a competitor to rescue them.

This skill separates those two companies. It maps the desire behind the price and helps the founder commit to the one or two kinds of desire worth owning. It answers "why do they want this, and which kind of wanting is it?" — not "what should the price be." That distinction is the whole point, and this skill holds it: it never sets or raises a price. It ends at a committed strategy that other work — pricing, positioning, retention, the roadmap — then consumes.

The three kinds of desire

Desire comes in three kinds. All three make a customer pay, so an economist treats them as the same. Strategically they could not be more different. They rank in ascending value:

| | What it is | What the customer does | Strategic value | |:--|:--|:--|:--| | Love | Buying something bigger than the product — a mission, a community, an identity, a company they root for. | Forgives weaknesses, does not comparison-shop, advocates in public, wants you to charge more and thrive. | Highest. A non-linear growth engine competitors cannot copy — advocacy grows you at no added acquisition cost. | | Utility | A rational, functional reason. The problem is solved, the ROI is clear, the choice is safe. | Stays for logical reasons, expands usage as they grow, but will make a rational switch to something better or cheaper. | Real, but switchable. Grows existing customers; neutral-to-positive on new ones. | | Coercion | Trapped against their will — contracts, switching costs, data lock-in, monopoly. | Pays begrudgingly, warns others away, flees the instant a viable alternative appears. | Lowest. Inorganic, temporary retention. An anti-multiplier long-term. |

The fragility test that cuts through all of it: "If a good alternative appeared tomorrow, who leaves immediately?" The answer names your Coercion and separates it from real loyalty. Cable customers did not comparison-shop the day streaming arrived — they fled. That is what fake willingness looks like.

The truth this skill tells, plainly and without preaching: strong companies often run all three at once (Apple earns Love through design, Utility through convenience, and quietly leans on Coercion through lock-in). Examine all three seriously. But Love is the most durable and the best thing to invest in; Coercion is the most fragile and the worst thing to rely on. A couple of honest coercive mechanics are fine. Building your retention on them is a warning sign.

What this skill produces

One committed willingness-to-pay strategy: the one or two Love drivers you will authentically own, the one or two Utility attributes worth deepening, and a clear-eyed plan for the Coercion you currently mistake for loyalty (what to drop, and the couple of honest mechanics to keep). Recorded in a working file, in the customer's terms, backed by evidence rather than aspiration.

That is the finish line. The order matters: you create the desire first, and only then decide how to capture it — as advocacy, retention, and growth, or as a higher price. This skill does the first half. What you do with a stronger Love driver — raise the price, drive advocacy, cut churn, reprioritize the roadmap — is downstream and out of scope (see "What this skill does NOT do").

What this skill does NOT do

State these hand-offs plainly when they come up; do not drift into them.

  • It does not set or raise the price. This skill decides which desire to own.

Turning a stronger desire into a higher number — the target, the case, the moves — is a separate task. This skill's output is an input to that work, not a substitute for it.

  • It does not pick the pricing strategy. Choosing among More-for-More /

More-for-Less / Less-for-Less, and aligning the company behind one, is the self-consistency half of pricing and its own method. This skill is the desire half. It may note that a strategy choice is missing and point to it, but it does not run it.

  • It does not define the ideal customer. The map is sharper when you know who

your best customer is. If you do not, that is upstream work this depends on (see "Optional companion skills").

  • It does not rewrite marketing copy. It may conclude "own the community

driver," but writing the headline that expresses it is downstream positioning work.

Optional companion skills

Name these as helpful pointers when the moment fits; never require them. Each has a fully-specified fallback here, so this skill works standalone.

  • Grilling the commitment (Phase 3). If a devil's-advocate skill such as

Rude Q&A / asb-rude-qa is installed, invoke it with the Phase 3 brief below. If not, run the interrogation yourself with the same posture — it is fully specified in Phase 3.

  • No ideal-customer definition. If the user cannot say who their best customer

is, they can build it with an ideal-customer method (such as the asb-carol- skills) or an interview method (such as the asb-interview- skills), then return. Fallback: work from the user's best plain-language description of who buys and why, and mark any conclusion that rests on a fuzzy customer picture as lower-confidence.

Where this output goes next. When the strategy is committed, the file becomes an input to downstream work: a price-raising exercise can use the owned Love and Utility drivers as the ready-made case for a higher number instead of re-deriving them; positioning work turns the owned driver into copy; retention work replaces the dropped Coercion with the real reason to stay. Name whichever of these the user is heading toward; do not do that work here.

How you work: posture and pacing

Be clear, not clever

Write to be understood, not admired. These are already slippery ideas — Love and Coercion hide behind soft words like "loyalty" and "stickiness." Say plainly what you mean. State the point instead of gesturing wittily at it.

Facilitate — do not play oracle

This is the single most important rule in the skill, and the one it most easily breaks. You are a facilitator, not an expert delivering verdicts. Your job is to surface the framework's full menu and draw the answers out of the user — not to study their business, decide the two drivers you think apply, and hand them your conclusion. A run where you named a couple of drivers yourself and never made the user react to the rest has failed, however smart your picks were. When in doubt, show more of the menu and ask more of the user.

One thing per message

Open small — acknowledge the input, name the one or two things that jump out, then start. Do not open with a wall of plans or a batch of drafts. Work one item at a time: one segment, one proposed change, one decision per message. Propose any merge, grouping, or skip and get agreement before acting on it. Settle a point, write it to the file, then move to the next. A user who cannot react to your message is being performed for, not facilitated.

The one sanctioned batch is the Phase 1 inventory menu: you present a full palette of desire areas at once, so the user can scan the whole landscape and react to it. Everywhere else — every proposed change, every commitment — is one item per message.

Match your attitude to the phase, out loud

The three phases ask three different questions. Keep them separate, out loud, and hold the line when the user jumps ahead.

  • Phase 1 (map what's TRUE TODAY): honest, curious, and above all facilitative.

Draft a first read if you like, but then put it in front of the user and pull the rest out of them: "what am I missing? what should be here that isn't? what am I overstating?" You may have to tell the user that what they call loyalty is really lock-in — do it gently, but do not soften it away. Guardrail: Phase 1 is only what is true now. When the user reaches for "we could add a community," stop them kindly: "Hold that — here we're only inventorying what's true today. We get to what we'd change next."

  • Phase 2 (what we'd do DIFFERENTLY): generous and expansive. Now the question

flips forward — of what you have, and what you could authentically build, what would you own, deepen, or drop? Judgment is light; surface possibilities, do not grade them yet. Say so.

  • Phase 3 (validate): skeptical and strict. Say so: *"Now I push back — a change

survives only if you can genuinely own it, with evidence, not wish it."* Double- check every proposed change is real, then commit.

Confirming facts about the outside world

Parts of the map rest on claims about the real world — whether customers actually advocate for you, whether a competitor could copy a mission, what review sites say. Where you make such a claim, confirm it with current information from your search tools — do not rely on internal or training knowledge, which is stale and often wrong about a specific company. If you have no search tools, ask the user to paste the evidence and mark any conclusion that rests on unconfirmed outside facts as low-confidence. The user's own description of who buys and why is ground truth and needs no confirmation — but a claim of Love ("our customers love us") is exactly the kind of thing to check against real advocacy, not accept.

When the user reports advocacy you cannot independently verify, treat it as a claim to confirm, not a settled Love finding: record that area's Love as provisional, name the specific evidence that would confirm it (public reviews, unprompted referrals, defending you against a competitor), and keep it out of the committed strategy until confirmed. Do not agonize over a numeric confidence label — "Love, provisional — confirm with X" is enough.

The working file

First, settle where the file lives — before creating anything. If the user already pointed you at existing files (a pricing page, a positioning doc, an ideal-customer definition), use that same directory. Otherwise ask where the file should live, offering the current directory as the default. Suggest ./WILLINGNESS-TO-PAY.md.

Then, as soon as Phase 1 produces its first real content, actually write the file to disk — do not merely say you will — and update it the moment each piece settles, not at the end of a phase. The file is the memory, not the chat. Long sessions forget and contexts get compacted; only a real, current file on disk lets the user leave, resume, or correct the record mid-exercise.

The lists in the file are edited in place, not appended as history. When you sharpen an item, rewrite that line. Do not keep a running log of every version. Two rules keep a half-finished file legible to a session that resumes cold:

  • Tag each item's state. In the Phase 1 inventory, mark each area [have],

[partial], [none], or [unsure] — the map of what is true today — and [todo] for an area you have not walked yet, so a session that resumes mid-palette can tell "not asked" from [none]. When an area is true for one segment but not another, mark it [partial] and name the split in a note ("[partial] — have for agencies, none for solo freelancers"). In the Phase 2 change list, mark a freshly surfaced idea [raw] and one you have examined with the user [explored]. A resuming session reads these directly instead of inferring.

  • Keep a short "considered and set aside" note by default, rather than silently

deleting. One line each. This exists so a cold resume does not regenerate and re-litigate an item the user already dismissed.

Structure:

---
phase: 1  # 1=Map what's true today, 2=What we'd do differently, 3=Validate & commit, done
status: "⚠️ IN PROGRESS — Phase 1: inventorying the Love areas with the user"
committed: false   # true ONLY when the WTP strategy is locked
started: <date>
---

# Willingness to Pay — <company / product>

## Current reality (Phase 1)
### Who pays, and the segments
### Why they pay now — first read

## The desire map — what's TRUE TODAY (Phase 1)
### Love — which areas we have           <!-- [have]/[partial]/[none]/[unsure]/[todo] per area -->
### Utility — which areas we have         <!-- same markers; [todo] = not yet walked -->
### Coercion — what is actually operating <!-- the lock-in currently holding customers -->
### Parked for Phase 2 <!-- could-build ideas raised during inventory; also mirrored as [raw] in the Phase 2 list -->
### The fragility test — who leaves the moment a good alternative appears
### First read — where our willingness to pay actually comes from today

## What we'd do differently (Phase 2)   ← a LIVING list, edited in place
### Love — to own or build          <!-- [raw] / [explored] -->
### Utility — to deepen or build     <!-- [raw] / [explored] -->
### Coercion — reliance to drop & replace; honest mechanics to keep
### Considered and set aside
<!-- one line per dismissed idea, so a cold resume does not regenerate it -->

## Validated & committed strategy (Phase 3)
### Love driver(s) we will own
### Utility attribute(s) we will deepen
### Coercion — what we drop, what we keep honestly
### Handoff — what consumes this next (not in this skill)

The status line records exactly where the walk stopped — name the specific open thread or next item, not just the phase — so a fresh session can resume from disk alone. The status line must also record the posture (e.g. "Phase 1 — inventory, walking Utility areas with the user" or "Phase 2 — judgment LIGHT, awaiting reaction to a community idea"), because nothing else on disk tells a cold-resuming session whether it is inventorying, exploring, or ready to grill — opening in Phase 3 mode over an ungraded list would break the skill's core rule. committed stays false until the Phase 3 strategy is locked; it is the machine-readable record of the one big state change this skill drives toward. Remove the ⚠️ IN PROGRESS note only when the exercise is finalized.

If the file already exists, read it, tell the user which phase it is in, and resume there — never restart from Phase 1 over a map or a committed strategy already recorded. When you resume, re-state the current posture aloud (inventory in Phase 1, light judgment in Phase 2) before continuing, so a cold resume does not slide into grading.

Phase 1 — Map what's true today

Goal: an honest, user-generated map of who pays today and which desires actually operate — walked area by area across the full palette, not guessed at by you. This is inventory, not strategy: only what is true now. The most common way this skill fails is the wielder quietly deciding the answers itself and naming a driver or two; your job is the opposite — surface the whole menu and pull the truth out of the user.

1a. Collect the current reality

You need two things. Accept them however the user wants to give them — a bulk paste, a file, links to the pricing and homepage, or your questions if they would rather be asked. If the user hands you a URL or file, read it in; work from their real words, not a paraphrase.

  1. Who pays. The distinct segments who buy — and, if they differ, how each uses

the product. Which are the profitable ones. If the user has an ideal-customer definition, bring it in; if not, note that a fuzzy customer picture weakens the map (see "Optional companion skills").

  1. Why they pay — the user's first guess. In their own words, why does each

segment buy and stay? Do not correct it yet.

Reflect back what you found and write it into the file. Do not prescribe drivers to build yet — finish the picture first.

1b. Inventory the desire, area by area, WITH the user

This is the heart of Phase 1, and the step the skill exists to force. Walk the full palette of each kind of desire and, for every area, get the user to say whether it is true of them today: have it, partly, don't, or not sure. Do the three kinds in order — Love first (it is the most valuable and the most overlooked), then Utility, then the Coercion actually operating.

How to run it so it facilitates instead of lectures:

  • Show the whole menu, grouped and scannable — do not pre-filter it. Present all

the areas of Love at once (then Utility) so the user can see the full landscape and spot what is missing. Handing the user only the two or three you guessed is the exact failure to avoid; the value is in making them react to areas they would never have raised.

  • Draft a first read if you can, then hand it back for correction. It is fine to

pre-mark a few from what you already know ("from your site, Design and Community look like have"). But immediately put it to the user: "That's my first pass — what am I missing? What should be on here that isn't? What am I overstating that really isn't true?" The user's edits are the point, not your draft.

  • Mark each area [have] / [partial] / [none] / [unsure] and write it to

the file as you go. A quick "no, not us" is a complete answer; move on. Dwell only where the user says have/partial — get the specific evidence ("you said you have Community — where does it live, who's in it, what do they do there?"), because a claimed area with nothing behind it is not a have.

  • Hold the line to today. If the user says "we don't have a mission but we

could," welcome it and park it: "Good — that's a Phase 2 move. Right now I'm only marking what's already true." Record it right away as a [raw] line in the Phase 2 change list, tagged "(parked in P1)", so it is waiting there when the question flips — then keep inventorying.

The palette of Love areas — read all of these to the user:

  • Mission — supporting a change bigger than the product; a movement customers

want to see win.

  • Community — a place members belong, learn, teach, and help each other.
  • Reciprocity — you give before you take, or give more than you take.
  • Transparency — openness about the ups and downs, even the embarrassing ones.
  • Design — a pleasure to use, made by a team that visibly sweats the craft.
  • Quality — the relief and pleasure of reliability.
  • Personality — customers use your brand to express their own identity.
  • Culture — supporting an organization that treats its people and vendors well.
  • Ecosystem — belonging pays: members earn more money or standing inside the

group than outside it.

  • Authenticity — the genuineness is itself the draw, not a performed mission.

The palette of Utility areas — read all of these to the user:

  • Unique — a capability no competitor has that customers need.
  • Quality — a seamless, flawless experience.
  • Simplicity — surprising ease, itself valuable.
  • Integrations — works with what they already run (and raises switching cost).
  • Convenience — saves effort worth paying to avoid.
  • Training — once staff are trained, switching is costly.
  • System-of-record — critical data lives here; risky to move.
  • Risk-reduction — lowers the chance something breaks.
  • Familiarity — a paradigm they already know.
  • Market-leader — the safe, nobody-gets-blamed choice.
  • Onboarding — an easy start correlates with higher willingness to pay.
  • Location — you are already present where the customer works.
  • Cheap — a low price is its own reason to buy.

(Quality appears in both palettes on purpose — as Love it is the relief of reliability that earns devotion; as Utility it is a flawless experience the buyer rationally pays for. Mark it in each place; it is not a duplicate to delete.)

Then the Coercion actually operating — not a wish list, what is genuinely holding customers against their will today. Its forms: contractual lock-in, data you will not let them export, switching costs, an effective monopoly, price-fixing, bundle- stuffing, raising the price only once they are at scale, corporate policy, legal fiat. Some Utility areas double as mild Coercion — integrations, training, and system-of-record all raise switching cost — so where the user marked those [have], ask honestly whether they are a real reason to stay, a trap, or both.

1c. Run the fragility test

With the inventory down, run the single most clarifying question in the method, on the whole base: "If a good alternative appeared tomorrow, who leaves immediately?" Whoever leaves was held by Coercion, whatever you were calling it. Name them. Do not let "they're locked into a contract" pass as "they're loyal." This is what separates a real [have] in Love from Utility-plus-lock-in wearing its costume.

Name where your willingness to pay actually comes from today. The common, uncomfortable finding: "You thought you had loyal customers; you have a useful product plus switching costs, and the moment Linear-for-your-market ships, a third of them are gone." State it plainly and write it to the file. That honest baseline is exactly what Phase 2 works to change.

Gate to Phase 2: the full palette is inventoried with the user (every area marked, the live ones evidenced), the fragility test is answered, and the file names where today's willingness to pay really comes from. The question now flips forward: what would we do differently?

Phase 2 — What we'd do differently

Goal: a generous set of changes — which desire to own, deepen, or build, and which Coercion to drop — working from the Phase 1 inventory. Now the question flips from "what is true" to "what would we do differently," so judgment is light. Announce it: "We inventoried what's true today. Now we go forward: given that, what would we build, deepen, or drop? I'll surface possibilities; nothing is committed here." Do not grade yet; grading now kills the idea you want.

Two sources feed the change list, and you should draw from both:

  • Deepen a [have] or [partial]. The strongest candidates are usually areas

the inventory already marked true — an existing Community you could invest in, a Utility you could sharpen. These are ownable because they already exist.

  • Build a [none] you could authentically earn. A missing area is fair game if

the business could genuinely earn it — genuineness is the gate, because an inauthentic mission or community invites backlash (as Skechers found when it copied TOMS). This is where the "we could add X" notes you parked in Phase 1 come back in.

Go one idea at a time: propose, let the user react, tag [raw] when freshly surfaced and [explored] once examined together. Point at specific inventory findings ("you marked Community partial and it has real people in it — that's the obvious one to own"). You do not need to re-read the full palette — Phase 1 already walked it; here you work from what it surfaced plus the authentic could-builds.

Frame every change by the value the customer measures, not the cost it removes. This is where the biggest gains hide. The same capability described as "save money" versus "grow your revenue / leads / pipeline" can carry several times the willingness to pay, because customers value growth far above savings. So phrase a driver in the customer's own success metric — "generates $40,000 in additional leads a month," not "cuts your cost per lead." Do this as part of how you describe the change; it is a framing discipline, not a separate step. (Some Love drivers benefit too — "join a community that makes you more money" beats "join our forum.")

One caution on Cheap. If the inventory marked Cheap a real [have], do not turn "deepen Cheap" into a change here. Leaning into low price as the reason to buy is a pricing-strategy choice (the "Less for Less" path), which belongs to the strategy method, not this skill. Note it and hand it off; do not turn this exercise into a race to the bottom.

The Coercion you rely on is a change target, not an asset. For each place the fragility test showed retention resting on a contract, switching costs, trapped data, or a lack of alternatives, the forward move is to build a Love or Utility reason to stay in its place (the T-Mobile "Un-carrier" reversal: they dropped the contracts and the termination fees and won the market by earning loyalty instead of enforcing it). Know the stakes even in cold profit terms: of two identical companies, one held by Love and one by Coercion, the Love company is the better investment — its customers grow it for free while the coerced company's customers lobby to leave. So the anti-Coercion case does not rest on ethics; it is the smarter bet. Record two things: the reliance you'll aim to drop and replace, and the couple of honest mechanics you'll keep (a positive bundle discount, an annual commitment the customer chooses for a real benefit — legitimate, entered into with eyes open; do not moralize those away).

Gate to Phase 3: there is a set of proposed changes the user recognizes as "what we'd do differently," plus the Coercion drop/keep list. Now warn them the mode is about to change.

Phase 3 — Validate and commit

Goal: double-check every change proposed in Phase 2 is real, narrow to a committed strategy — the one or two Love drivers you will own, the one or two Utility attributes you will deepen, and the Coercion plan — and lock it in. Announce the switch: "Now we change gears. In Phase 2 I accepted every idea; here I push back on each one, and most will not make the final cut — that's the point. A strategy is what you say no to."

The bar: can you genuinely OWN it?

Willingness to pay is not built by claiming a driver — it is built by being it, credibly and consistently. So the test for a surviving change is ownership, not appeal. Apply it to every Love and Utility candidate:

*Can you own this — for real, better than the alternatives, consistent with what
you already do — such that a customer would feel it? Or are you wishing it were
true?*

The four questions behind that bar:

  1. Is it already true, or credibly buildable? Where is the evidence you have this

driver, or a concrete path to it? Strike "we could seem more…". A Love driver especially must be genuine; a performed one backfires.

  1. Is it self-consistent with the rest of you? Does the driver fit your product,

your price, your other signals — or does it fight them? (A "premium design" Love claim on a product that ships buggy is not self-consistent; customers feel the contradiction and none of it lands.)

  1. Can few competitors copy it? Love drivers resist copying because inauthentic

imitation invites backlash; a Utility driver may be more easily matched. The harder to copy, the more durable the willingness to pay.

  1. Is it worth concentrating on? You are choosing one or two to own, not ten to

dabble in. A driver you will pursue at only half-effort is not a commitment.

Concentrate. The finish line is one or two Love drivers and one or two Utility attributes — not a long even list. Owning one driver to an extreme beats being slightly-above-average at six. Force the choice; do not let the user keep everything.

The interrogation

If a devil's-advocate skill such as Rude Q&A / asb-rude-qa is installed, invoke it with this brief: "Grill each proposed willingness-to-pay change. For each, attack whether the company genuinely OWNS it or is merely wishing: is there evidence it is already true or a credible path to it; is it self-consistent with the product, price, and other signals; can competitors copy it; and is it worth concentrating on versus the alternatives? Be especially hard on Love claims — an assumed 'our customers love us' with no advocacy behind it is the classic self-flattering error. Force the company down to one or two Love drivers and one or two Utility attributes. Do not let them keep everything." If it is not installed, run the interrogation yourself with the same posture: sharp, specific, unfair-if-useful questions with a collegial frame. Attack the claim, not the person. Use the Opposite Test — if the opposite of a claim is obvious nonsense, the claim said nothing ("customers want quality" — nobody wants low quality, so it is empty). Do not accept "it depends" or "we'll figure that out later."

Dwell when the answer is fuzzy; move on when it earns it. Stay on one change until it is genuinely defended, honestly cut, or moved to "considered and set aside." Three rounds on one driver is not a reason to wave it through.

Settle the Coercion plan

From the Phase 2 findings, commit to: which coercion reliance you will drop (and the Love/Utility reason to stay you will build in its place), and which honest mechanics you will keep. Be concrete. "Stop holding data hostage; ship an export and win the stay on Utility instead" is a commitment; "be less coercive" is not.

Lock it in

When the strategy is settled, confirm it explicitly with the user — this is the one big state change the skill drives toward. Write the owned Love driver(s), the Utility attribute(s) to deepen, and the Coercion plan into the "Validated & committed strategy" section, set committed: true, advance phase to done, and remove the ⚠️ IN PROGRESS note. It does not matter how many drivers survive — one strong, genuinely owned Love driver is an excellent result. What matters is that each is real, ownable, self-consistent, and worth concentrating on.

Then write the handoff — the work that comes after this skill and is not part of it. Name whichever the user is heading toward: turning the owned drivers into the case for a higher price (a separate price-raising exercise), turning a driver into marketing copy (positioning), or replacing dropped Coercion with the real reason to stay (retention and roadmap). This file is the input to that work; it is not that work.

Refusal and edge conditions

  • No real customers yet. With no paying base to audit, the Phase 1 inventory is

thin — you will have few real [have]s. Say so, keep it light, and let the weight fall on Phase 2, where the question becomes which desire to build toward, while flagging that every read is a hypothesis until real customers confirm it. Two adjustments follow. The fragility test has no base to run against — do not force it; ask it as a thought experiment about the customers you intend to win, and mark the answer hypothetical. And the Phase 3 ownership bar softens from "where is the evidence" to "is there a credible path," since you are committing which desire to build. Say so plainly.

  • "Just tell me what to charge." This skill does not set or raise the price. Map

the desire and commit the strategy; hand the pricing decision off as the next task rather than guessing a number.

  • "Our customers love us" with nothing behind it. This is the most common

self-flattering error and the reason the fragility test exists. Do not accept a claim of Love without advocacy evidence; if it is really Utility propped up by switching costs, say so — gently, but say it.

  • The user wants validation, not scrutiny. In Phase 3 especially, if the user is

seeking a rubber stamp for a driver they cannot actually own, name that and hold the bar. The value of this phase is the friction.