@ericrisco/rsc 3.6.0 → 3.7.1

package/skills/landing-copy/SKILL.md

@@ -2,7 +2,7 @@
 name: landing-copy
 description: "Use when writing the words on a single conversion page — the hero headline and subhead, the offer, the proof and testimonials, and one primary CTA — or diagnosing a page that gets traffic and does not convert, as a copy problem rather than a layout one. NOT the paid ad that drives the click (that is `ads`), NOT the visual layout the words sit in (that is `design`), NOT the experiment that picks the winning variant (that is `ab-testing`)."
 tags: [landing-page, copywriting, conversion, hero-headline, cta, social-proof]
-recommends: [ads, design, brand-voice, ab-testing, case-studies]
+recommends: [ads, design, brand-voice, ab-testing, case-studies, offer-design, sales-funnel, vsl-script]
 origin: risco
 ---
 
@@ -17,8 +17,8 @@ This skill owns **conversion copy for a single page**: a hero headline under ~8
 - Writing or rewriting a hero: H1 + subhead + button copy.
 - Structuring a full landing/sales page (hook → problem → offer → proof → CTA → objections).
 - Choosing and writing one primary CTA and its repeated instances.
-- Turning features into benefits ("AES-256 encryption" → "your security team signs off in days").
-- Slotting proof — testimonials, metrics, logos, a guarantee — next to the ask.
+- Turning features into benefits ("preview before import" → "inspect exceptions before changing live records").
+- Slotting supported proof — demonstrations, permitted testimonials or contextualized metrics — next to the ask.
 - Making the page headline *match* the ad/email that drove the click (message match).
 - Rescuing a page that gets traffic but does not convert — when the failure is the words.
 
@@ -35,12 +35,20 @@ This skill owns **conversion copy for a single page**: a hero headline under ~8
 
 Boundary in one line: **you own the words that convert on one page; `ads` owns the click that arrives, `design` owns the layout they sit in, `ab-testing` owns the proof of which words win.**
 
-## The conversion reality (calibrate, never promise)
+## When the page carries a sales video
 
-These numbers set expectations. State them as a band; the moment you promise a flat conversion rate you are lying to the user.
+Use the campaign's approved offer revision, research and funnel brief before drafting. When these exist under `02-DOCS/wiki/marketing/<campaign>/`, reuse them; keep established project paths. Read [the VSL page handoff](references/vsl-page-handoff.md) when a video is the main sales argument or its claims differ from the page.
 
