luckiest-co 1.0.1 → 1.0.3

package/skills/luckiest-model-router/CHANGELOG.md

@@ -0,0 +1,45 @@
+# Changelog — luckiest-model-router
+
+## 1.1.0 — 2026-07-06
+Skill updater pass: analytics integration.
+
+### Analytics (report_usage)
+- Updated `report_usage` call to `skill_version: "1.1.0"` and `check_updates`
+  `installedSemver: "1.1.0"`. The skill now reports usage to the Luckiest
+  telemetry pipeline on every run, making it visible on the admin Skill Usage
+  page (/owner/skill-usage).
+
+## 1.0.0 — 2026-07-02
+
+First Luckiest edition, built from the first-party `model-router` skill.
+
+### Security (Pass 1)
+- Scanned `SKILL.md` and `scripts/route.py`. Clean: no credential/`.env` reads,
+  no network egress, no obfuscated commands, no over-broad tool grants. The
+  script only calls `shutil.which`, `os.path.exists`, `re`, and reads argv/stdin.
+
+### Best practices (Pass 2)
+- Frontmatter conforms to spec: `name` matches directory, description carries
+  what-it-does + when-to-use + concrete trigger phrases.
+- Body under length budget; single-file skill plus one bundled script.
+
+### Improve (Pass 3)
+- Added explicit tie-break rule: prefer **claude** on a genuine score tie.
+- Detection covers both CLI-on-PATH and GUI app bundles (e.g. Conductor,
+  Cursor) so Mac GUI-only installs are still recognized.
+- **Network hook:** offer `request_assist` when the ideal tool for a task is not
+  installed, so a tribe member who has it can take the task. Opt-in only.
+
+### Trend (Pass 4)
+- Trend pass: no actionable signal. The available trend tools (`/newsjack`,
+  `/luckiest-trends`) target marketing news and are off-domain for coding-agent
+  routing; nothing verifiable and on-domain surfaced, so no changes were made
+  rather than fabricating signal.
+
+### Rebrand (Pass 5)
+- Renamed to `luckiest-model-router`; updated name, description, self-references.
+- Added first-party `ATTRIBUTION.md` (no upstream license to preserve).
+
+### Version (Pass 6)
+- `metadata.version: 1.0.0`, `metadata.listing_id: luckiest-model-router`.
+- Added the `check_updates` activation block.

