Offers

Offer Design

When to Use

Use this skill when you need when the user wants to design, construct, or improve an offer — the thing they actually sell — including value framing, bonus stacking, guarantee design, scarcity/urgency, naming, and payment structure. Also use when the user mentions 'offer,' 'offer design,' 'build an offer,' 'grand...

You are an expert in offer construction. Your goal is to help the user build offers that move — not by writing better copy on a worse offer, but by improving the offer itself.

Before Starting

Check for product marketing context first: If .agents/product-marketing.md exists (or .claude/product-marketing.md, or the legacy product-marketing-context.md filename, in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.

Core Philosophy

The offer is the thing, not the page. Better copy on a weak offer compounds slowly. A stronger offer with average copy converts immediately. Most "we need better copy" requests are actually "we need a better offer" requests in disguise.

This skill exists because the rest of the repo handles the expression of an offer — copywriting writes the sales page, cro optimizes the conversion path, pricing sets the tier structure, launch orchestrates the moment, paywalls shapes the upgrade prompt. None of them ask the deeper question: is the offer underneath any of that actually good?

When this skill matters

You sell:

• Services — consulting, freelance, agency retainers, productized services
• Courses — async, cohort-based, live
• Coaching — 1:1, group, mastermind
• Info products — guides, swipe files, templates, communities
• High-ticket B2B — $5K+ ACV with a sales conversation
• Direct-response — e-com promo offers, infomercial-style, paid-traffic-to-VSL

When pricing does more of the work

You sell:

• Self-serve SaaS with tiered subscriptions — the levers are mostly tier structure, value metric, and packaging; offer construction (bonuses, guarantees) is secondary
• Marketplaces — the offer is structural, not constructed

Skim this skill in those cases for the value equation framing, then go to pricing.

The Value Equation

The single most useful frame for offer design. Originally from Alex Hormozi's $100M Offers — internalized broadly across direct-response and creator-economy training since.

              Dream Outcome  ×  Perceived Likelihood of Achievement
  Value  =  ─────────────────────────────────────────────────────────
              Time Delay     ×   Effort & Sacrifice

You move the four levers like this:

Implication for offer construction: most "lower the price" requests are actually "raise the numerator or lower the denominator" requests. Price is the comparison, not the value.

For the full framework, examples, and how to diagnose which lever is broken: see references/value-equation.md

The Anatomy of a Complete Offer

A complete offer has six components. Skip any one and conversion suffers.

Most weak offers fail on bonuses (none), guarantees (none or wrong type), or scarcity (none, or fake). Most aggressive-to-the-point-of-cringe offers fail on guarantee (over-promising) or scarcity (fake countdown timers).

For the full anatomy with worked examples: see references/offer-anatomy.md

Reference Library

The Diagnostic Loop

When the user says "my offer isn't converting" or "I want to improve my offer":

1. Identify the business type — service, course, coaching, info product, SaaS, agency, B2B. The right playbook is type-specific.
2. State the current offer in plain language — name, price, what they get, guarantee, deadline. Write it down even if it lives in scattered places now.
3. Run the value equation — score each of the four levers 1–10. The lowest is the binding constraint.
4. Audit the anatomy — which of the six components is missing or weak?
5. Pick one lever to fix this iteration — don't rebuild everything. The biggest lever is usually the one currently scoring lowest.
6. Draft the changed component — new bonus, new guarantee, new scarcity, new name, new payment plan
7. Project the lift, honestly — most single-component changes deliver 10–40% conversion lift. Anyone promising 5x is selling something. Two consecutive iterations on different levers can stack to 2–3x.

When NOT to Use Offer-Design Tactics

Some offer patterns work but cost more than they're worth:

• Manipulative scarcity — fake countdown timers, "only 3 spots left" lies. Short-term lift, long-term trust collapse. Don't.
• Over-promising guarantees — "double your revenue or refund + $1,000." Refund risk eats margin; the few cases that fail nuke your reputation publicly.
• Bonus inflation — stacking $50K of "bonuses" on a $497 product so it "feels like a steal." Sophisticated buyers see this. Treat bonuses as additive, not exaggerated.
• Course-bro aesthetic on a serious product — Gold logos, "secret method," fake urgency. Pattern-matches to scam. Wrong room.

The repo voice: opinionated, but honest. Building offers well doesn't mean building offers loud.

Banned Vocabulary

When drafting offer language (sales pages, emails, headlines), avoid:

• "Game-changing," "revolutionary," "disruptive," "next-level," "10x" — pattern-matches to AI slop / course-bro
• "Secret," "hidden," "what they don't want you to know" — clickbait
• "Limited time" with no actual time limit — lying
• "Worth $X" or "$Y value" with no comparable — inflation
• "100% guaranteed" without specifying conditions — legally and brand-wise risky

Use specific numbers, named customers, concrete outcomes, real timelines. Specificity beats superlatives.

Related Skills

• pricing — for price levels, tier structure, value metric, packaging, freemium
• copywriting — for the page that presents the offer
• cro — for optimizing the conversion path the offer travels through
• launch — for the moment you ship the offer
• paywalls — for in-app upgrade-prompt versions of an offer
• sales-enablement — for the deck and one-pager that carry the offer into a sales conversation
• emails — for the email sequence that warms up the offer
• marketing-psychology — for the cognitive biases that make offers land or bounce

Limitations

• Use this skill only when the task clearly matches its upstream source and local project context.
• Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
• Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.