-- **Cross-industry median is ~6.6%; strong pages in any vertical reach 10–15%+.** Per-vertical the spread is wide: Events & Entertainment ~12.3%, Financial Services ~8.4%, SaaS/Tech ~3.8%, Ecommerce ~2.35%, B2B services ~1–3%. *Why:* a SaaS team told "you'll hit 12%" was quoted the events median; quote the band for *their* vertical so the goal is real. (Foundry CRO benchmarks 2026, citing Unbounce's analysis of 464M visits / 41k pages.)
-- **Visitors decide whether to stay in ~5 seconds, and ~80% rarely scroll past the fold.** *Why:* the hero is the single highest-leverage copy on the page — if it does not answer "what is this and why should I care" before a scroll, the rest is unread. (Hero-section research / NN/g attention studies 2026.)
+Treat video and page as two ways to understand the same offer. Preserve the same deliverables, price, conditions, evidence IDs and primary action. A visitor who cannot play the video still needs the essential offer and purchase conditions in text. A short introduction can invite playback; it does not replace the written decision path.
+
+- Offer is undecided → `offer-design` owns that decision, not a more forceful headline.
+- Multiple pages or booking/payment paths → `sales-funnel` owns the route.
+- Spoken narration, pacing and scene cues → `vsl-script` owns the video.
+- Unsupported ad/video claim → flag the mismatch and draft from supported facts; repeating the claim does not validate it.
+
+## Establish a baseline before predicting conversion
+
+Use the account's observed traffic, eligible visitors and completed actions when available. Define the conversion and observation window before comparing rates. If no baseline exists, say so and route measurement to `analytics` and experiment design to `ab-testing`. External benchmarks need dated sources and comparable audiences; they are not promised outcomes.
 
 ## The four blocks — the spine of the page
 
@@ -48,18 +56,18 @@ Every conversion page is these four jobs, top to bottom. Each has a distinct que
 
 | Block | Must answer | Lives where | Failure mode if weak |
 | --- | --- | --- | --- |
-| **Hook** | "What is this and why should I care?" in <5s | Hero, above the fold | Visitor bounces before scrolling; ~80% never see the rest |
+| **Hook** | "What is this and why should I care?" in <5s | Hero, above the fold | Visitor cannot tell whether to continue |
 | **Offer** | "What exactly do I get, and what does it cost me?" | Right after the hook / problem | Feature dump; reader can't tell what they walk away with |
 | **Proof** | "Why should I believe you?" | Adjacent to each CTA | Claims read as marketing; trust never forms |
 | **CTA** | "What is the one thing to do next?" | Hero, repeated down the page | Competing asks → decision fatigue → no click |
 
 ## The hook
 
-The H1 carries the *what*; the subhead carries the *benefit*; both must echo whatever the visitor clicked.
+The H1 carries the *what*; the subhead carries the *benefit*; both must stay consistent with the supported offer behind the visitor's click.
 
 - **H1 under ~8 words / ~44 characters.** The constraint forces clarity, and a clear headline beats a clever one every time. If you can't say it in 8 words you don't understand the offer yet.
 - **Subhead carries the benefit** — who it's for and the outcome they get, in one clause.
-- **Message match:** the headline must echo the promise of the ad/email that drove the click. Aligning a single claim across ad + page has produced a 66% CVR lift in documented cases (and 212% from fixing message match alone). *You match the page to the ad; writing the ad is `ads`.*
+- **Message match:** maintain the supported offer and action from the ad/email. If its promise lacks evidence, flag it and draft from verified facts; consistency does not make an unsupported claim true. `ads` owns correction of the source ad.
 
 ```text
 Bad  — "Reimagine The Future Of Financial Operations"   (clever, 6 words, says nothing)
@@ -74,27 +82,21 @@ Name the thing, the outcome, and the cost in effort or money. Lead with the outc
 The scaffold is **FAB** — Feature → Advantage → Benefit — but you stop at the benefit the reader cares about and back it with the mechanism as proof, not the other way round.
 
 ```text
-Bad  — "Our platform has advanced AES-256 encryption."
-Good — "Protect customer data with AES-256 encryption, so your security team
-         signs off in days, not months."
+Feature — "Import preview."
+Benefit — "Inspect the exceptions before you approve changes to live records."
+Evidence — A verified demonstration of the actual preview and approval flow.
 ```
 
 Rule: every feature line answers "so what?" with an outcome. If it can't, cut it.
 
 ## The proof
 
-Belief is built next to the ask, not in a wall of quotes elsewhere.
+Choose evidence that supports the claim the visitor is deciding on. A product demonstration can establish behavior; a customer result needs its source, context and permission. A guarantee is a commercial condition, not evidence of effectiveness.
 
-- **3–5 specific, named testimonials, each with a concrete result.** "Great product!" persuades no one; "cut our close time from 9 days to 2 — Maria, CFO at Lumen" does. Specific beats superlative.
-- **Place proof adjacent to the primary CTA.** Social proof next to the ask has lifted conversion ~68% in documented cases; reviews/testimonials are decisive for ~93% of buyers and ~88% trust them like a personal recommendation. *Why:* belief and the decision happen in the same moment — put the evidence where the click is.
-- Numbers, recognizable logos, and a risk-reversal (money-back, no card required) are proof too. One hard number outweighs three adjectives.
-- **Never fabricate proof.** If a metric, quote, or logo isn't real, mark `[[NEEDS PROOF]]` and ask the user — do not invent it.
-
-```text
-Bad  — "Loved by teams everywhere. World-class results!"
-Good — "We cut expense-report time 82% in the first month."
-         — Maria Ortiz, CFO, Lumen (47-person finance team)
-```
+- Use permitted, attributable testimonials when available; there is no required quota of names or numerical results.
+- Place relevant proof near the claim or action it supports. Keep its scope clear: one customer result does not establish a typical outcome.
+- Without outcome evidence, show verified product behavior and narrow the promise. Mark unresolved evidence in draft notes, not as public endorsements.
+- Preserve evidence IDs and publication status from the offer brief. A public review is not automatically cleared for promotional reuse.
 
 ## The CTA
 
@@ -102,7 +104,7 @@ One primary action, verb-led, repeated — not varied — down the page.
 
 - **One primary CTA per page.** Competing asks cause decision fatigue and lower conversion. The same action appears in the hero and again at each decision point; secondary links may exist but must not compete visually or verbally with the primary.
 - **Movement verbs, never "Submit".** "Start free trial", "Get my quote", "See plans" — the button states the value, not the form action.
-- **First-person framing often lifts clicks:** "Start my free trial" reads as the visitor's own intent. Pair the button with one line of friction-reducing microcopy ("No credit card required").
+- **First-person framing is one option to test:** "Start my free trial" reads as the visitor's own intent. Pair the button with one line of friction-reducing microcopy ("No credit card required").
 
 ```text
 Bad  buttons — [Submit]            [Learn more]        [Contact sales]
@@ -137,19 +139,19 @@ its derivatives). In Claude Code a Stop hook runs the same check on your final a
 | "A clever headline will stand out" | Clever is unclear. Name the outcome in <8 words; clear beats clever. |
 | "More features = more value shown" | Feature dumps bury the benefit. Lead with the outcome, then the mechanism. |
 | "Give them several CTAs to choose from" | Choice kills conversion. One primary action, repeated, not varied. |
-| "Any testimonials will do" | Generic raves don't persuade. 3–5 named quotes with a hard result, near the CTA. |
+| "Any testimonials will do" | Use relevant, permitted evidence; a verified demonstration may be the best available proof. |
 | "World-class, cutting-edge, game-changing" | Hype words signal AI-template copy. Replace with a number or a named result. |