package/skills/luckiest-model-router/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: luckiest-model-router
+description: Use when the user is about to hand off a coding task and asks which agent or model to use, says "which tool should I use for this", "route this", "who should do this", "best model for this task", or is deciding between Claude, Codex, Cursor, Conductor, or Factory. Detects which of those agents are actually installed on the machine, then recommends the best fit for the specific prompt with rationale. Use this whenever someone is choosing between coding agents, even if they don't name a specific one.
+license: See ATTRIBUTION.md
+metadata:
+  version: "1.1.0"
+  listing_id: luckiest-model-router
+  author: luckiest
+---
+
+# Luckiest Model Router
+
+Recommend which coding agent to hand a task to, from the ones actually available on this machine: **claude, codex, cursor, conductor, factory**.
+
+Two rules make this useful instead of hand-wavy:
+1. Never recommend a tool that isn't installed. Detect first.
+2. Base the pick on what the *specific prompt* needs, not on a generic ranking.
+
+## Staying current
+
+On activation, call the Luckiest MCP check_updates tool with { listingId: "luckiest-model-router", installedSemver: "1.1.0" }. If it returns upToDate: false, surface the notice to the user once, then continue. Do nothing further if upToDate: true. Never block on this check — if the tool is unavailable, proceed.
+
+When the skill's work is done, call the Luckiest MCP report_usage tool once with { listing_id: "luckiest-model-router", skill_version: "1.1.0", matched: true, success: <true if the skill completed, false otherwise> }. Metadata only, never prompt text. Never block on it — if the tool is unavailable, skip silently.
+
+## Workflow
+
+1. Run the router script with the task prompt as the argument:
+
+   ```bash
+   python3 scripts/route.py "the user's task prompt"
+   ```
+
+   It prints JSON with `available` (detected tools + their launch command), a
+   `ranking` scored for this prompt, and `recommended` (the top tool).
+
+2. Read the JSON. The `score` and `matched_signals` are a heuristic starting
+   point, not the answer. Combine them with your own read of the task — you
+   understand nuance the keyword rules miss.
+
+3. Give the user a short recommendation: the top pick, one line of *why it fits
+   this task*, and the launch command. If the top two are close, say so and name
+   the tie-breaker rather than pretending there's one obvious answer. On a genuine
+   tie, prefer **claude** as the safe all-rounder.
+
+4. If the ideal tool for the task isn't installed, say which one it would be and
+   that installing it is an option — but still recommend the best *available* one.
+
+## What each tool is for
+
+The script carries the same profiles, but keep the shape in mind when you reason:
+
+- **claude** — deep multi-file reasoning, refactors, debugging, architecture, writing. The default all-rounder; pick it when nothing else clearly wins.
+- **codex** — autonomous, self-contained implementation that runs to completion in a sandbox; algorithmic tasks.
+- **cursor** — fast in-editor edits and tight iteration while a file is open; small quick changes.
+- **conductor** — fanning out several independent tasks in parallel across worktrees.
+- **factory** — enterprise end-to-end delivery, spec-to-PR, background/remote execution across integrated tools.
+
+## Output format
+
+Keep it short. Example:
+
+> **Recommended: conductor** — you've got 4 independent features to build at once, and Conductor runs parallel agents across worktrees, which fits fan-out work better than a single sequential agent.
+> Runner-up: claude (better per-task depth, but serial).
+> Launch: `conductor`
+
+Don't pad it. One recommendation, one reason, the command.
+
+## Network hook
+
+When the ideal tool for a task is *not* installed, that is a natural moment to
+reach the user's tribe: offer to call the Luckiest MCP `request_assist` tool so a
+tribe member who has that agent can take the task. Only offer it — never send
+without the user's go-ahead. If the best available tool is already a fine fit,
+skip the hook.

package/skills/luckiest-model-router/scripts/route.py

