agentleFS
Moussaoui-GhilesMoussaoui-Ghiles/claude-skills/skills/offer-creation/SKILL.md

offer-creation

Skill4 starsChanged 2 months agoMITView on GitHub

Create, improve, reposition, and evaluate business offers using live market research plus structured offer design. Use when the task is to: (1) turn a topic, niche, or problem into an offer, (2) improve an existing offer, (3) adapt an offer to a new market or segment, (4) choose pricing, guarantees, tiers, or qualification rules, or (5) analyze whether an offer is strong enough to sell.

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 12 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈12

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill to build offers systematically instead of brainstorming randomly.

    line 8
  2. Distinctive:

    Run live market research before making strong claims about demand, pricing, guarantees, objections, or competitor patterns.

    line 12
  3. Distinctive:

    Use when the user starts with a topic, niche, market, audience, or problem and wants a net-new offer.

    line 26
  4. Distinctive:

    Use when the user already has an offer and wants to strengthen positioning, pricing, guarantees, tiering, or conversion quality.

    line 29
  5. Distinctive:

    Use when the user wants to keep the core mechanism but retarget it to a different niche, buyer, or channel.

    line 32
  6. Distinctive:

    If key inputs are missing, make reasonable assumptions only when the user clearly wants exploratory ideation.

    line 46
  7. Very specific:

    Use web_search and web_fetch to gather current evidence before deciding on:

    line 49
  8. Very specific:

    Use the value equation from references/framework.md.

    line 64
  9. Distinctive:

    do not add random bonuses

    line 103
  10. Distinctive:

    do not recommend guarantees that depend on uncontrollable variables

    line 105
  11. Distinctive:

    do not recommend recurring pricing unless recurring value is credible

    line 106
  12. Distinctive:

    If the score is weak, fix the weakest levers first instead of rewriting everything randomly.

    line 142
  13. Distinctive:

    If the user asks for an offer quickly, still do a lightweight live research pass before finalizing.

    line 178
  14. Distinctive:

    If evidence is thin, say:

    line 180

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Offer Creation

Use this skill to build offers systematically instead of brainstorming randomly.

Core rules

  1. Run live market research before making strong claims about demand, pricing, guarantees, objections, or competitor patterns.
  2. Apply three frameworks in order: Hormozi (what to build) → Haynes (how to frame it) → Fazio (how to deliver it). Do not skip the operational layer.
  3. An offer is not complete until it has a fulfillment factory with mapped stations, an intake form, a pre-call sequence, a communication cadence, and a case study production process.

Always read references/framework.md before starting any work. It contains the full detail on every concept referenced in this skill — value equation, "you're f***ing me" scale, desire stacking, guarantees, pricing, fulfillment factory, intake forms, pre-call sequence, communication cadence, case study flywheel. Without it, you will produce shallow output.

Also read before starting:

  • references/market-research.md — live research workflow using web tools
  • references/output-template.md — final output structure

Entry modes

Choose one mode first.

1. Topic → offer

Use when the user starts with a topic, niche, market, audience, or problem and wants a net-new offer.

2. Offer → improve

Use when the user already has an offer and wants to strengthen positioning, pricing, guarantees, tiering, or conversion quality.

3. Offer → adapt

Use when the user wants to keep the core mechanism but retarget it to a different niche, buyer, or channel.

Workflow

Step 1: Clarify the starting point

Capture what is known:

  • topic / niche / buyer
  • painful problem
  • desired outcome
  • current offer if one exists
  • current proof / authority / case studies
  • delivery constraints
  • preferred business model if specified

If key inputs are missing, make reasonable assumptions only when the user clearly wants exploratory ideation. Otherwise ask for the missing information.

Step 2: Run live market research

Use web_search and web_fetch to gather current evidence before deciding on:

  • pain intensity
  • buyer language
  • competitor offers
  • pricing bands
  • guarantee patterns
  • objections
  • whitespace
  • whether the offer likely fits cold traffic, outbound, or only warmer channels

Follow references/market-research.md.

Minimum standard: do not present claims about current markets as facts unless they are supported by URLs you actually checked.

Step 3: Build or diagnose the offer (Hormozi — what to build)

Use the value equation from references/framework.md.

At minimum, evaluate:

  • dream outcome
  • perceived likelihood
  • time delay
  • effort and sacrifice

Then improve the offer by:

  • increasing desired upside
  • increasing certainty
  • reducing time to result
  • reducing buyer effort and friction