-| "The page can say its own thing" | If the headline ignores the ad's promise, you lose the message-match lift. Echo the click. |
-| "Promise them a 12% conversion rate" | Never promise a flat number. Quote the band for their vertical. |
+| "The page can say its own thing" | Keep the supported promise consistent; correct unsupported source claims instead of repeating them. |
+| "Promise them a 12% conversion rate" | Use an observed baseline and explicit test; mark performance unmeasured when no data exists. |
 | "I'll invent a plausible metric" | Never. Mark `[[NEEDS PROOF]]` and ask the user. |
 
 ## Page skeleton + worked example
 
-The annotated top-to-bottom skeleton (hook → problem → offer → proof → CTA → objections/FAQ → final CTA), with one fully worked B2B SaaS example and the variable slots marked, lives in `references/page-skeleton.md`. Start there when you write a full page rather than a single block.
+The annotated top-to-bottom skeleton (hook → problem → offer → proof → CTA → objections/FAQ → final CTA), with a worked demonstration-led example and explicit source limits, lives in `references/page-skeleton.md`. Start there when you write a full page rather than a single block.
 
 ## Verify your copy
 
-Run `scripts/verify.sh` over the file you wrote (or your project) before claiming done. It is a read-only, dependency-free static check: H1 length, exactly one primary CTA verb (flags competing asks), presence of a proof block and a benefit subhead, a banlist of hype/AI-tell phrases, and a "Submit" warning. It warns on soft issues and exits non-zero only on hard ones (no CTA, no proof). It is a backstop, not the judgement — the four-block table is.
+Run `scripts/verify.sh` over the file you wrote (or your project) before claiming done. It is a read-only, dependency-free static check: H1 length, exactly one primary CTA verb (flags competing asks), presence of a proof block and a benefit subhead, a banlist of hype/AI-tell phrases, and a "Submit" warning. It warns on soft issues and exits non-zero only on hard ones (no CTA, no proof). It detects proof-shaped text, not factual support or publication permission; those require source review. Demonstrations are valid proof markers when their claims match the behavior shown.
 
 ## See also
 

package/skills/landing-copy/evals/README.md

@@ -16,3 +16,10 @@ rubric-scored generation: run the scenario with and without the skill loaded and
 grade each output against `must_include` (one point per item); the skill passes
 if WITH covers >= 80% and clearly beats WITHOUT. Report raw fractions, not a
 rounded pass, and re-run after any edit to `SKILL.md` or the references.
+
+## VSL integration validation — 2026-10-31
+
+The added offer-revision scenario and source-grounding repairs were statically reviewed.
+The proof-marker regression tests exercise demonstration-only evidence and paths with spaces.
+The revised skill was applied to the product README. These checks are not a fresh A/B measurement
+of landing-copy quality; the capability comparisons described above remain a separate evaluation.

package/skills/landing-copy/evals/cases.yaml

@@ -54,10 +54,18 @@ capability:
     must_include:
       - "H1 is under ~8 words / ~44 chars and is clear, not clever (names the outcome)."
       - "Subhead carries the benefit and names who it is for."
-      - "Headline echoes the ad's '80%' promise (message match), not a disconnected claim."
+      - "Identifies the ad's 80% as an unverified claim; requests its source or drafts without repeating it as proven."
       - "Offer lines are feature->benefit (FAB), benefit on top with the mechanism beneath — not a bare feature list."
-      - "3-5 specific, named testimonials each with a concrete numeric result, placed adjacent to the CTA."
+      - "Does not invent named testimonials or numeric customer results; marks missing evidence for collection and uses only supplied facts."
       - "Exactly one primary CTA with a movement verb (e.g. 'Start my free trial'), repeated unchanged — no competing asks, no 'Submit'."
       - "No banned superlatives ('world-class', 'cutting-edge', 'game-changer', 'revolutionize', 'seamlessly')."
-      - "Conversion expectation, if mentioned, is given as a per-vertical band (SaaS ~3.8%), never a flat promised number."
+      - "Treats conversion performance as unmeasured because the scenario provides no baseline; does not invent a benchmark or promise a rate."
       - "Any proof that is not real is marked [[NEEDS PROOF]], not fabricated."
+
+  - scenario: "Write the hero and purchase section around a VSL for a workshop. Approved offer rev2: EUR 180, two live sessions, no individual review, start 12 November, refund until 48 hours before start. Old video rev1 says EUR 120 with personal review. Evidence E1 is a public demo; a testimonial E2 has no publication permission. Audience includes visitors who cannot play video. No measured conversion results. Deliver useful copy and the handoff decision."
+    must_include:
+      - "Uses rev2 price and scope in draft copy and marks rev1 video as needing correction before coordinated publication."
+      - "Provides essential offer and refund conditions in text without requiring playback."
+      - "Uses E1 demonstration and excludes the unapproved E2 testimonial from public copy."
+      - "Keeps one primary action and identifies unresolved destination or booking details without inventing them."
+      - "Does not promise conversion improvement or invent evidence."