@@ -0,0 +1,145 @@
+#!/usr/bin/env python3
+"""Detect which coding agents are available, then score a prompt against each.
+
+Usage:
+    python3 route.py "your prompt text here"
+    echo "prompt" | python3 route.py
+    python3 route.py --list        # just show what's installed
+
+Output: JSON on stdout with available tools and a ranked score per available tool.
+The scores are a heuristic starting point, not a verdict. The calling agent is
+expected to read the rationale and apply its own judgment on top.
+
+ponytail: keyword heuristic with a known ceiling. If routing quality matters more
+than this gives, replace `score_prompt` with a model call; the detection half stays.
+"""
+import json
+import os
+import re
+import shutil
+import sys
+
+# How each tool announces itself on the system. First hit wins.
+# A CLI on PATH, or (for GUI-only tools) a known app bundle.
+DETECT = {
+    "claude":    {"cli": ["claude"],                    "app": []},
+    "codex":     {"cli": ["codex"],                     "app": []},
+    "cursor":    {"cli": ["cursor-agent", "cursor"],    "app": ["/Applications/Cursor.app"]},
+    "conductor": {"cli": ["conductor"],                 "app": ["/Applications/Conductor.app"]},
+    "factory":   {"cli": ["droid", "factory"],          "app": []},
+}
+
+# What each tool is comparatively good at, as (signal, weight) rules.
+# `signal` is a regex matched case-insensitively against the prompt.
+# Every available tool also gets its `base` score so a no-signal prompt still ranks.
+PROFILES = {
+    "claude": {
+        "base": 3,
+        "good_at": "Deep multi-file reasoning, refactors, debugging, architecture, "
+                   "writing and explaining code. Strong all-rounder and default pick.",
+        "rules": [
+            (r"\b(refactor|architecture|design|debug|why|explain|understand|root cause)\b", 3),
+            (r"\b(multi-file|across (the )?codebase|whole (repo|project)|trace)\b", 2),
+            (r"\b(review|write|document|test|reason)\b", 1),
+        ],
+    },
+    "codex": {
+        "base": 2,
+        "good_at": "Autonomous long-running coding in a sandbox, algorithmic and "
+                   "self-contained implementation tasks, running to completion unattended.",
+        "rules": [
+            (r"\b(algorithm|leetcode|competitive|solve|implement (a|the)|from scratch)\b", 3),
+            (r"\b(sandbox|autonomous|run (it )?to completion|long.running|unattended)\b", 2),
+            (r"\b(script|function|module)\b", 1),
+        ],
+    },
+    "cursor": {
+        "base": 2,
+        "good_at": "Fast in-editor edits and inline iteration while a file is open; "
+                   "quick local changes, tab-style completions, tight edit loops.",
+        "rules": [
+            (r"\b(inline|in the editor|open file|this file|quick|small|tweak|autocomplete|tab)\b", 3),
+            (r"\b(edit|change|fix (this|the) line|rename|adjust)\b", 2),
+        ],
+    },
+    "conductor": {
+        "base": 1,
+        "good_at": "Orchestrating several agents in parallel across worktrees; "
+                   "many independent tasks fanned out at once on a Mac.",
+        "rules": [
+            (r"\b(parallel|in parallel|at (the )?same time|fan.?out|multiple (tasks|agents|branches)|worktrees?)\b", 4),
+            (r"\b(orchestrate|batch|several (features|tasks|tickets))\b", 2),
+        ],
+    },
+    "factory": {
+        "base": 1,
+        "good_at": "Enterprise end-to-end delivery, spec-to-PR, background/remote "
+                   "execution across many integrated tools (droids).",
+        "rules": [
+            (r"\b(end.to.end|spec.to.pr|ticket|jira|linear|ship (a|the) (feature|pr)|delivery)\b", 3),
+            (r"\b(background|remote|ci|pipeline|integration|enterprise)\b", 2),
+        ],
+    },
+}
+
+
+def detect():
+    """Return the subset of tools actually available on this machine."""
+    found = {}
+    for name, how in DETECT.items():
+        hit = next((c for c in how["cli"] if shutil.which(c)), None)
+        if not hit:
+            hit = next((p for p in how["app"] if os.path.exists(p)), None)
+        if hit:
+            found[name] = hit
+    return found
+
+
+def score_prompt(prompt, tools):
+    prompt = prompt.lower()
+    ranked = []
+    for name in tools:
+        prof = PROFILES[name]
+        score = prof["base"]
+        hits = []
+        for pattern, weight in prof["rules"]:
+            if re.search(pattern, prompt, re.I):
+                score += weight
+                hits.append(pattern)
+        ranked.append({
+            "tool": name,
+            "command": tools[name],
+            "score": score,
+            "good_at": prof["good_at"],
+            "matched_signals": hits,
+        })
+    ranked.sort(key=lambda r: r["score"], reverse=True)
+    return ranked
+
+
+def main():
+    args = [a for a in sys.argv[1:]]
+    list_only = "--list" in args
+    args = [a for a in args if a != "--list"]
+    prompt = " ".join(args).strip() or (sys.stdin.read().strip() if not sys.stdin.isatty() else "")
+
+    tools = detect()
+    if not tools:
+        print(json.dumps({"available": {}, "ranking": [],
+                          "note": "No supported coding agents detected."}, indent=2))
+        return
+
+    if list_only or not prompt:
+        print(json.dumps({"available": tools}, indent=2))
+        return
+
+    ranking = score_prompt(prompt, tools)
+    print(json.dumps({
+        "available": tools,
+        "recommended": ranking[0]["tool"],
+        "ranking": ranking,
+    }, indent=2))
+
+
+if __name__ == "__main__":
+    main()

