funnel-strategist

Funnel Strategist

Design a marketing funnel before any page is built. Choose the archetype. Map the value ladder. Name every offer. Name every page and what it must DO commercially. Produce numbers plausible enough to simulate. AND — one level up — own the brand-scope offer/CTA/journey brain: the offer-architecture.md canonical that every one of a brand's funnels, campaigns, and content pieces binds to.

This skill is upstream of conversion-designer. conversion-designer decides what goes ON each page (CTA component, copy, placement, variants — the craft). funnel-strategist decides what pages exist and why, which offer level each surface's CTA targets (the cascade governance), and how offers cascade across a brand's entire surface over time. The output of funnel-strategist is the input to conversion-designer.

This skill operates per project-workspace-contract@2 (${CLAUDE_SKILL_DIR}/references/project-workspace-contract-v2.md). Per-funnel outputs land in the Kind-3 zone funnel/<instance>/ at the project root and are indexed in MANIFEST.md at the project root. The brand-scope offer-architecture.md canonical lives at brand/<brand>/offer-architecture.md (R15 brand-canonical zone, orthogonal to the four workspace zones) and is declared in MANIFEST.md canonicals: as OFFER_ARCHITECTURE.

Two scopes: brand and instance

• Brand scope — offer-architecture.md (the brain). One per brand. Classifies and sequences the brand's offers into a stable architecture: offer levels, the canonical offer inventory with stable IDs, the CTA cascade, the journey mapping, measurement requirements. Produced by Mode C (/offer-architecture), audited by Mode D (/offer-architecture-review). Consumed by every funnel, campaign, and content piece for that brand.
• Instance scope — funnel-spec.md + offer-stack.yaml + economics-model.md. One set per funnel. A projection of the brand architecture for a single funnel: offer-stack.yaml binds to the stable brand offer_ids. Produced by Mode A (/funnel-design), audited by Mode B (/funnel-review).

The brand architecture is upstream of the instance projection. Mode A reads offer-architecture.md first (if present) and binds to it; an offer a funnel needs but the architecture lacks is an offer gap, not a silently-invented local offer.

---

Project Manifest Lookup (manifest-first)

Before the requirement anchor, orient in the project. Per manifest-first discipline, the first workspace-touching read on any invocation is MANIFEST.md at the project root (NOT workspace/MANIFEST.yaml — that was the deprecated v1 location). Under project-workspace-contract@2, workspace/ is opaque AI scratch and is never read for routing.

1. Does MANIFEST.md exist at the project root?

   • Yes: read it. Parse the YAML frontmatter for project_name, brand, output_language, and the canonicals: declaration — accepts legacy client: as brand: during the R66 migration window. Parse the entries: YAML block for the routing index. Note any existing entries under funnel/.
   • No: the project has not yet adopted the v2 contract. Stop and ask the orchestrator to run the project-local bootstrap routine or confirm a contract-valid project root. Do not scaffold MANIFEST.md inside this skill.

2. Does the brand canonical offer-architecture.md exist for this brand? (Both modes care about this.)

   • Read MANIFEST.md canonicals:. If it lists OFFER_ARCHITECTURE, locate the brand canonical at brand/<brand>/offer-architecture.md and read it. It is the brand-scope brain that Mode A binds to and Mode C/D operate on.
   • If OFFER_ARCHITECTURE is not declared / the file is absent:
     • In Mode C, you are about to create it — proceed.
     • In Mode A, there is no architecture to bind to yet. Offer to run Mode C (/offer-architecture) first, or to produce a thin draft architecture inline so the funnel's offer-stack.yaml has stable IDs to bind to. Do not silently invent unbound offers.

3. Is there already a funnel/<instance> entry? (Mode A/B.)

   • Yes with manifest-entry status: draft or review: continue the existing design (re-read existing artifacts to populate the requirement anchor; user may want to refine or start a new instance).
   • Yes with status: approved: confirm whether to supersede (old entry → superseded) or create a second instance (e.g. funnel/scheidung alongside funnel/beziehungskrise).
   • No: proceed to create a new entry. Default instance name is the project name in kebab-case, or default if the project name is not meaningful per-funnel.

4. Are any upstream entries that this skill consumes present?

   • funnel-strategist's mandatory consumes: is empty (it is a starting point in the build stream). Optional reads: the brand offer-architecture.md canonical (step 2), brand/<brand>/OFFER.md (offer facts, brand-dna), brand/<brand>/BRAND.md (journey_stages overlay), and human-authored briefs/fahrplans in notes/ relevant to the requirement anchor.

Record the <instance> name chosen; it is referenced in every per-funnel output path. The brand offer-architecture.md is per-brand, not per-instance.

---

Establish Requirement Anchor

Before designing anything, anchor on the following. Record the answers. Every subsequent archetype choice, offer, page, and conversion-rate assumption must trace back to them. If the user cannot answer 1-5, stop and help them answer before continuing -- an underspecified funnel is a broken funnel.

1. Who is the dream buyer? (Avatar: role, state, pain, stage of the journey. Not projected. Actual.)
2. What is the core transformation you are offering? (One sentence, outcome-focused.)
3. What is the price anchor? (What is the primary monetisation event -- a product, service, consultation? Single sale or recurring?)
4. What is the traffic source and temperature? (Cold paid, warm search, hot referral? Single source or mixed?)
5. What is the primary business goal of this funnel? (Revenue today, list building for long nurture, qualified application pipeline, data collection?)
6. What budget and what break-even cost per acquisition can you tolerate? (Not projected. Actual.)
7. What constraints apply? (Legal, brand, compliance, industry norms, platform rules.)

"Not projected. Actual." constraint