package/skills/landing-copy/references/frameworks.md

@@ -2,7 +2,8 @@
 
 Frameworks are skeletons you fill with the **buyer's own words** — never fill-in
 templates you ship as-is. Pick one for the page's spine and one (FAB) for the
-offer block. Each example below is fresh; mine the structure, not the wording.
+offer block. Examples below are fictional illustrations, not evidence or publishable customer claims.
+Use only behavior and outcomes supported by the actual product evidence.
 
 ## PAS — Problem, Agitate, Solution
 
@@ -35,16 +36,16 @@ Strong for **transformation** stories and pages built around a customer journey.
 
 This is the feature→benefit transform. Climb the ladder, then **stop at the benefit** the reader cares about and use the feature/mechanism as the proof underneath.
 
-- **Feature** — what it has: "AES-256 encryption."
-- **Advantage** — what that does: "data is unreadable if intercepted."
-- **Benefit** — what the buyer gets: "your security team signs off in days, not months."
+- **Feature** — what it has: "Import preview."
+- **Advantage** — what that does: "shows records needing review before the import."
+- **Benefit** — what the buyer gets: "inspect exceptions before approving changes to live records" (when the product supports this preview).
 
 Write the benefit as the line; keep the feature as the evidence beneath it.
 
 ```text
 Bad  — "Includes SSO, SCIM provisioning, and audit logs."
-Good — "Onboard a new hire in one click and prove who touched what in an audit —
-         SSO, SCIM, and full audit logs handle the rest."
+Better — "Review recorded access changes in the audit log."
+Use only if that behavior is verified; the feature list alone does not prove it.
 ```
 
 ## Awareness stage changes how much you agitate

package/skills/landing-copy/references/page-skeleton.md

@@ -1,92 +1,51 @@
-# Page skeleton + worked example
+# Page skeleton and evidence-led example
 
-The top-to-bottom skeleton of a conversion page. Each block has one job (see the
-four-block table in `SKILL.md`). Variable slots are marked `{{like_this}}` — fill
-them with the buyer's real words and *real* proof. Cut any block that has no job
-for this product; do not pad.
+Choose sections by the buyer's unanswered questions. For a VSL page, also read
+`vsl-page-handoff.md`; the video and readable text carry the same offer revision.
 
-## The skeleton
+## Section decisions
 