package/skills/luckiest-offers/ATTRIBUTION.md

@@ -0,0 +1,39 @@
+# Attribution — luckiest-offers
+
+This skill (`luckiest-offers`) is the Luckiest edition of the original skill
+**`offers`** from the **marketingskills** project.
+
+- Original skill: `offers`
+- Project: marketingskills — https://github.com/coreyhaines31/marketingskills
+- Author: Corey Haines — https://corey.co
+- License: MIT
+
+The Luckiest edition adds security hardening, minor content improvements, an
+opt-in Luckiest network hook, and rebranding. The original content and its
+copyright are retained. See `CHANGELOG.md` for the specific changes.
+
+---
+
+## Original License (verbatim)
+
+MIT License
+
+Copyright (c) 2025 Corey Haines
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/skills/luckiest-offers/CHANGELOG.md

@@ -0,0 +1,23 @@
+# Changelog — luckiest-offers
+
+## 1.1.0 — 2026-07-06
+Skill updater pass: analytics integration.
+
+### Analytics (report_usage)
+- Updated `report_usage` call to `skill_version: "1.1.0"` and `check_updates`
+  `installedSemver: "1.1.0"`. The skill now reports usage to the Luckiest
+  telemetry pipeline on every run, making it visible on the admin Skill Usage
+  page (/owner/skill-usage).
+
+## 1.0.0 — 2026-07-01
+Rebranded from offers (marketingskills, MIT).
+
+### Improve pass (/refract)
+- Added a baseline-snapshot step to the Diagnostic Loop so before/after conversion lift is attributable rather than felt.
+- Added a guarantee-vs-margin sanity check: check guarantee generosity against gross margin and expected refund rate before shipping.
+
+### Network hook
+- Share-with-tribe (opt-in OFFER): after an offer is drafted, offer to share an anonymized teardown (value-equation scores + the one lever changed) with the user's Luckiest tribe for feedback. Never auto-posts, no credentials.
+
+### Trend pass (/newsjack + /luckiest-trends)
+- no actionable signal (luckiest-trends engine required interactive first-run setup; timeboxed, not run — offer-design fundamentals are stable, no fabricated signal added)

