conversion-designer

Conversion Designer

Diagnose conversion problems. Design conversion solutions. Produce page strategy packs and implementation-ready manifests.

This skill operates as an orchestrator. Domain knowledge lives in reference files, not here. This file defines the workflow, routing, and constraints.

This skill operates per project-workspace-contract@2 (${CLAUDE_SKILL_DIR}/references/project-workspace-contract-v2.md). Outputs (components-manifest.json, page-strategy-pack.md, page-content-model.yaml, audit-report.md) land in the Kind-3 zone conversion/<instance>/ at the project root and are indexed in MANIFEST.md at the project root. Upstream from funnel-strategist's funnel/<instance>/ entries is optional — conversion-designer also runs standalone (single-page work without a multi-page funnel context). Under v2, workspace/ is opaque AI scratch and is never read for routing.

---

Phase 0a: 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. Parse the entries: YAML block for the routing index. Note any existing entries under funnel/ and conversion/.
   • No: the project has not yet adopted the v2 contract. Per R67, /init-project is retired; project-surface setup is an orchestrator/native or project-local bootstrap routine. Return incomplete to the orchestrator with a clear request to initialize the project surface and root MANIFEST.md, then proceed only after MANIFEST.md exists. The v2 contract MUST be followed for this skill's outputs — there is no out-of-contract fallback.
2. Is there already a conversion/<instance> entry?
   • Yes with manifest-entry status: draft or review: continue the existing work (re-read existing artifacts to populate Phase 0b anchor; user may want to refine).
   • Yes with status: approved: confirm with the user whether they want to supersede (old entry marked superseded) or create a second instance (e.g. conversion/landing-v2 alongside an existing conversion/landing-v1).
   • 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-page.
3. Is there an upstream funnel/<instance> entry from funnel-strategist?
   • Single matching entry with manifest-entry status: draft | review | approved: pre-populate Phase 0b anchor inputs from the funnel artifacts listed in the entry (funnel-spec.md, offer-stack.yaml, economics-model.md). For draft or review entries, confirm with the user that the funnel is downstream-ready before consuming. Note funnel/<instance> last_updated for the staleness check below.
     • Respect the funnel's offer_ladder_kind. The upstream offer-stack.yaml carries an offer_ladder_kind (product-ascension | trust-service | hybrid) plus stable offer_id bindings projected from the brand's offer-architecture. Honor it: a trust-service funnel gets calm, orienting CTA craft (free diagnostic, low-commitment first step) — NOT aggressive product-ascension urgency or manufactured scarcity. You MAY read the brand canonical brand/<brand>/offer-architecture.md (declared as OFFER_ARCHITECTURE in the manifest canonicals:) to understand the CTA-cascade intent the funnel projects, so per-surface CTA copy targets the same offer level the architecture intends.
   • Multiple funnel entries (e.g., funnel/scheidung + funnel/beziehungskrise): ask the user which funnel this conversion run belongs to. Ignore superseded entries.
   • Mismatched or absent: conversion-designer's consumes: is optional (per the skill's MANIFEST.yaml). Proceed standalone — Phase 0b anchor inputs come directly from the user.
4. Staleness check (if both funnel and conversion entries exist):
   • Compare upstream funnel/<instance> last_updated vs current conversion/<instance> last_updated.
   • If funnel is newer than conversion: surface to the user — "The funnel was updated after this conversion entry. Re-read the funnel artifacts and revise the conversion design, or confirm the conversion entry is still current."

Record the <instance> name chosen; it is referenced in every output path.

---

Phase 0b: Establish Requirement Anchor

Before beginning any conversion optimization work, establish the requirement anchor by asking:

1. What is this product/service? Who operates it, and what do they sell or offer?
2. Who is the target audience? (Not projected. Actual.) Who visits this site today? What do they need?
3. What is the current conversion rate? (Not projected. Actual. Not industry benchmark. Your actual rate.) If unknown, that is itself diagnostic -- you need analytics instrumentation before conversion optimization.
4. What is the primary conversion goal? (Form submit, phone call, booking, purchase, assessment completion?)
5. What objections do visitors have? What would make someone leave this page without converting?
6. What legal/compliance constraints apply? (GDPR, AVG, DSGVO, medical disclaimers, advertising law?)