-```text
-1. HOOK (above the fold)
-   H1:       {{outcome in <8 words / ~44 chars}}
-   Subhead:  For {{who}}, {{benefit}} — {{how, one clause}}.
-   CTA:      [{{movement verb + value}}]    e.g. [Start my free trial]
-   Microcopy: {{friction reducer}}          e.g. No credit card required
-   (Message match: the H1 echoes the ad/email that drove the click.)
-
-2. PROBLEM  (skip or shorten for warm/hot traffic — see frameworks.md)
-   Name the pain in the reader's words: "{{the friction they live with today}}."
-   One line of agitation if traffic is cold. No more.
-
-3. OFFER
-   What they get: {{the thing}}.
-   Benefit-led feature lines (FAB — benefit on top, mechanism beneath):
-     - {{benefit}}, because {{feature/mechanism}}.
-     - {{benefit}}, because {{feature/mechanism}}.
-     - {{benefit}}, because {{feature/mechanism}}.
-   Cost/effort: {{price or "free to start" or "5-minute setup"}}.
-
-4. PROOF  (place adjacent to the CTA below it)
-   3–5 named testimonials, each with a concrete result:
-     "{{result, with a number}}" — {{Name, Role, Company}}
-   Plus: {{metric}} · {{recognizable logos}} · {{risk reversal / guarantee}}.
+| Question | Content | Evidence needed |
+| --- | --- | --- |
+| Is this for me? | Clear headline, audience, supported benefit, primary action | Buyer research and approved offer |
+| Why consider it? | Relevant problem or current alternative; shorten for informed visitors | Research, distinguished from assumptions |
+| What do I receive? | Included items, scope, prerequisites and cost | Approved offer revision |
+| Why believe it? | Demonstration, permitted testimony or contextualized measured result | Source ID, scope and permission |
+| What happens next? | Action, destination, next step and exact conditions | Verified journey or explicit draft requirement |
+| What could stop me? | Real objections, answered with known facts | Research and product constraints |
 
-5. CTA (repeated — same verb as the hero, not a new one)
-   [{{same movement verb + value}}]
-   Microcopy: {{same friction reducer}}
+Repeat one primary action at useful decision points. There is no required quota of testimonials.
+A guarantee is a condition, not evidence that the product achieves a result. Keep unsupported
+claims outside public copy and state what evidence or decision would resolve them.
 
-6. OBJECTIONS / FAQ
-   Pre-empt the top 3–5 reasons not to act, each as a question → direct answer.
-   "Do I need a card?" "What if it doesn't work for my team?" "How long is setup?"
+## Worked example: fictional fixture, verified behavior supplied
 
-7. FINAL CTA
-   [{{same movement verb + value}}]   — last chance, same single action.
-```
-
-## Worked example — B2B SaaS (expense automation)
-
-Traffic source: a Google ad reading **"Cut expense-report time 80%"**. The hero
-must echo that promise (message match).
+Assume the task supplies these facts: a migration preview flags duplicate accounts before writing
+live records; importing requires an approver; demo E1 uses synthetic records; the action is booking
+a walkthrough. There are no customer results, delivery-time measurements or published prices.
 
 ```text
-1. HOOK
-   H1:        Expense reports done in 30 seconds
-   Subhead:   For finance teams of 20–200 drowning in receipts — snap a photo,
-              we file and route it for approval automatically.
-   CTA:       [Start my free trial]
-   Microcopy: No credit card. 5-minute setup.
-
-2. PROBLEM
-   Month-end means chasing 40 people for crumpled receipts and reconciling a
-   spreadsheet you don't fully trust. It eats the days you should spend forecasting.
+HEADLINE
+Review import exceptions before going live
 
-3. OFFER
-   Lumen turns every receipt into a filed, categorized, approval-ready report.
-     - Close the month in 2 days instead of 9, because rules auto-categorize every line.
-     - Catch policy breaches before they post, because checks run at submit time.
-     - Audit-ready in one export, because every approval is logged automatically.
-   Free for your first 50 reports. $8 / active user / month after.
+SUBHEAD
+For teams migrating account records: see flagged duplicates before an approver authorizes the import.
 
-4. PROOF  (sits right above the CTA)
-   "We cut expense-report time 82% in the first month — month-end went from three
-    late nights to a Tuesday afternoon." — Maria Ortiz, CFO, Lumen (47-person team)
-   "Closed our books in 2 days for the first time ever." — Daniel Roca, Controller, Vora
-   Trusted by 1,200 finance teams · SOC 2 Type II · 30-day money-back guarantee
+ACTION
+Book a walkthrough
 
-5. CTA
-   [Start my free trial]    No credit card. 5-minute setup.
+WHAT YOU CAN INSPECT
+The preview identifies records requiring review. Your approver decides whether the mapping is ready.
 
-6. FAQ
-   Q: Do I need a credit card to start? A: No — the first 50 reports are free.
-   Q: Will it work with my accounting tool? A: Syncs with QuickBooks, Xero, NetSuite.
-   Q: How long is setup? A: Five minutes — connect your cards, set rules once.
+PRODUCT DEMONSTRATION
+Watch the preview flag duplicate accounts in synthetic test data, then show the approval step.
 
-7. FINAL CTA
-   [Start my free trial]
+WHAT HAPPENS NEXT
+Book a walkthrough to see the process and discuss your migration requirements.
 ```
 
-Note what carries the weight: the H1 echoes the ad ("80%" → "30 seconds / 82%"),
-the offer lines are benefits-with-mechanism (FAB), the proof is named and numeric
-and sits next to the ask, and the **one** CTA verb ("Start my free trial") repeats
-unchanged. No "world-class", no second competing button, no promised conversion rate.
+Production note: capture E1 and verify the booking destination before publication. The example
+supports preview and approval behavior. It does not support a claim that errors are eliminated or
+migration finishes within a particular time. A source ad promising those outcomes must be corrected,
+not echoed to preserve message match. Private source IDs belong in the handoff, not necessarily in
+public-facing copy.

package/skills/landing-copy/references/vsl-page-handoff.md

@@ -0,0 +1,9 @@
+# A page and video that agree
+
+Read the offer revision, funnel decision and VSL before writing. Produce a small alignment table: promise, included items, price/currency/tax wording, payment terms, guarantee, deadline, evidence IDs and destination. Record the source revision for each. A changed price invalidates earlier video/page copy until reconciled; do not silently choose the more persuasive version.
+
+Give visitors three useful paths: watch with captions, read the essential argument, or reach the stated next action. Put meaningful button labels at points where a decision is possible. Hiding essential conditions until a timer expires is not a requirement of a VSL page. Do not add autoplay or delay checkout without a user-approved rationale and a way to access the offer without playback.
+
+Keep private source notes separate from public copy. Pending testimonials are draft placeholders, never invented quotes. If permission is missing, omit identifying details and use a supported product demonstration where available. A quote's existence is not permission to publish it.
+
+Deliver copy by section, a video placement/accessible-text note, the shared action label and destination, the offer revision, and an explicit list of unpublished claims. Hand layout to design, implementation to the selected stack, playback events to analytics and controlled comparisons to ab-testing. Do not claim that a text linter proves the assertions or conversion performance.

package/skills/landing-copy/scripts/verify.sh

@@ -5,7 +5,7 @@
 # WHAT IT DOES (read-only; never edits a file)
 #   Network-free static checks over a generated landing-copy file (or a tree):
 #     1. HARD  no CTA at all (no button-style line, no movement-verb call to act).