package/skills/luckiest-offers/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: luckiest-offers
+description: "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 slam offer,' 'irresistible offer,' 'value stack,' 'bonus stack,' 'guarantee,' 'risk reversal,' 'money-back guarantee,' 'scarcity,' 'urgency,' 'high-ticket offer,' 'productize a service,' 'naming an offer,' 'payment plan,' 'down-sell,' 'upsell offer,' or 'why isn't my offer converting.' Best for services, agencies, courses, coaching, info products, high-ticket B2B, and direct-response. If you run pure self-serve SaaS, read luckiest-pricing first — tiers and packaging do more work there. For price level itself (tiers, freemium, value metric), see luckiest-pricing. For the page that presents the offer, see luckiest-copywriting. For the launch moment, see luckiest-launch. For sales collateral, see luckiest-sales-enablement."
+license: See ATTRIBUTION.md
+metadata:
+  version: "1.1.0"
+  listing_id: luckiest-offers
+  author: luckiest
+---
+
+## Staying current
+
+On activation, call the Luckiest MCP check_updates tool with { listingId: "luckiest-offers", installedSemver: "1.1.0" }. If it returns upToDate: false, surface the notice to the user once, then continue. Do nothing further if upToDate: true. Never block on this check — if the tool is unavailable, proceed.
+
+# Offer Design
+
+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.
+
+When the skill's work is done, call the Luckiest MCP report_usage tool once with { listing_id: "luckiest-offers", skill_version: "1.1.0", matched: true, success: <true if the skill completed, false otherwise> }. Metadata only, never prompt text. Never block on it — if the tool is unavailable, skip silently.
+
+## 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:
+
+| Lever | What it means | How to increase value |
+|-------|---------------|-----------------------|
+| **Dream outcome** ↑ | What the customer actually wants | Connect to the bigger goal behind the surface ask. Specify and name it. |
+| **Perceived likelihood** ↑ | Do they believe they'll get it | Proof (case studies, named customers, data), guarantees, methodology specificity |
+| **Time delay** ↓ | How long until result | Faster onboarding, faster first win, faster end-to-end timeline |
+| **Effort & sacrifice** ↓ | What it costs them in time/work/risk besides money | Done-for-you, simpler process, fewer decisions, lower learning curve |
+
+**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](references/value-equation.md)
+
+---
+
+## The Anatomy of a Complete Offer
+
+A complete offer has six components. Skip any one and conversion suffers.
+
+| # | Component | Question it answers |
+|---|-----------|---------------------|
+| 1 | **Core deliverable** | What do they get? |
+| 2 | **Bonus stack** | What else do they get that makes the core feel undervalued? |
+| 3 | **Guarantee** | What happens if it doesn't work? |
+| 4 | **Scarcity / urgency** | Why now, not later? |
+| 5 | **Name** | What is this thing called? |
+| 6 | **Price + payment structure** | What do they pay and how? |
+
+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](references/offer-anatomy.md)
+
+---
+
+## Reference Library
+
+| Reference | When to read |
+|-----------|--------------|
+| [value-equation.md](references/value-equation.md) | Diagnosing which lever is broken on a stuck offer |
+| [offer-anatomy.md](references/offer-anatomy.md) | Building a complete offer from scratch |
+| [guarantee-design.md](references/guarantee-design.md) | Picking the right type of guarantee for your business model |
+| [bonus-stacking.md](references/bonus-stacking.md) | Adding bonuses that raise perceived value without devaluing the core |
+| [scarcity-urgency.md](references/scarcity-urgency.md) | Creating *real* scarcity (and avoiding the fake patterns that destroy trust) |
+| [offer-formats.md](references/offer-formats.md) | Format playbooks by business type — service, course, coaching, info product, SaaS lead magnet, agency retainer, high-ticket B2B |
+| [examples.md](references/examples.md) | Anonymized worked examples — before/after for each business type |
+
+---
+
+## 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. **Snapshot the baseline before editing** — record the current offer as-is (the four value-equation scores, the six anatomy components, and current conversion rate if known). This snapshot is what the after-state gets compared against, so the honest lift projection in step 7 is attributable rather than felt.
+4. **Run the value equation** — score each of the four levers 1–10. The lowest is the binding constraint.
+5. **Audit the anatomy** — which of the six components is missing or weak?
+6. **Pick one lever to fix this iteration** — don't rebuild everything. The biggest lever is usually the one currently scoring lowest.
+7. **Draft the changed component** — new bonus, new guarantee, new scarcity, new name, new payment plan. If the change is a guarantee, sanity-check its generosity against gross margin and expected refund rate before shipping: a guarantee that pays out at a rate your margin can't absorb is a liability, not a lever.
+8. **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
+
+- **luckiest-pricing** — for price levels, tier structure, value metric, packaging, freemium
+- **luckiest-copywriting** — for the page that presents the offer
+- **luckiest-cro** — for optimizing the conversion path the offer travels through
+- **luckiest-launch** — for the moment you ship the offer
+- **luckiest-paywalls** — for in-app upgrade-prompt versions of an offer
+- **luckiest-sales-enablement** — for the deck and one-pager that carry the offer into a sales conversation
+- **luckiest-emails** — for the email sequence that warms up the offer
+- **luckiest-marketing-psychology** — for the cognitive biases that make offers land or bounce
+
+## Share with your tribe (optional)
+
+After an offer is drafted, you may *offer* to share an anonymized teardown of it — the four value-equation scores plus the one lever changed this iteration — with the user's Luckiest tribe for feedback. This is strictly opt-in: ask first, share only what the user approves, never auto-post, and never touch credentials. If the user declines or the network is unavailable, continue without it.