Step 4: Pressure-test the framing (Haynes — how to frame it)

Apply these checks from references/framework.md:

  • "You're f***ing me" scale: does value flip absurdly in the buyer's favor at EVERY phase? Check each phase independently (diagnostic, build, retainer). If any phase fails, restructure it.
  • Costly not expensive: what does NOT buying cost them? That number must dwarf your price. Calculate both sides explicitly.
  • Desire density: for premium offers, are 3-5 independently compelling desires stacked? Rich buyers buy on desire density, not price.
  • Tier check: do the tiers (if any) improve speed and certainty at each level? Not every offer needs all three tiers — if stakes are too high for DIY, skip it.
  • 30-day recurring value test: if the offer has a retainer, can the client point to what they received THIS month that is worth more than what they paid? Name the specific monthly deliverable.

Step 5: Construct the offer

Build these parts explicitly:

  • positioning
  • core promise
  • mechanism
  • deliverable stack
  • desire stack when useful
  • tiering when useful
  • pricing model
  • guarantee or risk reversal
  • qualification rules
  • urgency / incentive only if justified

Rules:

  • sell outcomes, not vague services
  • make the offer concrete
  • do not add random bonuses
  • price from value, certainty, and economics
  • do not recommend guarantees that depend on uncontrollable variables
  • do not recommend recurring pricing unless recurring value is credible

Step 6: Build the fulfillment factory (Fazio — how to deliver it)

This is the operational blueprint. Use references/framework.md fulfillment factory section.

Build these components:

Fulfillment factory stations: Map every step of delivery as a station. Each station: what happens, who does it (you / AI / automation / partner / client), how long. Map separate factories for each phase (diagnostic, build, retainer) and each tier (DIY/DWY/DFY) if applicable. Calculate total active time per engagement and capacity (how many clients simultaneously).

Client intelligence extraction (intake form): Design a structured 20-30 question intake form. Every question must tie to a delivery station. Sections: basics, current state, problem specifics, access/contacts. Sent immediately after payment. Takes 20-30 minutes to complete.

Pre-call consumption sequence: Design 3 touchpoints between booking and sales call. Touchpoint 1: confirmation + short video (what happens on the call, sample deliverable). Touchpoint 2: one teaching insight that positions expertise. Touchpoint 3: day-before reminder + guarantee + urgency. All automated.

Communication cadence: Define the update rhythm for each phase. Specify what, when, and through what channel. The client should never have to ask "what is happening?" Do not tell them about the cadence — just execute it consistently.

Case study production: Build into delivery by default. Capture "before" at intake, "after" at delivery, ask permission at 90 days. Every client becomes a case study. Case studies feed content. Content attracts new clients. Track case study production as a delivery metric.

Step 7: Check delivery feasibility

Reject or downgrade offers that are attractive on paper but weak operationally.

Evaluate:

  • repeatability
  • margin potential
  • buyer implementation burden
  • proof requirements
  • automation or systemization potential where relevant
  • risk of churn or fulfillment breakdown
  • whether the core process is documented clearly enough to repeat and improve
  • whether the offer can work through cold traffic or outbound if scale is a goal
  • 80/20 ratio: is 80% of energy on acquisition and 20% on fulfillment? If fulfillment is consuming too much, the factory is not built right

For service offers, distinguish mindful work from mindless work and push repeatable mindless work toward automation or systemization where realistic.

Step 8: Score and refine

Score the offer on the rubric in references/framework.md.

If the score is weak, fix the weakest levers first instead of rewriting everything randomly.

Typical fix order:

  1. weak outcome
  2. weak certainty / proof
  3. too much buyer effort
  4. too much delay
  5. poor economics or fulfillment feasibility
  6. unclear qualification

Step 9: Return the final output

Use references/output-template.md.

Always include:

  • a one-line offer
  • the full offer design
  • why it should work
  • weaknesses / risks
  • at least 2 variants when the task is exploratory or strategic

Quality bar

Good outputs are:

  • evidence-backed
  • concrete
  • economically sensible
  • operationally feasible
  • specific about who it is for and not for

Bad outputs are:

  • generic
  • copied from market clichés
  • priced only from competitor averages
  • full of fake certainty
  • loaded with random bonuses that do not improve the value equation

Default behavior

If the user asks for an offer quickly, still do a lightweight live research pass before finalizing.

If evidence is thin, say:

  • what is known
  • what is inferred
  • what needs validation next

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.