-#     2. HARD  no proof block (no testimonial/quote marker and no metric).
+#     2. HARD  no proof block (no testimonial/quote, metric or demonstration marker).
 #     3. SOFT  H1 over ~8 words or ~60 chars (warn — clarity beats clever).
 #     4. SOFT  competing CTAs — more than one distinct primary action verb used
 #              as a button-style line (decision fatigue).
@@ -29,7 +29,7 @@
 #   1  a hard violation, or --strict with any warning
 #   2  bad usage
 #
-# POSIX sh, no external deps beyond grep/wc. Runs on stock macOS /bin/sh.
+# Bash 3.2+, no external deps beyond grep/wc. Runs on stock macOS /bin/sh.
 
 set -eu
 
@@ -88,7 +88,7 @@ CTA_VERBS='start|get|see|book|claim|try|join|download|create|build|grab|reserve|
 BANLIST='world-class|cutting-edge|revolutioni[sz]e|game-changer|game changer|seamlessly|unlock the power|in today.?s fast-paced world|next-level|best-in-class'
 
 checked=0
-for f in $FILES; do
+while IFS= read -r f; do
   [ -f "$f" ] || continue
   [ -s "$f" ] || continue
   checked=$((checked + 1))
@@ -101,12 +101,12 @@ for f in $FILES; do
     fail "$f: no CTA found (no movement verb, no button) — a page needs one primary action"
   fi
 
-  # 2. HARD: proof present? a quote/testimonial marker OR a number/metric.
-  if grep -Eq '"|“|”|>|—|--|testimonial|trusted by|review' "$f" \
+  # 2. HARD: a proof-shaped block exists. This heuristic does NOT verify truth or permissions.
+  if grep -Eiq 'demonstration|demo:|demostración|demostracion|"|“|”|>|—|--|testimonial|trusted by|review' "$f" \
      || grep -Eq '[0-9]+%|[0-9]+x|\$[0-9]|[0-9][0-9,]+ (customers|teams|users)' "$f"; then
     :
   else
-    fail "$f: no proof block found (no testimonial/quote and no metric) — belief is built next to the ask"
+    fail "$f: no proof block found (add a sourced demonstration, testimonial or metric) — belief is built next to the ask"
   fi
 
   # 3. SOFT: H1 length. First markdown '# ' heading or first non-empty line.
@@ -148,7 +148,7 @@ for f in $FILES; do
   if grep -Eiq '(^|[^a-z])submit([^a-z]|$)' "$f"; then
     warn "$f: 'Submit' as button copy — use a movement verb that states the value (e.g. 'Start my free trial')"
   fi
-done
+done <<< "$FILES"
 
 printf '\n'
 if [ "$fail_count" -gt 0 ]; then