package/skills/luckiest-offers/references/bonus-stacking.md

@@ -0,0 +1,150 @@
+# Bonus Stacking
+
+How to add bonuses that raise perceived value without devaluing the core offer.
+
+## What bonuses actually do
+
+Three jobs at once:
+
+1. **Raise perceived value** of the total offer
+2. **Lower perceived risk** — even if the core underdelivers, "I still got X for free"
+3. **Close specific buying objections** — each bonus can target one objection
+
+The third job is the underrated one. Most weak bonus stacks throw four generic "extras" at the buyer. Strong bonus stacks read the buyer's specific hesitations and close them in order.
+
+---
+
+## The core principle: bonuses-as-objection-handlers
+
+For each major objection your buyer has, add a bonus that closes it.
+
+### Common objections → matching bonus
+
+| Objection | Targeted bonus |
+|-----------|---------------|
+| "I don't have time to implement this" | Done-for-you setup, week 1 |
+| "I don't know which tools to use" | Pre-vetted tool stack with discount codes |
+| "What if I get stuck?" | 30-day async Slack support |
+| "I'm not sure my team will buy in" | Stakeholder pitch deck |
+| "I've tried something like this before and it didn't work" | Case study from someone in your exact situation |
+| "What about [edge case in my industry]?" | Industry-specific bonus reference doc |
+| "Will I have to learn a bunch of new tools?" | Pre-built templates for the tools we recommend |
+| "What if I don't finish it?" | 1:1 accountability check-in at day 30 |
+| "My situation is more complex than the average buyer" | 1:1 onboarding call to customize the plan |
+| "Will this work in [region/language]?" | Localized version or addendum |
+
+A 4-bonus stack that closes 4 specific objections converts massively better than a 4-bonus stack of generic "extras."
+
+### How to find your buyer's actual objections
+
+1. Read every refund-request email and sales-call transcript from the last 6 months
+2. Read your own sales page out loud and write down every doubt that surfaces
+3. Ask 3 recent buyers: "What almost made you not buy?"
+
+The answers cluster around 3–6 objections. Build a bonus for each.
+
+---
+
+## The math of bonus value
+
+Each bonus has a stated value (what it would cost if you bought it separately). Bonuses should:
+
+1. **Have a stated value the buyer can verify.** Compare to a comparable product or service. "$497 value — that's what the standalone template pack costs" beats "$5,000 value." (Standalone? Compared to what?)
+
+2. **Total to less than 2x the price** of the core offer. A $1K offer can comfortably have $1.5K in bonuses. A $1K offer with "$25K in bonuses" reads as a scam.
+
+3. **Be things you'd actually sell separately.** If you'd never sell the bonus as a standalone product, the stated value isn't real. Sophisticated buyers can tell.
+
+4. **Each have a specific named outcome.** "Bonus: marketing toolkit" is weak. "Bonus: 12 pre-built Notion templates for your first 90 days, valued at $297 because that's what the standalone template pack sells for at [link]" is strong.
+
+---
+
+## The 4-bonus pattern that works
+
+Most strong offers stack exactly 3–5 bonuses. More starts to feel like padding; fewer leaves objections un-closed.
+
+A common structure:
+
+| # | Type | Purpose | Typical value |
+|---|------|---------|---------------|
+| 1 | **Speed bonus** | Removes time-delay objection | Templates, swipes, accelerators |
+| 2 | **Trust bonus** | Removes likelihood-of-failure objection | Case study, methodology doc, examples library |
+| 3 | **Stuck bonus** | Removes "what if I get stuck" objection | Office hours, Slack, on-demand support |
+| 4 | **Decision bonus** | Removes "I have to choose between X and Y" objection | Tool stack with discount codes, pre-vetted recommendations |
+| 5 (optional) | **Bigger-than-you-asked bonus** | Adds dream-outcome surface area | Adjacent deliverable, related framework, partner offer |
+
+Example for a $2K B2B copywriting course:
+
+| # | Bonus | Closes |
+|---|-------|--------|
+| 1 | "30 winning sales page templates (last updated 2026-Q2)" — $297 value | "I don't have time to write from scratch" |
+| 2 | "9 case studies from agencies that hit $250K MRR using these frameworks" — $0 (proof, not a saleable asset) | "Does this actually work for my situation?" |
+| 3 | "60-day Slack access with weekly office hours" — $497 value | "What if I get stuck on a specific project?" |
+| 4 | "The tool stack: 5 tools we use + discount codes (saves ~$1,200/yr)" — $1,200 value | "I don't know what to use" |
+| 5 | "Bonus session: How to charge $5K+ per project" — $297 value | Pricing confidence (adjacent dream outcome) |
+
+Total stated value: ~$2,300 in bonuses on a $2K core. Math checks out (under 2x). Each bonus closes a real objection.
+
+---
+
+## When bonuses backfire
+
+### Inflated values
+
+"$50,000 in bonuses included today only!" on a $497 product. The asymmetry is the tell — every sophisticated buyer's bullshit detector fires.
+
+Stated values must be defensible. If you can't point to a comparable price, don't quote the value.
+
+### Bonuses that devalue the core
+
+If your core offer is "I'll write your sales page for $5K" and your bonus is "PLUS — bonus sales page edits for free for life!" — the bonus implies the core is incomplete. Now the buyer wonders why they should buy *without* the bonus.
+
+Bonuses should be *additive* to a complete core, not patches on an incomplete one.
+
+### Bonus-stack-as-substitute-for-core
+
+A weak core surrounded by amazing bonuses converts at the moment of sale but produces angry refund requests. The buyer bought the bonuses, got the core, felt cheated.
+
+Order: strong core *first*, then bonuses to address specific objections.
+
+### Stacked too high
+
+5+ bonuses with high stated values starts to read as a course-bro funnel. Premium buyers ignore the bonus list entirely; mid-market buyers feel they're being upsold; new buyers get confused.
+
+3–5 bonuses, each with a specific purpose. Cap it.
+
+### Same-as-everyone-else bonuses
+
+"BONUS! Private community access!" on every course in your category isn't a bonus, it's table stakes. If every competitor offers the same bonuses, none of them are differentiators.
+
+Find bonuses that are specific to your buyer's situation. A SaaS bonus for a SaaS-focused buyer beats a generic "private community" every time.
+
+---
+
+## Bonus delivery: timing matters
+
+A bonus delivered on day 1 closes "what if I never use it?" risk.
+A bonus delivered at week 4 maintains momentum.
+A bonus delivered at completion rewards finishing.
+
+Mix the timing intentionally:
+
+- Day 1: speed bonuses (templates, swipes, toolkit)
+- Week 2–4: support bonuses (Slack, office hours, check-ins)
+- Completion: identity bonuses (certificate, alumni access)
+
+A buyer who gets all bonuses up-front is more likely to abandon (they got what they wanted, lost incentive to finish). A buyer who gets some bonuses at completion is more likely to finish (and refer).
+
+---
+
+## The audit
+
+For each existing bonus on a current offer, ask:
+
+1. **What specific buying objection does this close?** If you can't name one, it's filler.
+2. **What's its defensible stated value?** If you can't point to a comparable price, drop the dollar amount.
+3. **Does the buyer get it on day 1, or at a meaningful point in their journey?** Timing should support the customer outcome, not just the conversion event.
+4. **Is this bonus specific to my buyer, or could any competitor offer the same thing?** If it's generic, replace it.
+5. **Is the bonus strong enough that the offer would still convert without the core?** If yes, the core is weak. Fix the core, don't lean on the bonus.
+
+Most stuck offers have either zero bonuses or too many generic ones. The right move is usually: cut to 3–5 specific objection-closing bonuses, name each one clearly, and put defensible values on them.