Record the answers. Every subsequent finding, recommendation, and component design must trace back to these answers. If a recommendation cannot be justified by the requirement anchor, it does not belong in the output.

If the user cannot answer questions 1-4, that is itself diagnostic -- they need analytics instrumentation and audience research before conversion optimization can help them.

"Not Projected. Actual." Constraint

When asking about scale, traffic, conversion rates, revenue, or any quantitative scope question, always append the constraint: "(Not projected. Actual.)"

Accept only current, measured values. If the user provides projections, aspirational targets, or industry benchmarks instead of actual numbers, flag this explicitly: "I need the actual current number, not a projection. If you don't have it, that is useful information -- it means we need to instrument measurement before proceeding."

Never use projected numbers as the basis for conversion optimization decisions. Projected numbers justify monitoring; actual numbers justify building.

---

Method Lens Discipline

Use method lenses only when they materially change the page strategy, component choice, proof requirement, objection handling, or experiment handoff. Treat Scorecard Marketing, CRO, StoryBrand, Value Equation, Cialdini, SUCCESs, Contagious, and retention/habit material as prompts for judgment, not as authority.

• Select zero to three lenses. Do not load them just because they exist.
• Before applying a lens, read references/conversion-method-lenses.md and run checklists/method-lens-checklist.md.
• Record the selected lens, uncertainty it addressed, artifact change it caused, evidence still needed, misuse avoided, and downstream owner.
• Do not compute framework scores, weighted readiness, or automatic gates.
• Do not change offer level, value ladder, or funnel sequence here. Route offer architecture changes to funnel-strategist.
• If a lens suggests final copy, content production, analytics setup, A/B-test execution, or page implementation, write a handoff note instead of doing that work inside this skill.

---

Operating Modes

This skill has three operating modes. Determine the mode from the user's command or intent before loading reference files.

Mode A: Audit (/conversion-audit)

Purpose: Diagnose an existing page or funnel for conversion issues.

Load these references:

• references/objection-map.md -- Objection catalog with counter-argument patterns
• references/cialdini-principles.md -- Cialdini's 7 influence principles with application rules
• references/storybrand-wireframe.md -- StoryBrand page structure for comparison
• references/value-equation.md -- $100M Offers value equation diagnostic
• references/success-scoring.md -- SUCCESs copy diagnostic framework (Made to Stick)
• references/b-map-model.md -- B=MAP behavior diagnostic (Improve Retention)
• references/conversion-method-lenses.md -- optional method-lens selection when a named framework changes strategy, evidence, or routing

Workflow:

1. Requirement anchor -- Establish per Phase 0b above
2. Funnel leak analysis -- Map the current funnel. Identify drop-off points. Catalog visitor objections using references/objection-map.md
3. Method lens selection -- Select zero to three lenses only if they change the page/component strategy. Record uncertainty, change, missing evidence, misuse avoided, and downstream owner.
4. Persuasion audit -- Review the page against Cialdini's 7 principles using references/cialdini-principles.md. Identify missing/weak social proof, authority signals, commitment ladders, reciprocity triggers, and manipulation risks.
5. Value equation diagnostic -- Read the current offer through Dream Outcome, Perceived Likelihood, Time Delay, Effort using references/value-equation.md. Identify which dimension most needs improvement without changing funnel-level offer architecture.
6. Copy audit -- Review headlines, CTAs, and body copy against the SUCCESs framework using references/success-scoring.md. Identify curse-of-knowledge violations and concrete rewrite needs.
7. Behavior diagnostic -- For each conversion step: Is Motivation sufficient? Is Ability high enough (friction low enough)? Is the Prompt present and well-timed? Use references/b-map-model.md
8. Apply Diagnostic Lenses -- Run each lens (section below) against the page and cite failures explicitly
9. Produce findings -- Evidence-attached findings ordered by severity (V3 first), then by impact
10. Update the project manifest -- Add or refresh the conversion/<instance> entry in MANIFEST.md at the project root per the v2 contract entry shape (status: translated per R61 from the artifact's own status: — draft|review → draft|review; greenlit → approved):

conversion/<instance>:
  kind: spec
  path: conversion/<instance>/
  produced_by: [email protected]
  authored_by: ["claude", "<user>"]
  last_updated: <ISO-8601 timestamp>
  status: draft   # manifest-entry routing status; or review, per user intent — never approved without explicit user signal
  artifacts: [audit-report.md]
  upstream: [funnel/<instance>]   # if Phase 0a found one; else []
  consumed_by: []                  # no downstream manifest entry yet

Output: Structured audit report with evidence-attached findings, severity ratings, and prioritized recommendations, placed at conversion/<instance>/audit-report.md per project-workspace-contract@2.

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

Mode B: Create (/conversion-create, /scorecard, /cta-optimize)

Purpose: Design new conversion elements and produce a components-manifest.json.

Load these references:

• references/scorecard-design.md -- Scorecard Marketing assessment design methodology
• references/value-equation.md -- $100M Offers value equation and offer architecture
• references/hook-model.md -- Nir Eyal's Hook Model for habit loop design
• references/cialdini-principles.md -- Influence principles for CTA and commitment ladder design
• references/storybrand-wireframe.md -- StoryBrand page structure
• references/microinteraction-spec.md -- Microinteraction design (trigger-rules-feedback-loops)
• references/conversion-method-lenses.md -- optional method-lens selection when a named framework changes page/component strategy, evidence, or routing

Load these templates:

• templates/scorecard-template.md -- Scorecard component template with dimensions, questions, tiers
• templates/cta-template.md -- CTA component template for all four variants
• templates/trust-bar-template.md -- Trust bar component template
• templates/social-proof-template.md -- Social proof component template

Workflow:

1. Requirement anchor -- Establish per Phase 0b above
2. Assessment design (if scorecard) -- Define 5-8 scoring dimensions, write 10-15 questions with "aha moment" psychology, define threshold tiers and results page copy. Use references/scorecard-design.md
3. Method lens selection -- Select zero to three lenses only if they change component strategy, proof needs, privacy/ethics boundaries, or handoff routing.
4. Page wireframe -- Section-by-section structure using StoryBrand: hero with CTA, stakes, value, guide, plan, CTA repeat. Use references/storybrand-wireframe.md
5. Offer framing -- Dream outcome, obstacle list, solution bundle, bonus stack, guarantee design. Use references/value-equation.md without changing funnel-level offer architecture.
6. Commitment ladder -- Sequence micro-commitments from low-cost (quiz answer) to high-cost (consultation booking). Use references/cialdini-principles.md
7. Habit loop design (for recurring elements) -- Define trigger, action, variable reward, and investment only when the loop creates recurring user value. Reject anxiety loops, manipulative variable rewards, and sensitive-data capture before value is delivered.
8. Microinteraction specification -- Define trigger, rules, feedback, and loops for each interactive moment. Use references/microinteraction-spec.md
9. Produce components-manifest.json -- Conforming to conversion-component-contract@1 (full schema in ${CLAUDE_SKILL_DIR}/references/conversion-component-contract.md). Every component entry must include all required fields per the contract.
10. Update the project manifest -- Add or refresh the conversion/<instance> entry in MANIFEST.md at the project root per the v2 contract entry shape (status: translated per R61 from the artifact's own status: — draft|review → draft|review; greenlit → approved):

conversion/<instance>:
  kind: spec
  path: conversion/<instance>/
  produced_by: [email protected]
  authored_by: ["claude", "<user>"]
  last_updated: <ISO-8601 timestamp>
  status: draft   # manifest-entry routing status; or review, per user intent — never approved without explicit user signal
  artifacts: [components-manifest.json]   # add other artifacts only when produced (audit-report.md, page-strategy-pack.md, etc.)
  upstream: [funnel/<instance>]   # if Phase 0a found one; else []
  consumed_by: []                  # no downstream manifest entry yet (site-builder is the expected consumer but does not currently declare a manifest entry)

Output: A components-manifest.json file conforming to the conversion-component-contract, placed in conversion/<instance>/ per project-workspace-contract@2. If the project has not yet adopted the v2 contract (no MANIFEST.md at the project root), return incomplete per Phase 0a and request orchestrator/native or project-local bootstrap before writing conversion artifacts.

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

Mode C: Page Strategy (/page-strategy, /landing-page-strategy, /service-page-strategy)

Purpose: Plan a single evergreen landing, sales, service, or treatment page before implementation.

Use this when the user wants a build-ready page strategy for one topic or a set of similar service pages. The output is a strategy pack, not final frontend code and not a dated article pipeline.

Route away from this mode when:

• The user needs a multi-page funnel, value ladder, offer stack, webinar funnel, tripwire, upsell, or economics model. Use funnel-strategist.
• The user only needs a CTA, scorecard, trust bar, or social proof component. Use Mode B.
• The user needs full long-form drafting, editorial production, or multi-stage research/writing/review workflow. Use the project's content creation system if available.
• The user needs keyword research only. Use seo-strategist.

Load these references:

• references/page-archetypes.md -- single-page archetype selection
• references/service-page-strategy.md -- evergreen service-page structure
• references/copy-frameworks.md -- copy frameworks as authoring scaffolds
• references/objection-map.md -- visitor objections and counter-arguments
• references/cialdini-principles.md -- trust/proof/authority calibration
• references/storybrand-wireframe.md -- page flow comparison
• references/value-equation.md -- offer/value framing
• references/success-scoring.md -- copy quality diagnostic
• references/stepps-shareability.md -- STEPPS viral/shareability triggers (consult when section plan or CTA strategy needs shareable mechanics)
• references/conversion-method-lenses.md -- optional method-lens selection when a named framework changes section strategy, proof, CTA route, or handoff
• locale profile in profiles/{languageCode}.json

Load these templates:

• templates/page-strategy-pack.md
• templates/page-content-model.yaml

Workflow:

1. Requirement anchor -- Establish Phase 0b answers. If actual conversion data is missing, proceed only with the explicit caveat that the strategy is hypothesis-led.
2. Project profile lookup -- Read available project context: the project-root MANIFEST.md, product/profile docs, design docs, agent instructions, content config, and relevant strategy docs. Record the project constraints rather than inventing defaults.
3. Search intent handoff -- Use existing keyword/search-intent evidence if present. If absent, define the likely primary intent and mark it needs-seo-validation.
4. Archetype and copy framework -- Select one page archetype and one copy framework. Treat copy frameworks as authoring scaffolds, not frontend templates.
5. Method lens selection -- Select zero to three lenses only if they change page architecture, proof needs, CTA route, shareability mechanics, or experiment handoff. Record the selected lens table in the output.
6. Page architecture -- Build a section-by-section plan with objective, user question, proof need, CTA role, asset role, and implementation notes per section.
7. CTA, trust, and objection strategy -- Define primary and secondary CTA, objection coverage, proof sources, and trust requirements. Regulated domains must avoid unsourced claims, fake urgency, and guarantees.
8. Visual asset strategy -- Define hero visual role, emotional image needs, diagram/screenshot needs, proof visuals, CTA bridge visual, asset source preference, generated-image rules, and asset risks.
9. SEO, linking, and schema -- Define slug, meta title/description, H1, internal links, FAQ plan, and schema recommendations.
10. Produce artifacts -- Write page-strategy-pack.md and optional page-content-model.yaml. Only produce components-manifest.json if a specific CTA/trust/social-proof component should be built.
11. Validate -- Run checklists/page-strategy-checklist.md and report open assumptions, review needs, and implementation handoff.
12. Update the project manifest -- Add or refresh the conversion/<instance> entry in MANIFEST.md at the project root per the v2 contract entry shape (status: translated per R61 from the artifact's own status: — draft|review → draft|review; greenlit → approved):

    conversion/<instance>:
      kind: spec
      path: conversion/<instance>/
      produced_by: [email protected]
      authored_by: ["claude", "<user>"]
      last_updated: <ISO-8601 timestamp>
      status: draft   # manifest-entry routing status; or review, per user intent — never approved without explicit user signal
      artifacts:      # always include page-strategy-pack.md; conditionally include the others only when produced
        - page-strategy-pack.md
        # - page-content-model.yaml      # include only if step 9 produced it
        # - components-manifest.json     # include only if step 9 produced a component spec
      upstream: [funnel/<instance>]   # if Phase 0a found one; else []
      consumed_by: []                  # no downstream manifest entry yet
    

Output: A page strategy pack and optional structured content model placed in the Kind-3 zone conversion/<instance>/ at the project root per project-workspace-contract@2. If the consuming project has not yet adopted the v2 contract, return incomplete per Phase 0a and request orchestrator/native or project-local bootstrap before writing the page strategy pack.

Checklist: Follow checklists/page-strategy-checklist.md step-by-step.

---

Commands

Command	Checklist	Mode	Description
/conversion-audit	checklists/audit-checklist.md	Audit	Full conversion audit of an existing page or funnel
/conversion-create	checklists/create-checklist.md	Create	Design new conversion elements and produce manifest
/page-strategy	checklists/page-strategy-checklist.md	Page Strategy	Plan a single evergreen landing/service page
/landing-page-strategy	checklists/page-strategy-checklist.md	Page Strategy	Plan a single landing or sales page
/service-page-strategy	checklists/page-strategy-checklist.md	Page Strategy	Plan a single service/treatment/professional page
/scorecard	checklists/scorecard-checklist.md	Create	Design an interactive scorecard/assessment
/cta-optimize	checklists/cta-checklist.md	Create	Optimize or design CTA elements (direct, transitional, in-content, exit-intent)
/funnel-map	checklists/funnel-checklist.md	Audit	Map and diagnose a conversion funnel end-to-end
/objection-map	checklists/objection-checklist.md	Audit	Catalog visitor objections and design counter-arguments

---

Output Constraint: Evidence-Attached Findings

Every finding in the output MUST include all four fields:

• What: The specific pattern, issue, or element detected
• Where: The URL, page section, component, or line number where it occurs
• Why: How it fails a diagnostic test, violates a requirement anchor item, or causes measurable harm
• What Instead: The specific alternative, fix, or replacement with enough detail to implement

Findings missing any of these four fields are incomplete and must not appear in the output. A finding without a "Where" is a guess. A finding without a "What Instead" is a complaint, not a recommendation.

Example

• What: The CTA button uses generic copy ("Meer informatie") with no authority signaling
• Where: /contact/ page, primary CTA above the fold
• Why: Fails the Commitment Test -- "Meer informatie" is vague and does not tell the visitor what they commit to or what they receive
• What Instead: Replace with "Plan uw gratis kennismakingsgesprek" and add a trust line above: "Al meer dan 2.000 patienten geholpen"

---

Diagnostic Lenses

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

1. The Objection Test: "Can you name the top 3 visitor objections this page addresses?" If you cannot point to visible answers for the top 3 objections, the page is leaking conversions at the objection barrier. Check references/objection-map.md for the project's objection catalog.

2. The CTA Clarity Test: "Can you describe the next action in 5 words or less?" If the CTA is longer than 5 words, ambiguous, or uses jargon, the visitor does not know what they are committing to. Every page must have one clear, unambiguous primary CTA.

3. The Trust Test: "Would you give this page your credit card or personal details?" If the page lacks social proof, authority signals, or verifiable claims, the answer is no. Count the trust elements: ratings, certifications, testimonials, case counts, partner logos. If fewer than 3 are visible, the trust infrastructure is insufficient.

4. The Scroll Test: "Does conversion opportunity exist above AND below the fold?" If the only CTA is above the fold, visitors who scroll past it have no conversion path. If the only CTA is below the fold, visitors who decide early have no conversion path. Every page needs conversion touchpoints at multiple scroll depths.

5. The Exit Test: "What happens when a visitor is about to leave?" If nothing -- no exit-intent overlay, no sticky CTA, no transitional offer -- then every bounce is a total loss. The exit moment is the last chance to convert a hesitant visitor into at least a low-commitment lead.

6. The Mother Test: "Would your mother understand what to do next on this page?" If the next action is not obvious to a non-technical user within 5 seconds, the UX is failing. This tests for jargon, visual clutter, competing CTAs, and unclear value propositions.

7. The Commitment Test: "What is the smallest 'yes' we can ask for?" If the first CTA asks for a phone call, offer a form first. If the form asks for 10 fields, offer 3. If the only option is "buy now," offer a free assessment. The commitment ladder must start with a step small enough that saying "yes" feels effortless.

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

---

Severity Scale

Use this severity scale for all findings:

Level	Name	Criterion	Action
V0	Cosmetic	Unnecessary but harmless; no maintenance or downstream impact	Note and move on
V1	Local	Has a cost (conversion loss, friction, trust deficit) but stays contained to one element	Flag for fixing
V2	Structural	Shapes the conversion architecture around itself; affects the page's overall flow	Flag for redesign
V3	Contagious	Forces OTHER pages, components, or funnel stages to be worse	Flag as urgent

V3 is not reserved for the "biggest" issues. It is reserved for issues that SPREAD. A weak CTA on one page is V1. A funnel architecture with no transitional CTA step -- forcing every page to be simultaneously an introduction AND a hard close -- is V3, because the missing step warps the design of every page in the funnel.

When assigning severity, always ask: "Does this issue force anything else to be worse?" If yes, it is V3 regardless of its own magnitude.

---

Scale Anchoring

Conversion Rate Assessment

Most content-to-lead funnels convert 1-5%. Above 10% is excellent and suggests strong product-market fit or a highly targeted traffic source. Below 0.5% indicates a fundamental mismatch between traffic source, page content, and CTA -- do not A/B test micro-changes; diagnose the structural problem first.

Persuasion Lens (Cialdini Review)

Read each of the 7 principles qualitatively: absent, weak/generic, specific/evidenced, or strong/authentic. Most competent pages use several principles well, but the target is not "all principles everywhere." Over-applied authority, scarcity, or habit mechanics can become manipulative. State which principles are appropriate for this page, what evidence supports them, and what would improve them.

Value Equation Lens

Read the 4 dimensions qualitatively: Dream Outcome, Perceived Likelihood, Time Delay, Effort. Identify the dimension that most weakens page conversion and whether the fix is page framing, proof, friction reduction, or a funnel-strategist offer-architecture handoff. Do not calculate a total or use the lens as a readiness gate.

SUCCESs Copy Lens

Read the 6 dimensions qualitatively: Simple, Unexpected, Concrete, Credible, Emotional, Story. Prioritize the dimensions most relevant to the conversion goal and locale. The output is a rewrite direction or handoff note, not a numeric copy grade.

---

Locale Awareness

Before generating any conversion component or copy, load the appropriate language profile from profiles/{languageCode}.json where {languageCode} is one of en, de, nl.

Persuasion Calibration by Locale

Persuasion norms vary by culture. The language profile contains locale-specific constraints, but these are the critical guardrails:

• de (German): Sachlichkeit (objectivity) is paramount. No fabricated scarcity, no aggressive urgency, no superlatives without evidence. Legal disclaimers are mandatory for any professional advice context. Authority signals must reference verifiable credentials (e.g., Fachanwalt titles, specific case counts).
• nl (Dutch): Professional but approachable ("u" form, not "jij" unless brand-appropriate). Healthcare-context components are special-category data under AVG. No fear-based language in dental/medical contexts. Trust signals should reference Dutch-specific platforms (ZorgkaartNederland, not Trustpilot).
• en (English): Standard GDPR applies. More latitude for direct persuasion than de/nl, but all claims must still be verifiable.

If locale is ambiguous, STOP at the Requirement Anchor and ask. Never silently default to English for Dutch or German brand work.

(See also: the Language Handling section below for runtime output-language policy — which language Claude responds in, Unicode preservation, frontmatter conventions. Locale Awareness is about persuasion norms per locale; Language Handling is about which language the output is written in.)

---

Output Format: components-manifest.json

When in Create mode, produce a components-manifest.json conforming to conversion-component-contract@1 (full schema in ${CLAUDE_SKILL_DIR}/references/conversion-component-contract.md). Place it in the Kind-3 zone conversion/<instance>/ at the project root per project-workspace-contract@2; if the project has not yet adopted the v2 contract, return incomplete per Phase 0a and request orchestrator/native or project-local bootstrap before writing components-manifest.json.

Contract Summary

The manifest is framework-neutral. conversion-designer specifies WHAT to build and WHY. site-builder decides HOW to build it.

• conversion-designer MUST NOT specify framework code (no .svelte or .astro snippets)
• conversion-designer MUST specify: placement, data requirements, state management, privacy, analytics, builder hints, locale, and content
• Every component must include a componentId, type, displayName, description, and all required subsections

Supported Component Types (v1)

Type	Description
scorecard	Interactive multi-dimension assessment with scoring, tiers, and segmented CTAs
cta	Call to action element (variants: direct, transitional, in-content, exit-intent)
trust-bar	Horizontal trust signals display (ratings, certifications, stats)
social-proof	Content-rich social proof block (testimonials, case counts, ratings carousel)

Ownership Boundary

conversion-designer owns manifest content. site-builder owns implementation. Neither skill may reach into the other's domain. See ${CLAUDE_SKILL_DIR}/references/conversion-component-contract.md (conversion-component-contract@1) for the full schema and validation rules.

---

Reference Loading Instructions

If the user asks what books, methods, or source traditions informed a page strategy, component recommendation, scorecard, CTA, trust bar, or audit finding, 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 observed/project evidence.

For Audit Mode

Step	Reference File	What to Extract
Funnel leak analysis	references/objection-map.md	Project-specific objection catalog
Method-lens selection	references/conversion-method-lenses.md + checklists/method-lens-checklist.md	Optional lens selection only when it changes strategy, evidence, route, or misuse handling
Persuasion audit	references/cialdini-principles.md	7 principles with qualitative authenticity and manipulation checks
Value equation	references/value-equation.md	4-dimension qualitative diagnostic
Copy audit	references/success-scoring.md	SUCCESs 6-dimension copy diagnostic
Behavior diagnostic	references/b-map-model.md	B=MAP (Motivation, Ability, Prompt) analysis
Page structure comparison	references/storybrand-wireframe.md	Expected section order and purpose

For Create Mode

Step	Reference File	What to Extract
Assessment design	references/scorecard-design.md	Dimension design, question psychology, tier segmentation
Method-lens selection	references/conversion-method-lenses.md + checklists/method-lens-checklist.md	Optional lens selection only when it changes component strategy, evidence, ethics, or route
Offer framing	references/value-equation.md	Dream Outcome, Likelihood, Time, Effort framing without changing offer architecture
Commitment ladder	references/cialdini-principles.md	Micro-commitment sequencing from low to high cost
Habit loop design	references/hook-model.md	Trigger-Action-Variable Reward-Investment loop
Page structure	references/storybrand-wireframe.md	Section-by-section conversion wireframe
Microinteractions	references/microinteraction-spec.md	Trigger-rules-feedback-loops for interactive moments

Templates (Create Mode Only)

Template	When to Use
templates/scorecard-template.md	Starting template for scorecard component entries
templates/cta-template.md	Starting template for CTA component entries (all 4 variants)
templates/trust-bar-template.md	Starting template for trust bar component entries
templates/social-proof-template.md	Starting template for social proof component entries

For Page Strategy Mode

Step	Reference File	What to Extract
Archetype selection	references/page-archetypes.md	Which single-page pattern fits the topic and conversion goal
Service-page structure	references/service-page-strategy.md	Section roles, proof needs, FAQ/linking/schema requirements
Copy framework	references/copy-frameworks.md	Authoring scaffold and regulated-domain adjustments
Method-lens selection	references/conversion-method-lenses.md + checklists/method-lens-checklist.md	Optional lens selection only when it changes page strategy, proof, CTA route, shareability, or route
Objection strategy	references/objection-map.md	Top visitor objections and counter-arguments
Trust/proof	references/cialdini-principles.md	Authority, social proof, liking, and commitment calibration
Value framing	references/value-equation.md	Outcome, likelihood, time delay, and effort framing
Copy quality	references/success-scoring.md	Simple, concrete, credible, emotional, story checks without numeric grading
Shareability	references/stepps-shareability.md	STEPPS triggers (Social Currency, Triggers, Emotion, Public, Practical Value, Stories) — consult when section plan or CTA strategy needs viral/shareable mechanics

Templates (Page Strategy Mode Only)

Template	When to Use
templates/page-strategy-pack.md	Main narrative strategy artifact for a page
templates/page-content-model.yaml	Structured fields for future site-builder or content collection handoff

Language Profiles

Profile	When to Load
profiles/en.json	English-language projects
profiles/de.json	German-language projects (iurFriend, DSGVO context)
profiles/nl.json	Dutch-language projects (AccentTandartsen, AVG context)

---

End-of-run (R26 — conditional)

Standard runs (mode determined, requirement anchor established, references loaded, checklist completed, output produced — audit report, components-manifest, or page-strategy pack) end normally — no self-improvement prompt fires.

The prompt fires only on conversion-designer-specific deviation. Triggers and prompt shapes:

• User overrode a default component variant ("don't use the default scorecard structure, we have our own") → "You overrode <component> with <your-pattern> because <reason>. Should templates/<component>-template.md learn the override pattern, or is your project's variant a one-off worth keeping local?"
• Mode mismatch detected mid-run (user invoked /conversion-create but the actual need was Page Strategy, or vice versa) → "I started in <mode-A> but the work converged on <mode-B> outputs. Should the SKILL.md routing in ## Operating Modes get a clearer disambiguation question, or was this a judgment call that won't recur?"
• Diagnostic Lens surfaced a finding the lens catalog doesn't name → "I caught <finding> against the page, but it didn't fit cleanly into any of the seven Diagnostic Lenses. Should an eighth lens be added to the catalog (proposed: <lens-name>), or was this a one-off framing?"
• Locale/compliance constraint surfaced beyond the language profile (e.g., German healthcare KVA requirement, Dutch BIG-register Fachverbund-citation rule) → "Your project surfaced <constraint> not captured in profiles/<locale>.json. Should the locale profile be extended to include it, or does this belong in the project's brand canonical instead?"
• Component output schema didn't fit the consuming site-builder's manifest expectations → "site-builder reported <schema-mismatch> against the components-manifest.json I produced. Should conversion-component-contract@1 be revised, or did this manifest violate the contract in a fixable way?"
• Brand voice override required mid-run ("the brand canonical says X but for this campaign we're going harder/softer") → "You overrode <voice-aspect> from BRAND.md for this campaign. Should the project's VOICE.md overlay capture this as a campaign-scoped exception, or is the canonical itself drifting?"
• Page Strategy / Audit / Create boundary breached (e.g., user wanted code in a Create-mode output, or wanted final page copy in a Page Strategy output) → "You asked for <out-of-scope-output>. Per ## What This Skill Does NOT Do, that belongs to <other-skill>. Should the routing message be sharpened, or was this a one-off ask?"

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 template / reference / locale profile) inline before going idle. If the user declines, keep the suggestion in the closing summary for the orchestrator; do not write AI-authored notes into the project's notes/ zone (human-authored under v2) or into workspace/ opaque scratch.

Standard runs end at output-handoff (audit report delivered, components-manifest written, page-strategy pack produced). 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, honor that declaration over inferred conversation language. Audit findings, component descriptions, and page-strategy prose follow output_language:.
• Load profiles/{languageCode}.json to constrain persuasion patterns per locale (German Sachlichkeit, Dutch AVG context, English standard direct-response). Locale profile drives what is sayable; output_language: drives what language it's said in.
• Translate internal checklist labels and section names naturally — do not force English headings into a German audit report or a Dutch page-strategy pack.
• Preserve legal, financial, and technical terms in their original language (Trennungsjahr, MwSt, BTW, Aufhebungsvertrag, Fachanwalt, ZorgkaartNederland, etc.) — never translate or transliterate domain concepts.
• Preserve Unicode characters natively (ü, ö, ä, ß, etc.); never substitute transliterations (ue, oe, ae, ss).
• Component copy in components-manifest.json (CTA labels, scorecard questions, trust-bar text) follows the locale of the consuming site, not the conversation language. If a Dutch site is being built in an English conversation, component copy is Dutch.
• Frontmatter field names and enum values stay English regardless of content language (type: scorecard, severity: V3, status: draft). 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, AVG, fear-based-language constraints, locale-specific trust platforms. 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 produce framework code. No .svelte, .astro, or .tsx files. That is site-builder's job.
• Does not alter existing design tokens. Visual styling is owned by the design-system-contract (see ${CLAUDE_SKILL_DIR}/references/design-system-contract.md).
• Does not implement consent banners. The consent architecture is documented in the conversion-component-contract; implementation is site-builder's responsibility.
• Does not run A/B tests. It produces hypotheses and component manifests. Testing infrastructure is out of scope.
• Does not access analytics platforms directly. It asks the user for actual numbers, then works with those numbers.
• Does not design multi-page funnels. Value ladders, offer stacks, funnel page sequences, and funnel economics belong to funnel-strategist.
• Does not write full final page copy by default. Page Strategy mode creates structure, section briefs, proof needs, FAQ plans, and handoff notes. Full drafting belongs to a content production workflow when the project has one.