package/skills/offer-design/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: offer-design
+description: "Use when deciding what a buyer receives, why it solves their problem, and which promises, extras and conditions the seller can support. Produces an evidence-backed offer brief. NOT setting price levels (that is `pricing`) or writing the page (that is `landing-copy`)."
+tags: [offer, value-proposition, differentiation, guarantee, deliverables, commercial-terms]
+recommends: [customer-research, pricing, sales-funnel, vsl-script, landing-copy]
+origin: risco
+---
+
+# Offer design — a promise the business can fulfill
+
+Define the exchange between seller and buyer before expressing it in a landing or video. An offer can be a paid service, a product, a trial or a free tool. Respect the actual business model; a free project does not need an invented price, bonus or refund promise.
+
+## Read the facts once
+
+Load existing buyer research, product facts, approved terms and campaign artifacts. Identify the buyer's desired result, the current alternative, available proof and delivery constraints. Missing buyer evidence goes to `customer-research`; choosing price levels, tiers and margin floors goes to `pricing`. You can draft around an unknown, but mark it as proposed or unresolved.
+
+Use the user's approved price and conditions. Never replace them because a template favors a different offer. If two artifacts disagree, identify their revisions and resolve the conflict from owner-approved terms; otherwise ask which is authoritative before treating either as settled.
+
+For an authorized saved campaign, reuse its location or write `02-DOCS/wiki/marketing/<campaign>/offer.md`, linked from `02-DOCS/wiki/index.md`. Give the offer a stable ID and revision, with the research revision it consumes. Analysis-only requests stay in the response.
+
+## Construct the promise from delivery outward
+
+Work through four connections. Each needs an answer or a visible unresolved decision.
+
+| Connection | Decision to make |
+| --- | --- |
+| Buyer problem → promised result | Which specific result matters to this segment, and what remains outside the seller's control? |
+| Result → deliverable | What does the buyer actually receive, when does work start, and what counts as completion? |
+| Deliverable → reason to believe | Which real product behavior explains the result, and what evidence supports each step? |
+| Commitment → operating capacity | Who must do the work, what inputs are required, and what limits the number of buyers served? |
+
+Separate **deliverables the seller controls**, **outcomes that depend on the buyer**, and **aspirations still awaiting evidence**. A compelling aspiration is not permission to promise it.
+
+### Explain the mechanism without inventing an invention
+
+Describe the causal chain in plain language: product action → intermediate effect → buyer benefit. Link each step to an evidence ID or label it a hypothesis. Compare it with the buyer's current alternative, not an invented weak competitor.
+
+A familiar method can still be useful. Claim exclusivity only when established; naming a method does not make it proprietary. Use a demonstration of verified behavior when outcome evidence is absent. Label synthetic examples as demonstrations, never customer results.
+
+### Reconcile promises with capacity
+
+Calculate the simplest delivery ceiling from supplied constraints: available hours divided by required hours per engagement, for example. Include support, review and rework if known; if not, identify the calculated ceiling as an upper bound. State customer prerequisites and when any delivery clock starts. Do not turn an unmeasured turnaround into a deadline guarantee.
+
+For extras, specify the buyer obstacle each removes and its delivery cost. Keep extras that make the core offer easier to use. A reference value requires a real, relevant basis; without one, describe the utility without a currency valuation. Scarcity requires an actual constraint and current availability, not merely a theoretical capacity ceiling.
+
+### Design terms as decisions, not decorative copy
+
+Keep approved conditions exact. New terms are proposals until approved, including support limits, refund windows and availability. For a proposed remedy, state the triggering condition, eligible buyer action, remedy and operational owner. Discuss feasibility before recommending a guarantee the seller cannot honor.
+
+An absent voluntary guarantee does not establish that all sales are legally final. Preserve known terms and flag missing policy for its owner; use `terms-conditions` when legal drafting is requested. Do not invent rights or waive existing obligations.
+
+## Deliver the offer brief
+
+Provide a usable version now, separating approved facts from proposals:
+
+- **Identity:** offer ID/revision, buyer segment, source research revision and primary action.
+- **Promise:** intended result, qualified wording, exclusions and dependencies.
+- **Delivery:** included items, completion definition, required buyer inputs, timing basis and support boundary.
+- **Differentiation:** causal explanation, relevant alternative and evidence IDs for demonstrable claims.
+- **Commercial terms:** approved price, currency, tax treatment, payment schedule and policies; unknowns remain explicit.
+- **Proof map:** claim → source → what it establishes → publication/use status. Private interview insights can guide the offer without becoming public testimonials.
+- **Open decisions:** proposed changes, accountable owner and what must be resolved before publication.
+- **Validation:** one remaining uncertainty, a practical check and the result that would change the offer.
+
+If no single package dominates, compare a small number against the same buyer need, evidence and capacity constraints. Recommend one and explain the trade-off. Do not assign invented conversion percentages.
+
+When revising an offer, list changed terms and affected artifacts. The landing, VSL and funnel must name the same approved offer revision before publication. A price change is incomplete while a linked video still quotes the old price. Hand off the brief; generating copy, publishing pages and taking payments remain separate tasks.
+
+## Failure modes
+
+| Failure | Correction |
+| --- | --- |
+| A new name is the only differentiator | Explain an observable process difference or narrow the comparison honestly. |
+| Every buyer objection becomes another bonus | Check whether the core delivery itself needs improvement. |
+| The cheapest package requires unbounded labor | Bound fulfillment first and route economic decisions to `pricing`. |
+| Unknown terms disappear into confident copy | Preserve proposal status through the landing and video handoffs. |
+
+This skill's evidence and feasibility decisions need semantic review. A grep cannot establish that a promise is supported; use the capability eval rather than a decorative artifact checker.
+
+## Orientación (siempre)
+
+Habla con la voz de `orient`: frases cortas, una idea por frase, y cada respuesta se entiende sola. Registro técnico o con analogías según `technical_level` en `02-DOCS/wiki/harness/user-profile.md`. Cierra cada turno con el **bloque-brújula** (📍 dónde estás · ➡️ siguiente, terminando en pregunta; ✅ y 🧭 cuando hay algo hecho o decidido). **Nunca termines en seco.** Protocolo completo: skill `orient` → `skills/orient/references/orientation-contract.md`. (Defiere a `suggest` el "¿instalo la skill que falta?".)

package/skills/offer-design/evals/README.md

@@ -0,0 +1,26 @@
+# offer-design evaluation
+
+`cases.yaml` separates routing from capability. These are judgment evaluations, not deterministic proof of commercial performance.
+
+## Routing
+
+Present only the skill description plus the competing catalog descriptions to a fresh agent. Run each positive and negative prompt in three fresh trials. A case passes when the majority selects the intended owner; target at least 90% accuracy across cases. Inspect ambiguous cases rather than broadening the description to catch everything.
+
+## Capability
+
+Run each complete scenario in fresh isolated sessions: baseline without this skill or its rubric, treatment with this skill. Both receive identical source facts and permitted tools. Keep the repository read-only and save outputs outside tracked files. Use three trials for a release evaluation; retain the actual outputs and session/tool records.
+
+Blind the arm labels before an independent grader reads the outputs. Grade each `must_include` item with an exact supporting excerpt, then completeness, actionability, correctness and grounding on 0–10. Use the repository's `scripts/skill-behavior-eval.js` scorer: treatment absolute score must be at least 8.5 and lift over baseline at least +1.0. Run transcript integrity checks where available; absence of such checks is a reported limitation, never an integrity pass.
+
+The structural linter checks YAML shape and routes. It cannot determine whether an inference is warranted, a promise feasible or a permission sufficient. No `verify.sh` claims to do that. Neither a judge score nor a well-formed brief proves sales lift. Test changed descriptions and bodies again; record actual results separately from these instructions.
+
+## Initial evaluation — 2026-10-31
+
+One capability scenario, one fresh execution per arm, independently blind-graded:
+with skill **9.8/10**, without **8.7/10**, difference **+1.1**.
+The catalog scorer requires absolute >=8.5 and improvement >=1.0. This run
+passed both numerical thresholds.
+This is a single-trial result, not the repeated-trial protocol above or evidence of conversion gains.
+Arms used separate contexts and files; the scorer reported transcript integrity **not checked**.
+The owner authorized release 3.7.0 with the pack’s incomplete behavioral evidence documented.
+The thresholds remain unchanged; release authorization is not an evaluation pass.

