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
- Distinctive: line 8
Use this skill to build offers systematically instead of brainstorming randomly.
- Distinctive: line 12
Run live market research before making strong claims about demand, pricing, guarantees, objections, or competitor patterns.
- Distinctive: line 26
Use when the user starts with a topic, niche, market, audience, or problem and wants a net-new offer.
- Distinctive: line 29
Use when the user already has an offer and wants to strengthen positioning, pricing, guarantees, tiering, or conversion quality.
- Distinctive: line 32
Use when the user wants to keep the core mechanism but retarget it to a different niche, buyer, or channel.
- Distinctive: line 46
If key inputs are missing, make reasonable assumptions only when the user clearly wants exploratory ideation.
- Very specific: line 49
Use web_search and web_fetch to gather current evidence before deciding on:
- Very specific: line 64
Use the value equation from references/framework.md.
- Distinctive: line 103
do not add random bonuses
- Distinctive: line 105
do not recommend guarantees that depend on uncontrollable variables
- Distinctive: line 106
do not recommend recurring pricing unless recurring value is credible
- Distinctive: line 142
If the score is weak, fix the weakest levers first instead of rewriting everything randomly.
- Distinctive: line 178
If the user asks for an offer quickly, still do a lightweight live research pass before finalizing.
- Distinctive: line 180
If evidence is thin, say:
≈ “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.
Files
Offer Creation
Use this skill to build offers systematically instead of brainstorming randomly.
Core rules
- Run live market research before making strong claims about demand, pricing, guarantees, objections, or competitor patterns.
- 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.
- 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 toolsreferences/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:
- weak outcome
- weak certainty / proof
- too much buyer effort
- too much delay
- poor economics or fulfillment feasibility
- 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
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- FakharEAli/book-skills★ 3same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository12 other files it gives its agents.
- audience-content-osSkill
- buyer-signal-list-researchSkill
- cold-offer-reviewSkill
- google-maps-list-builderSkill
- google-maps-owner-email-finderSkill
- icp-prompt-builderSkill
- linkedin-content-writerSkill
- list-builderSkill
- list-expanderSkill
- outbound-funnel-economicsSkill
- tiktok-slideshow-machineSkill
- x-content-writerSkill
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
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.