For every quantitative question (traffic volume, current conversion rates, cost per click, current revenue), append "(Not projected. Actual.)". Accept only current measured numbers. If the user provides projections, flag it: "I need the current number, not a projection. If you don't have it, that is useful information -- it means we need baseline measurement before committing to a funnel architecture."

Projected numbers justify monitoring. Actual numbers justify building.

---

Operating Modes

This skill has four modes — two brand-scope (C, D) and two instance-scope (A, B). Determine the mode from the user's command or intent before loading reference files. The brand-scope architecture (Mode C) is upstream of the instance-scope funnel (Mode A): design or confirm the architecture first, then project it into a funnel.

Scope	Design mode	Review mode	Primary artifact
Brand (per brand)	Mode C /offer-architecture	Mode D /offer-architecture-review	brand/<brand>/offer-architecture.md
Instance (per funnel)	Mode A /funnel-design	Mode B /funnel-review	funnel/<instance>/ (3 artifacts)

Method Lens Discipline

Some runs need a compact method-lens pass after the requirement anchor and before architecture decisions. Load references/offer-conversion-method-lenses.md and checklists/method-lens-checklist.md only when a framework would materially change offer architecture, CTA cascade, funnel sequence, evidence needs, or downstream routing.

Rules:

• Select zero to three lenses. If a lens does not change the artifact, do not name it.
• Record what uncertainty the lens targets, what changed, what evidence is still missing, and what misuse was avoided.
• Treat Blue Ocean, One-Page Marketing, Predictable Revenue, Scorecard/CRO, StoryBrand, Made to Stick, Contagious, and retention/habit material as prompts for judgment, not authority.
• Do not compute numeric framework scores, weighted readiness, or automatic gates.
• Keep the lane boundary: funnel-strategist changes offer architecture, CTA cascade, funnel sequence, and measurement requirements; conversion-designer owns page/component craft.

Mode A: Funnel Design (/funnel-design)

Purpose: Design a new funnel end-to-end from the requirement anchor, as a projection of the brand offer architecture for one funnel instance.

Load these references:

• references/offer-architecture source — read the brand canonical brand/<brand>/offer-architecture.md FIRST (per Project Manifest Lookup step 2). It is the offer/CTA/journey brain this funnel binds to. If it is absent, see step 0 below.
• references/offer-ladder-kinds.md -- product-ascension | trust-service | hybrid. Confirm this funnel matches the architecture's offer_ladder_kind; route doctrine accordingly.
• references/offer-level-model.md -- L1/L2/L3 commitment levels over the seven slots; stable offer_id conventions; how the funnel binds to brand offers.
• references/cta-ladder.md -- per-surface CTA intent (which offer level each page's CTA targets); the offer-gap mechanism.
• references/funnel-archetypes.md -- Squeeze, Tripwire, VSL, Webinar, Application, Survey, Product Launch. Pick ONE primary archetype before naming pages.
• references/page-types.md -- Opt-in, thank-you, sales, OTO, upsell/downsell, order form, confirmation, bridge, content hub. Menu of pages to compose the funnel.
• references/value-ladder.md -- Free / low / mid / high / continuity rung logic (Brunson) for product ascension; the trust-service commitment-ladder variant for service businesses. Where does this funnel live on the ladder? What comes next?
• references/offer-stack.md -- Lead magnet, tripwire, core, order bump, upsell, downsell, OTO, continuity. Defines every offer slot and its job; L-level overlay; empty-by-design service slots.
• references/hook-story-offer.md -- Every offer carries a hook, story, and offer. Used to structure the sales-page and ad pre-frame.
• references/godfather-offer.md -- Suby's irresistible-offer structure. Applied to the core offer.
• references/traffic-temperature.md -- Cold, warm, hot. Dream 100. Pre-frame bridge. Constrains archetype choice and opt-in copy.
• references/conversion-benchmarks.md -- Realistic per-step conversion ranges so the economics model is not fantasy.

Workflow:

0. Bind to the brand architecture (read it first). Per Project Manifest Lookup step 2, read brand/<brand>/offer-architecture.md. Note its offer_ladder_kind, its canonical offer inventory (the stable offer_ids), its CTA cascade, and its journey mapping. This funnel's offer-stack.yaml binds to those stable IDs — it does not define offers afresh. If no architecture exists, offer to run Mode C (/offer-architecture) first, or produce a thin draft architecture so the funnel has stable IDs to bind to (references/offer-ladder-kinds.md + references/offer-level-model.md). Never bind to an invented local offer.
1. Requirement anchor -- use the Establish Requirement Anchor section above.
2. Confirm offer_ladder_kind (route early). Using references/offer-ladder-kinds.md, confirm whether this funnel is product-ascension, trust-service, or hybrid — matching the architecture. This choice routes the rest of the workflow: product-ascension uses price-multiple jump-gaps and may carry an impulse tripwire; trust-service uses the commitment_profile, leads with a free diagnostic L2, and leaves tripwire/order_bump/upsell empty-by-design. Do NOT manufacture a tripwire for a trust-service funnel.
3. Select method lenses only if they change the projection. Load references/offer-conversion-method-lenses.md and checklists/method-lens-checklist.md only when a selected lens changes funnel sequence, offer-stack binding, evidence requirements, CTA cascade, or downstream ownership. Carry forward method lenses already recorded in the brand architecture if they still matter here; otherwise record none.
4. Archetype selection -- Apply checklists/archetype-selection.md. Pick ONE primary archetype. Document why.
5. Value ladder / commitment ladder placement -- Using references/value-ladder.md (and the trust-service variant when applicable), locate this funnel on the ladder. What is the rung above and below? What is the ascension/commitment path?
6. Offer stack (bind to architecture) -- Fill every applicable slot in references/offer-stack.md. Each filled slot carries both craft fields (name, promise, price, role) AND binding fields (offer_id from the architecture, offer_level, stack_slot, offer_role, awareness_state, readiness_state, journey_stage, primary_cta_intent, next_offer_id, binding_status). An offer the funnel needs but the architecture lacks → binding_status: gap + gap_reason:; raise it as an offer gap in offer-architecture.md §9 (Mode C resolves it). For empty slots, document the reason (empty-by-design for trust-service is NOT a finding).
7. Core offer design -- Apply references/godfather-offer.md and references/hook-story-offer.md to the core offer.
8. Page sequence + per-surface CTA intent -- Using references/page-types.md, list every page in encounter order. Each page entry names: page type, purpose (one verb), single primary conversion event, on-Yes target, on-No target, AND the primary_cta_intent (which offer_id @ which offer_level the CTA targets, per references/cta-ladder.md). Never jump offer levels.
9. Traffic temperature matching -- Apply references/traffic-temperature.md to validate the pre-frame is correct for the chosen traffic.
10. Economics model -- Apply conservative numbers from references/conversion-benchmarks.md. Compute: leads per 1,000 visitors, buyers per 1,000 visitors, AOV, revenue per visitor, break-even CPM/CPC, margin at break-even. (Trust-service: the north star is L1→L2→L3 throughput, not AOV — see references/offer-ladder-kinds.md.)
11. Produce three artifacts -- funnel-spec.md, offer-stack.yaml, economics-model.md in funnel/<instance>/ at the project root.
12. Update the project manifest -- add or refresh the funnel/<instance> entry in MANIFEST.md at the project root: kind: spec, path: funnel/<instance>/, produced_by: funnel-strategist@<version>, new last_updated, manifest-entry status: translated per R61 from the artifact's own status: (draft|review → draft|review; greenlit → approved), upstream: [OFFER_ARCHITECTURE] (name the brand offer-architecture canonical explicitly — the funnel is a projection of it, so the dependency is real, not optional), consumed_by: [conversion/<instance>].

Output: Three template-conforming artifacts (binding to the brand architecture) plus the manifest entry, ready to hand off to conversion-designer.

Checklist: Follow checklists/design-checklist.md step-by-step.

Mode B: Funnel Review (/funnel-review)

Purpose: Review an existing funnel design before it gets built. Not for auditing a live site -- for that use conversion-designer /funnel-map.

Load these references:

• references/funnel-archetypes.md
• references/offer-stack.md
• references/conversion-benchmarks.md
• references/traffic-temperature.md
• references/offer-conversion-method-lenses.md + checklists/method-lens-checklist.md when the artifact names method lenses or imports a framework claim

Workflow:

1. Requirement anchor -- use the Establish Requirement Anchor section. If the anchor is not in the design, that is Finding #1.
2. Archetype coherence -- Apply checklists/archetype-selection.md. Does the chosen archetype match the traffic temperature and the price point?
3. Method-lens discipline -- If the design names a framework or method lens, verify it materially changed sequence, offer binding, evidence requirements, or downstream routing. Flag framework theater, imported source language, numeric framework scoring, or dark-pattern drift.
4. Offer stack audit -- Apply checklists/offer-stack-audit.md. Are the rungs logical? Are any slots empty that should be filled? Are any offers duplicated?
5. Economics plausibility -- Apply checklists/economics-readiness.md. Do the assumed conversion rates fall within the benchmark ranges? Is break-even achievable?
6. Page sequence coherence -- Is every page in the sequence necessary? Is any transition missing (e.g., thank-you to sales page with no bridge)? Is the single-primary-conversion-event rule held per page?

Output: Review report with severity-ranked findings.

Mode C: Offer Architecture (/offer-architecture)

Purpose: Design (or extend) the brand-scope offer/CTA/journey brain — the offer-architecture.md canonical that every one of this brand's funnels, campaigns, and content pieces binds to. This is the brain that Mode A projects from. One per brand; brand scope, not instance scope.

Produces: brand/<brand>/offer-architecture.md (R15 brand-canonical zone), declared in MANIFEST.md canonicals: as OFFER_ARCHITECTURE. Template: templates/offer-architecture.md.

Load these references:

• references/offer-level-model.md -- L1/L2/L3 as a commitment layer OVER the canonical seven slots (never a replacement); the "free diagnostic is L2-by-commitment yet lead_magnet-by-economics" insight; stable offer_id conventions + lifecycle (retire/supersede, never silent-rename).
• references/offer-ladder-kinds.md -- the keystone discriminator product-ascension | trust-service | hybrid; the commitment_profile dimensions; per-kind jump-gap logic. Choosing the ladder kind is the first act of this mode.
• references/cta-ladder.md -- the CTA cascade governance: which offer level each surface targets, allowed/forbidden jumps by awareness/readiness, high-trust/negative-intent adaptations, the lane boundary vs conversion-designer, the offer-gap mechanism.
• references/journey-awareness-mapping.md -- the generic Schwartz awareness_state + generic readiness_state backbone, and the R44-clean journey_stage overlay resolved from brand/<brand>/BRAND.md at runtime (NO universal journey enum ships here).
• references/offer-stack.md -- the seven canonical slots this layer groups; the L-level overlay; empty-by-design service slots.
• references/value-ladder.md -- the price-tier (Wertreppe) view for product ascension and the commitment-ladder variant for trust-service.
• references/offer-conversion-method-lenses.md -- selected only when a method lens changes architecture, evidence, route, or misuse handling.
• Fact source: brand/<brand>/OFFER.md (brand-dna). This artifact may CLASSIFY / SEQUENCE / BIND offers; it must NOT invent claims, guarantees, prices, or deliverables absent from OFFER.md or explicit user source.

Workflow: (mirrors templates/offer-architecture.md section order)

0. Manifest-first + read OFFER.md. Per Project Manifest Lookup, read MANIFEST.md; locate and read brand/<brand>/OFFER.md (offer facts) and brand/<brand>/BRAND.md (journey_stages overlay, if declared). If an offer-architecture.md already exists, this is an extension/revision — read it and preserve stable IDs.

   If brand/<brand>/OFFER.md is ABSENT: the architecture cannot be built on invented facts (the brain classifies/sequences/binds offer FACTS — it never invents claims, prices, guarantees, or deliverables). STOP and choose one of two routes, surfacing the choice to the user:

   • Preferred: route to /brand-dna to produce brand/<brand>/OFFER.md first, then resume Mode C. (OFFER.md is brand-dna's artifact — offer facts are brand-dna's responsibility; offer architecture is funnel-strategist's.)
   • Only if the user explicitly wants to proceed without it: produce a clearly-marked skeleton offer-architecture.md whose every fact-dependent field (claims, prices, guarantees, deliverables, offer names) is flagged as a FACT GAP — supply from OFFER.md placeholder, with an assumption-log entry per gap (§9). NEVER invent a fact to fill a gap. The skeleton is not bindable downstream until the gaps are resolved from a real OFFER.md or explicit, cited user source. Mark status: draft and note the skeleton state prominently.

1. Requirement anchor (brand scope). Mirror Establish Requirement Anchor at brand scope: dream buyer, core transformation, primary business goal, typical traffic, the primary monetization event, the primary FIRST conversion (may differ from the monetization event), and the constraints/boundaries that bind the offers.

2. Select method lenses only when needed. If the architecture uncertainty is category positioning, message-market-media coherence, pipeline qualification, diagnostic trust bridge, CRO friction, narrative clarity, shareability, or retention ethics, load references/offer-conversion-method-lenses.md and checklists/method-lens-checklist.md. Select zero to three lenses and record why each changed the architecture. If none materially changes the work, record none.

3. Choose offer_ladder_kind (route everything). Using references/offer-ladder-kinds.md, decide product-ascension | trust-service | hybrid. This is the most consequential decision — it routes L2 defaults, the L3 event, jump-gap logic, CTA tone, and measurement. For hybrid, name the branch point explicitly.

4. Define the offer level model for this brand. What does L1/L2/L3 mean here, shaped by the ladder kind. Name post-L3 explicitly (product: order-bump→upsell→continuity; service: onboarding→aftercare→retention).

5. Build the canonical offer inventory. One stable offer_id row per offer (kebab, brand-prefixed, descriptive of the offer not its level/slot). Record both offer_level AND stack_slot for every offer (the level↔slot reconciliation). Treat IDs like database keys: never silently renamed.

6. Reconcile L1/L2/L3 ↔ the seven slots. Record empty-by-design slots with reasons for trust-service ladders.

7. Define the CTA ladder (cascade governance). Per-surface primary_cta_intent (which offer_id @ which offer_level), allowed/forbidden jumps by awareness/readiness, per-kind CTA tone, high-trust adaptations. Strategic intent ONLY — never component/copy/placement (that is conversion-designer's lane). Apply the name-collision guard (commitment ladder ≠ CTA ladder).

8. Map journey / awareness. Record awareness_state + readiness_state (generic backbone, always present) + journey_stage (per-brand overlay from BRAND.md, or none). No universal J-enum (R44).

9. Emit measurement requirements (per-artifact emission against measurement-contract@1). State the signals downstream surfaces MUST make observable at journey/campaign/asset levels (per R55). This is the funnel-strategist's per-artifact measurement emission conforming to measurement-contract@1 (child copy at references/measurement-contract.md). Honest caveats hold: it emits REQUIREMENTS (what must be observable), NOT analytics — aggregation belongs to the future measurement-analyst. Keep the required-vs-actual distinction.

10. Record offer gaps + assumptions. A needed-but-missing offer is an offer gap resolved here, never invented locally downstream. Keep assumptions distinct from OFFER.md facts.

11. Write + index. Write brand/<brand>/offer-architecture.md. Ensure MANIFEST.md canonicals: declares OFFER_ARCHITECTURE (add it if absent). The brand canonical is per-brand and lives in the brand zone, NOT in a funnel/<instance>/ zone.

Checklist: Follow checklists/offer-architecture-design.md step-by-step.

Output: brand/<brand>/offer-architecture.md, conforming to templates/offer-architecture.md, declared as the OFFER_ARCHITECTURE canonical. Consumed by Mode A and by campaigns/content.

Mode D: Offer Architecture Review (/offer-architecture-review)

Purpose: Audit an existing brand-scope offer-architecture.md before downstream funnels, campaigns, and content bind to it. Brand scope. Not for auditing a live site.

Load these references: the same set as Mode C (offer-level-model.md, offer-ladder-kinds.md, cta-ladder.md, journey-awareness-mapping.md, offer-stack.md, value-ladder.md), read against brand/<brand>/offer-architecture.md and its OFFER.md fact source. Also load references/offer-conversion-method-lenses.md + checklists/method-lens-checklist.md if the architecture names method lenses, imported frameworks, scorecards, persuasion principles, or retention mechanics.

Workflow (AI judgment over rubrics — no scoring, no PASS/FAIL gate, R32):

1. Stable-ID integrity. Are offer_ids stable, brand-prefixed, descriptive of the offer (not its level/slot)? Any silent renames (a finding)? Retire/supersede recorded explicitly?
2. Level / slot coherence. Does every offer record BOTH offer_level and stack_slot? Is any offer assigned an eighth (invented) slot? Is a diagnostic correctly recorded as lead_magnet slot @ L2 role, not a new slot?
3. Ladder-kind fit. Does the architecture's offer_ladder_kind actually match the business? Trust-service mishandled as product-ascension (manufactured tripwire, forced consultation) is a structural finding. Hybrid branch point named?
4. Method-lens discipline. If the architecture names method lenses, do they target a specific uncertainty and produce a visible architecture/evidence/routing change? Flag framework theater, source-text import, numeric readiness scoring, manipulative scarcity, or habit-loop misuse.
5. CTA cascade / jump-gap review. Does any surface's primary CTA jump offer levels for a not-yet-ready visitor (fails the Cascade Test)? On trust-service: is the promised orientation gated behind a form? Any fear/urgency/scarcity on a sensitive decision? L3 forced rather than "available, never forced"?
6. R44 overlay compliance. Is the journey backbone the generic awareness_state + readiness_state, with journey_stage resolved from BRAND.md (or none)? Any hardcoded universal J-enum baked in (an R44 violation finding)?
7. Campaign-binding readiness. Can a campaign bind to stable offer_ids? Are offer gaps recorded (not silently invented)?
8. Measurement completeness. Are journey/campaign/asset signals stated as requirements (per-artifact emission against measurement-contract@1), with the first-conversion-vs-monetization-event split named where they differ?
9. Boundary compliance. Does the architecture classify/sequence/bind offers WITHOUT inventing claims/prices/guarantees absent from OFFER.md? Does it stay in the cascade-governance lane (no CTA component/copy/placement)?

Checklist: Follow checklists/offer-architecture-review.md step-by-step.

Output: Review report with severity-ranked findings (V0–V3 per the scale below). Cite named tests (Cascade Test, Commitment-Gap Test) where they apply.

---

Commands

Command	Checklist	Mode	Scope	Description
/offer-architecture	checklists/offer-architecture-design.md	C — Design	Brand	Design/extend the brand-scope offer/CTA/journey brain (offer-architecture.md) all funnels & campaigns bind to
/offer-architecture-review	checklists/offer-architecture-review.md	D — Review	Brand	Audit an existing brand-scope offer-architecture.md before downstream binding
/funnel-design	checklists/design-checklist.md	A — Design	Instance	Design a new funnel end-to-end (a projection of the brand architecture)
/funnel-review	checklists/offer-stack-audit.md + checklists/economics-readiness.md	B — Review	Instance	Review an existing funnel design (pre-build)
/archetype	checklists/archetype-selection.md	A — Design	Instance	Pick the right funnel archetype for a given context
/offer-stack	checklists/offer-stack-audit.md	A/B	Instance	Design or audit the offer-stack independent of page sequence

Note: for auditing a LIVE funnel with real analytics, use conversion-designer /funnel-map. This skill is explicitly pre-build.

---

Output Constraint: Evidence-Attached Decisions

Every archetype choice, offer slot fill, and conversion-rate assumption MUST include:

• What: The specific choice (archetype name, offer slot, conversion rate)
• Why: The reason, tied to the requirement anchor, the traffic temperature, or a named framework (Brunson ladder, Suby Godfather criteria, Hormozi value equation)
• Source: The reference doc or book the reasoning comes from
• Alternative considered: Which other option was weighed and why it lost

Decisions without all four fields are guesses. A funnel built on guesses is a funnel that cannot be iterated on, because nobody knows why any piece is there.

Example

• What: Tripwire archetype with a €9 front-end offer, €97 core offer, €297 upsell
• Why: Traffic is cold paid (Meta/Instagram) at €0.50-1.20 CPC; audience is emotional/impulse-receptive (acute relationship crisis); a low-friction first purchase is needed to recoup ad spend fast and identify real buyers from tire-kickers
• Source: Brunson DotCom Secrets Ch. 4 (Value Ladder tripwire rung), Hormozi $100M Offers value-equation pricing, references/conversion-benchmarks.md cold-paid-to-tripwire row
• Alternative considered: Squeeze funnel (opt-in only, monetise via email) -- rejected because the user's goal is revenue within 30 days, not list building. Squeeze is revisited in Mode B if budget shrinks.

---

Diagnostic Lenses

Apply these named tests during design and review. Each has a near-binary answer. Name the test explicitly in your findings.

1. The Ladder Test: "Can the visitor ascend from any rung to the next?" If a rung is missing or the jump is too steep (lead-magnet to €2,000 coaching), the ladder is broken. Funnels with broken ladders leak hardest between rungs.

2. The Temperature Test: "Does the first page match the temperature of the traffic?" Cold traffic requires an indirect pre-frame (curiosity, self-assessment, story). Warm traffic tolerates a more direct offer. Hot traffic converts on a direct CTA. Mismatches produce expensive, low-conversion spend.

3. The Single-Conversion Test: "Does every page have ONE primary conversion event?" A page that asks for both an email AND a purchase competes with itself. Split into two pages.

4. The Bridge Test: "Is every transition explicit?" Thank-you page with no bridge to the sales page = 90% drop-off from something that should flow. Each transition needs a bridge (copy, video, redirect, button).

5. The Break-Even Test: "At benchmark conversion rates, does CAC < LTV?" If no, the funnel is unprofitable at scale. Redesign the offer stack or cut a rung before building.

6. The Godfather Test: "Is the core offer so good refusal feels stupid?" Use Suby's criteria: high-value outcome, stacked bonuses, risk reversal, scarcity that is real. If refusal is easy, the sales page will struggle regardless of copy.

7. The Ascension Test: "What happens after the core offer?" If there is no upsell, no order bump, no continuity path, the funnel caps its own revenue. This is acceptable for list-building-only funnels. It is a V3 finding for revenue funnels.

When citing a lens in a finding, use the format: "Fails the [Name] Test -- [specific evidence of failure]."

---

Severity Scale

Use the same severity scale as conversion-designer:

Level	Name	Criterion	Action
V0	Cosmetic	Unnecessary but harmless	Note and move on
V1	Local	Has a cost but stays contained to one element	Flag for fixing
V2	Structural	Shapes the funnel architecture around itself	Flag for redesign
V3	Contagious	Forces OTHER pages, offers, or economics to be worse	Flag as urgent

A missing tripwire offer is V1 (can be added later). A broken value ladder is V3 -- it warps every page below and above the break.

---

Scale Anchoring

• Cold-paid opt-in: 10-25% on a strong hook. Below 5% = hook or targeting is wrong. Above 40% on cold paid is rare and often masks a lead-quality problem.
• Opt-in to tripwire purchase: 1-5% of opt-ins on the thank-you/sales page. Cold traffic rarely beats 3%.
• Tripwire to core offer: 15-35% of tripwire buyers (warm, committed audience).
• Core offer to upsell: 20-40% of core-offer buyers accept at least one upsell.
• Application-funnel show rate to consultation: 40-70% (depends on the scheduling friction).
• Webinar registration to attendance: 30-50% live, 50-70% replay.
• Webinar attendance to purchase: 5-15% on a well-structured pitch.

See references/conversion-benchmarks.md for the full table.

---

Locale Awareness

Before producing any funnel artifact with user-facing copy (even skeleton copy), load the appropriate profile from profiles/{languageCode}.json.

• de (German): Sachlichkeit. Scarcity only if real. Price transparency is expected. Term hygiene: "Lead-Magnet" (hyphen), "Wertreppe" alongside "Value Ladder", "Einstiegs-Offer" for tripwire.
• en (English): Standard direct-response conventions. More latitude for urgency and scarcity language if verifiable.
• nl (Dutch): Direct and practical. Scarcity must be genuine and modest. Social proof works best as peer proof and concrete outcomes. Use straightforward offer language without stiff corporate phrasing.

If locale is ambiguous, STOP at the requirement anchor and ask.

(See also: the Language Handling section below for runtime output-language policy — Unicode preservation, frontmatter conventions, when skeleton copy follows the end-customer locale vs. the conversation language. Locale Awareness is about persuasion norms per locale; Language Handling is about which language the output is written in.)

---

Reference Loading Instructions

If the user asks what books, methods, or source traditions informed a funnel, offer-architecture, CTA-cascade, or economics recommendation, read references/source-lineage.md and summarize only the sources that affected the current output. Do not present source lineage as proof by authority; tie it back to the requirement anchor and project evidence.

For Offer-Architecture Modes (C / D — brand scope)

Step	Reference File	What to Extract
Choose ladder kind (FIRST)	references/offer-ladder-kinds.md	product-ascension | trust-service | hybrid discriminator; the commitment_profile dimensions; per-kind jump-gap logic, L2 default, L3 event, CTA tone; iurFriend/Accent as falsifiers (NOT defaults)
Offer levels over slots	references/offer-level-model.md	L1/L2/L3 as a commitment layer OVER the seven slots; the "free diagnostic = L2-by-commitment yet lead_magnet-by-economics" insight; stable offer_id conventions + retire/supersede lifecycle
CTA cascade governance	references/cta-ladder.md	Which offer level each surface targets; allowed/forbidden jumps by awareness/readiness; high-trust/negative-intent adaptations; the conversion-designer lane boundary + the commitment-ladder name-collision guard; the offer-gap mechanism
Journey / awareness mapping	references/journey-awareness-mapping.md	Generic Schwartz awareness_state + generic readiness_state backbone; the R44-clean journey_stage overlay resolved from BRAND.md at runtime; the anti-rule (no universal J-enum)
Optional method-lens selection	references/offer-conversion-method-lenses.md + checklists/method-lens-checklist.md	Blue Ocean / One-Page Marketing / Predictable Revenue / Scorecard-CRO / StoryBrand / SUCCESs / Contagious / retention lenses only when they materially alter architecture, evidence, route, or misuse handling

For Funnel Design Mode (A — instance scope)

Step	Reference File	What to Extract
Bind to architecture (FIRST)	brand/<brand>/offer-architecture.md	The brand's offer_ladder_kind, stable offer_id inventory, CTA cascade, journey map — the funnel binds to these
Confirm ladder kind	references/offer-ladder-kinds.md	Match the funnel to the architecture's kind; route doctrine (price-multiples vs commitment_profile)
Offer levels + binding	references/offer-level-model.md	L1/L2/L3 over the seven slots; the binding fields the funnel records per offer
Per-surface CTA intent	references/cta-ladder.md	The primary_cta_intent each page records; never jump offer levels; the offer-gap mechanism
Archetype selection	references/funnel-archetypes.md	Seven archetypes with fit criteria
Page sequencing	references/page-types.md	Page-type taxonomy and purpose per type
Ladder placement	references/value-ladder.md	Product-ascension rung logic + pricing tiers; the trust-service commitment-ladder variant + commitment-gap doctrine
Offer design	references/offer-stack.md	Offer-slot menu + role of each; L-level overlay; empty-by-design service slots
Core offer copy framework	references/hook-story-offer.md	Hook / Story / Offer structure for each offer
Core offer irresistibility	references/godfather-offer.md	Suby criteria, bonus stacking, risk reversal
Traffic-offer matching	references/traffic-temperature.md	Cold/warm/hot pre-frame rules, Dream 100
Economics modelling	references/conversion-benchmarks.md	Per-step conversion ranges
Tool translation	references/geru-simulation.md	How to translate the output into Geru by hand
Optional method-lens selection	references/offer-conversion-method-lenses.md + checklists/method-lens-checklist.md	Selected lenses carried from architecture or chosen when the funnel sequence needs a specific method lens

For Review Modes (B / D)

Mode B: same funnel-design reference files, plus the three funnel-review checklists. Mode D: the same offer-architecture reference set (C/D table above), read against the existing offer-architecture.md and its OFFER.md fact source.

Book Digests (load on demand)

Digest	When to Load
references/book-digests/dotcom-secrets.md	When archetype or ladder decisions need deeper grounding
references/book-digests/traffic-secrets.md	When traffic strategy or Dream 100 matters
references/book-digests/expert-secrets.md	When the story-selling / attractive character dimension is relevant
references/book-digests/sell-like-crazy.md	When the Godfather Offer or HALO sequencing matters

---

Output Format

Brand scope (Mode C) — one canonical per brand

brand/<brand>/offer-architecture.md — the offer/CTA/journey brain. Follows templates/offer-architecture.md. Lives in the R15 brand-canonical zone (orthogonal to the four workspace zones), declared in MANIFEST.md canonicals: as OFFER_ARCHITECTURE.

Instance scope (Mode A) — three artifacts per funnel

When in funnel-design mode, produce three files in funnel/<instance>/ at the project root:

1. funnel-spec.md -- Narrative funnel description with page sequence, offer placements, per-surface CTA intent, and a text diagram. Follows templates/funnel-spec.md.
2. offer-stack.yaml -- Structured inventory of every offer in the stack (YAML), each binding to a stable brand offer_id. Follows templates/offer-stack.yaml.
3. economics-model.md -- Inputs, assumed conversion rates, and derived revenue/CAC/LTV numbers. Follows templates/economics-model.md.

Plus: add / refresh the funnel/<instance> entry in MANIFEST.md at the project root.

Handoff contract

conversion-designer opens MANIFEST.md at the project root, finds the funnel/<instance> entry, reads the three artifacts at the entry's path: (funnel/<instance>/), and — for the CTA cascade — resolves each offer's primary_cta_intent back to the brand offer-architecture.md declared in MANIFEST.md canonicals:. If conversion-designer asks clarifying questions after reading them, the artifacts are incomplete -- patch them and bump last_updated.

Cross-plugin contract: project-workspace-contract@2 (see ${CLAUDE_SKILL_DIR}/references/project-workspace-contract-v2.md). Per-skill contract: see this skill's MANIFEST.yaml.

---

End-of-run (R26 — conditional)

Standard runs (project MANIFEST.md looked up, requirement anchor established, archetype selected, value ladder placed, offer stack filled and bound to the brand architecture, page sequence built, economics modeled, three artifacts produced, manifest entry refreshed — or, for Mode C, the brand offer-architecture.md produced and declared as the OFFER_ARCHITECTURE canonical) end normally — no self-improvement prompt fires.

The prompt fires only on funnel-strategist-specific deviation. Triggers and prompt shapes:

• Value ladder shape didn't fit the brand's offering (e.g., service-based business with no natural product rungs, B2B with one-and-done deals, or recurring-only with no front-end) → "The value ladder in references/value-ladder.md assumes <assumption>, but <brand>'s offering is <shape> — I improvised <workaround>. Should references/value-ladder.md document this offering-shape variant, or is this a one-off?"
• Offer stack slot missing from defaults (user needed a slot like "diagnostic-call upsell" or "cohort-window order bump" that references/offer-stack.md doesn't enumerate) → "You needed <slot-name> which isn't in references/offer-stack.md's default offer-slot menu. Should the offer-stack reference be extended to include it, or is this slot brand-specific enough to keep in the project's overlay?"
• Economics-model assumption overridden (user said "our actual margins are X, not your benchmark Y" or "our LTV input is wrong because we have 70% retention") → "You overrode <assumption> from references/conversion-benchmarks.md because <reason>. Should the benchmark doc surface a calibration note for <industry / vertical>, or is your override too brand-specific to generalize?"
• Brunson/Suby/Halbert/Hormozi pattern conflict (the brand's funnel hybridizes patterns in a way that doesn't map cleanly — e.g., webinar archetype with Hormozi's $100M Offers core but Brunson's perfect-webinar-script transitions) → "Your funnel hybridizes <pattern-A> and <pattern-B>. Should references/funnel-archetypes.md add a hybrid archetype (proposed: <name>), or document the hybridization rule as a meta-pattern?"
• User had an existing funnel structure to honor (incoming funnel was already built; user wanted analysis/refinement, not a clean-sheet design) → "You came in with an existing funnel at <path> and wanted me to refine, not redesign from scratch. The current Mode A workflow assumes clean-sheet. Should there be a new /funnel-refactor mode that starts from an existing funnel-spec, or did Mode B (/funnel-review) cover this adequately?"
• Offer architecture absent or thin when a funnel needed it (Mode A had no brand offer-architecture.md to bind to, or the architecture lacked an offer the funnel needed) → "This funnel needed <offer/level> which the brand offer-architecture.md does not define (recorded as binding_status: gap). Should we run /offer-architecture (Mode C) to resolve the gap properly, or is this offer instance-specific enough that a future revision should generalize it into the architecture?"
• Locale-specific funnel norm conflicted with archetype (e.g., German Sachlichkeit ruled out the Tripwire archetype's price-anchoring drama; Dutch AVG ruled out aggressive scarcity in webinar registration) → "Your locale (<locale>) ruled out <archetype>'s standard <pattern>. Should profiles/<locale>.json enumerate which archetype patterns are off-limits per locale, or did the locale profile cover this?"
• Geru/Funnelytics translation surfaced a gap (the simulation tool needed an input dimension the economics model didn't produce) → "When translating to <sim-tool>, I needed <missing-dimension> which templates/economics-model.md doesn't capture. Should the economics-model template be extended to include it for clean simulation handoff?"

If a trigger fires, surface the specific deviation in context-specific prose (not generic "any feedback?"). If the user confirms, update SKILL.md (or the relevant reference / template / profile) inline before going idle. If the user declines, do not write an AI-authored suggestion into project notes/; surface it in the closing summary and let the orchestrator file a Bead or a project-appropriate learning-log entry when the user wants it preserved.

Standard runs end at the handoff — for Mode A, the three-artifact handoff (funnel-spec.md + offer-stack.yaml + economics-model.md written, bound to the brand architecture; manifest entry refreshed; ready for conversion-designer); for Mode C, the brand offer-architecture.md written and declared as the OFFER_ARCHITECTURE canonical (ready for funnels, campaigns, and content to bind to). No prompt fires for uneventful runs.

Language Handling

• Detect the conversation language; respond in the user's language unless explicitly asked otherwise.
• If MANIFEST.md declares an output_language: field (project-workspace-contract@2 frontmatter), honor that declaration over inferred conversation language. Funnel-spec narrative, offer-stack entries, offer-architecture prose, and economics-model prose follow output_language:.
• Load profiles/{languageCode}.json to constrain persuasion and price-presentation norms per locale (German Sachlichkeit + price transparency, English direct-response latitude). Locale profile drives what is sayable; output_language: drives what language it's said in.
• Preserve funnel-strategist domain terms in their canonical form: prefer Wertreppe alongside Value Ladder for German contexts, Lead-Magnet (hyphen) for German, Einstiegs-Offer for German tripwire. Keep English terms (upsell, downsell, order bump, OTO) when no clean local equivalent exists — domain practitioners read English direct-response literature.
• Preserve legal, financial, and technical terms in their original language (Trennungsjahr, MwSt, BTW, Aufhebungsvertrag, etc.).
• Preserve Unicode characters natively (ü, ö, ä, ß, etc.); never substitute transliterations (ue, oe, ae, ss).
• Skeleton page copy and offer names in the funnel-spec follow the end-customer's locale, not the conversation language. If designing a Dutch funnel in an English conversation, page names and offer names are Dutch.
• Frontmatter field names and enum values stay English regardless of content language (status: draft, kind: spec, produced_by: [email protected]). Free-text frontmatter values (titles, descriptions) may follow content language where natural.

(See also: the Locale Awareness section above for persuasion norms per locale — Sachlichkeit, price-transparency expectations, scarcity-language constraints, German term hygiene (Wertreppe, Lead-Magnet, Einstiegs-Offer). Language Handling is about which language Claude responds in; Locale Awareness is about what is sayable in that language for this brand's market.)

What This Skill Does NOT Do

• Does not write page copy. Final copywriting is downstream of this skill. The skill specifies the HOOK/STORY/OFFER structure per page but not the actual paragraphs.
• Owns CTA cascade GOVERNANCE, not CTA CRAFT. This is the load-bearing lane boundary (full detail in references/cta-ladder.md). funnel-strategist decides which offer level each surface's CTA targets — the destination logic, the allowed/forbidden jumps between offer levels, the per-surface primary_cta_intent, the next-step cascade, the offer-gap mechanism. conversion-designer owns CTA craft — the actual component, the button copy, the placement on the page, the visual treatment, the A/B variants, and the components-manifest.json. funnel-strategist never specifies a hex colour, a final button label, or a placement coordinate; conversion-designer never re-points a CTA at a different offer level.
• "Commitment ladder" (conversion-designer) ≠ "CTA ladder" (here). Name-collision guard: conversion-designer's commitment ladder is Cialdini-style micro-commitments WITHIN a single page (small yeses that build toward the page's one ask — page-internal craft). This skill's CTA ladder is about never jumping OFFER LEVELS across a brand's assets (a brand-scope cascade). Same word "ladder", entirely different scope. Say "CTA ladder (offer-level cascade)" when confusion is possible.
• offer-architecture.md classifies / sequences / binds offers — it does NOT invent them. The brain may organize, level, sequence, and bind offers into a stable architecture, but it must NOT invent claims, guarantees, prices, or deliverables absent from brand/<brand>/OFFER.md (brand-dna) or explicit user source. Offer FACTS are brand-dna's; offer ARCHITECTURE is funnel-strategist's.
• Does not design conversion components. CTAs as components, scorecards, trust bars, social proof blocks are conversion-designer's domain (funnel-strategist declares the diagnostic/scorecard's offer-level INTENT; conversion-designer builds the component).
• Does not choose visual design. Visual styling is owned by site-designer.
• Does not pick traffic channels in detail. Archetype choice narrows the viable channels, but channel strategy (Dream 100 execution, platform choice, ad creative) and campaign-to-offer binding execution belong to the future campaign-strategist skill (which binds to this skill's stable offer_ids).
• Does not aggregate analytics or run experiments. It EMITS measurement requirements (what must be observable, per R55) at journey/campaign/asset levels; it does not collect, aggregate, or interpret analytics (future measurement-analyst) and does not own optimisation experiments (future optimisation-strategist).
• Does not run simulations itself. The economics model is shaped so a simulation tool (Geru, Funnelytics, a spreadsheet) can ingest it. The skill produces the specification, not the simulation output.
• Does not audit live sites. Use conversion-designer /funnel-map for that. This skill is pre-build.