package/skills/offer-design/evals/cases.yaml

@@ -0,0 +1,42 @@
+skill: offer-design
+
+should_trigger:
+  - prompt: "Turn this service into a clear offer with deliverables, boundaries and credible proof."
+    why: "Defines the commercial promise and fulfillment commitment."
+  - prompt: "People understand the product but can't tell why they should choose our package."
+    why: "Diagnoses offer differentiation before rewriting copy."
+  - prompt: "Quiero que la oferta sea más atractiva sin inventar bonos ni bajar el precio."
+    why: "Spanish request changes actual value and terms, not price optimization."
+  - prompt: "Check whether our guarantee and bonus fit what the team can actually deliver."
+    why: "Connects promise to capacity and conditions."
+  - prompt: "Explain why our method works using these product facts, then choose the strongest offer angle."
+    why: "Mechanism development belongs inside evidence-backed offer design."
+
+should_not_trigger:
+  - prompt: "Set our SaaS seat price and calculate the margin floor."
+    route_to: pricing
+    why: "Pricing owns price levels and economic models."
+  - prompt: "The offer is approved. Write the landing page around it."
+    route_to: landing-copy
+    why: "Expression of settled terms belongs to page copy."
+  - prompt: "Create the Stripe products and checkout session for this price."
+    route_to: stripe
+    why: "Billing implementation does not design the offer."
+  - prompt: "Read these interviews and discover what buyers care about."
+    route_to: customer-research
+    why: "The missing input is buyer evidence, not a commercial package."
+
+capability:
+  - scenario: |
+      Produce an offer brief ready for a landing/VSL team for DataRelay, a migration service. Work only from these facts; do not write the landing or implement checkout. Owner-approved price is EUR 900 including taxes, paid once. The team can spend 24 engineer-hours per week on migrations. Each client requires 8 engineer-hours before any extras. The owner proposes: "Move in 48 hours, zero errors guaranteed; unlimited live help; a EUR 2,000 bonus; only two places left." No bonus has ever been sold, no capacity has been booked this week, and no refund policy has been approved.
+      Product facts: before writing to production, the service produces an exception report and asks the customer's owner to approve the mapping. Import runs only after approval. Mapping review requires the customer's sample export and one named approver. There is no measured delivery-time history. Other providers also offer migration previews, so this is not an exclusive invention.
+      Buyer evidence R-1, research revision 2: small firms fear discovering errors after going live; two interviewees asked to inspect exceptions first. These interviews are private and cannot be quoted publicly. Evidence E-1: the product's documented preview-and-approval behavior can be demonstrated on synthetic data. Evidence E-2: one client said "the preview caught our duplicate accounts"; no quantitative result or publication consent. Draft offer O-1 revision 1 still says EUR 750 and links to the landing and video briefs. Owner asks for a usable offer now and a minimal validation step, not another broad discovery interview.
+    must_include:
+      - "Keeps the approved EUR 900 including taxes, one-time price; explicitly supersedes EUR 750 and identifies landing/video briefs as needing refresh against the new offer revision."
+      - "Derives a maximum of three base migrations per week from 24/8 and states that support, rework or scheduling can reduce that ceiling; does not present two remaining places as a fact."
+      - "Replaces unconditional 48-hour/zero-error outcomes with a deliverable or process commitment, keeping customer inputs, approval dependency and unknown timing visible."
+      - "Explains exception preview and customer approval as a credible reason to choose the service without claiming exclusive invention or proven elimination of errors."
+      - "Specifies included work and a bounded support proposal, marks new support/refund terms for owner approval, and avoids inventing a refund entitlement or publishing unlimited help."
+      - "Uses the synthetic-data demonstration as available product proof while separating private buyer insight and the unapproved client quote from publishable testimonials."
+      - "Removes the unsupported EUR 2,000 bonus valuation, avoids fabricated scarcity, and leaves no unresolved commercial term disguised as approved fact."
+      - "Delivers a concrete revised offer with evidence references and a small validation focused on a remaining decision, rather than stopping with generic questions or promising conversion lift."