@jairodri/huckleberry-cli 1.0.2 → 1.1.0

package/skills/context-recovery/SKILL.md

@@ -0,0 +1,198 @@
+---
+name: context-recovery
+description: Automatically recover working context after session compaction or context loss. Works across Discord, Slack, Telegram, and other channels.
+---
+
+slash_command: false
+name: context-recovery
+description: Automatically recover working context after session compaction or when continuation is implied but context is missing. Works across Discord, Slack, Telegram, Signal, and other supported channels.
+homepage: https://github.com/PSPDFKit-labs/agent-skills
+repository: https://github.com/PSPDFKit-labs/agent-skills
+metadata:
+ {
+ "openclaw":
+ "emoji": "",
+ },
+ }
+
+# Context Recovery
+Automatically recover working context after session compaction or when continuation is implied but context is missing. Works across Discord, Slack, Telegram, Signal, and other supported channels.
+
+**Use when**: Session starts with truncated context, user references prior work without specifying details, or compaction indicators appear.
+
+## Safety Boundaries
+- This skill prioritizes channel/session API history to recover context.
+- It does NOT perform broad filesystem scans or shell glob searches by default.
+- It does NOT send recovered context to external services.
+- It does NOT write to disk unless the user explicitly asks to persist recovered state.
+
+## Triggers
+
+### Automatic Triggers
+- Session begins with a `<summary>` tag (compaction detected)
+- User message contains compaction indicators: "Summary unavailable", "context limits", "truncated"
+
+### Manual Triggers
+- User says "continue", "did this happen?", "where were we?", "what was I working on?"
+- User references "the project", "the PR", "the branch", "the issue" without specifying which
+- User implies prior work exists but context is unclear
+- User asks "do you remember...?" or "we were working on..."
+
+## Execution Protocol
+
+### Step 1: Detect Active Channel
+Extract from runtime context:
+- `channel` — discord | slack | telegram | signal | etc.
+- `channelId` — the specific channel/conversation ID
+- `threadId` — for threaded conversations (Slack, Discord threads)
+
+### Step 2: Fetch Channel History (Adaptive Depth)
+**Initial fetch:**
+```
+message:read
+ channel: <detected-channel>
+ channelId: <detected-channel-id>
+ limit: 50
+
+**Adaptive expansion logic:**
+1. Parse timestamps from returned messages
+2. Calculate time span: `newest_timestamp - oldest_timestamp`
+3. If time span < 2 hours AND message count == limit:
+ - Fetch additional 50 messages (using `before` parameter if supported)
+ - Repeat until time span ≥ 2 hours OR total messages ≥ 100
+4. Hard cap: 100 messages maximum (token budget constraint)
+
+**Thread-aware recovery (Slack/Discord):**
+
+# If threadId is present, fetch thread messages first
+threadId: <thread-id>
+
+# Then fetch parent channel for broader context
+channelId: <parent-channel-id>
+ limit: 30
+
+**Parse for:**
+- Recent user requests (what was asked)
+- Recent assistant responses (what was done)
+- URLs, file paths, branch names, PR numbers
+- Incomplete actions (promises made but not fulfilled)
+- Project identifiers and working directories
+
+### Step 3: Fetch Session Context (safe mode)
+Use platform/session APIs only (no shell filesystem scans):
+
+```yaml
+
+# List recent sessions (if tool exists)
+sessions_list:
+ limit: 5
+
+# Pull last messages from likely matching session
+sessions_history:
+ sessionKey: <candidate-session-key>
+ limit: 80
+ includeTools: true
+
+If session APIs are unavailable, skip this step and proceed with channel-only evidence.
+
+### Step 4: Optional Memory Check (explicitly scoped)
+Only inspect memory if the agent runtime already provides a scoped memory tool/path.
+Do **not** run shell glob scans across home directories.
+
+### Step 5: Synthesize Context
+Compile a structured summary:
+
+```markdown
+
+## Recovered Context
+**Channel:** #<channel-name> (<platform>)
+**Time Range:** <oldest-message> to <newest-message>
+**Messages Analyzed:** <count>
+
+### Active Project/Task
+- **Repository:** <repo-name>
+- **Branch:** <branch-name>
+- **PR:** #<number> — <title>
+
+### Recent Work Timeline
+1. [<timestamp>] <action/request>
+2. [<timestamp>] <action/request>
+3. [<timestamp>] <action/request>
+
+### Pending/Incomplete Actions
+- ⏳ "<quoted incomplete action>"
+- ⏳ "<another incomplete item>"
+
+### Last User Request
+> "<quoted request that may not have been completed>"
+
+### Step 6: Optional Persistence (consent-first)
+Do not write to disk by default. If persistence is useful, ask first:
+
+> "I can cache this recovered context to memory for later continuity. Should I save it?"
+
+### Step 7: Respond with Context
+Present the recovered context, then prompt:
+
+> "Context recovered. Your last request was [X]. This action [completed/did not complete]. Shall I [continue/retry/clarify]?"
+
+## Channel-Specific Notes
+
+### Discord
+- Use `channelId` from the incoming message metadata
+- Guild channels have full history access
+- Thread recovery: check for `threadId` in message metadata
+- DMs may have limited history
+
+### Slack
+- Use `channel` parameter with Slack channel ID
+- Thread context requires `threadId` — always check for thread context first
+- Parent channel fetch provides surrounding conversation context
+- May need workspace-level permissions for full history
+
+### Telegram / Signal / Others
+- Same `message:read` interface
+- History depth may vary by platform
+- Group vs. DM context may differ
+
+## Constraints
+- Prefer this protocol before declaring "insufficient data" when context appears missing
+- Adaptive depth: start with 50, expand to 100 max
+- Time-based goal: capture at least 2 hours of context when possible
+- If recovery fails, state what was attempted and what data sources were unavailable
+- Avoid broad filesystem scans or writes without explicit user consent
+
+## Auto-Trigger Detection
+At session start, scan for compaction indicators:
+
+```python
+
+# Pseudocode for trigger detection
+if message contains "<summary>":
+ trigger_context_recovery()
+elif message contains any of ["Summary unavailable", "context limits", "truncated", "compacted"]:
+elif message matches continuation_patterns:
+ # "continue", "where were we", "did this happen", etc.
+
+**Do not wait for user to ask** — if compaction is detected, proactively recover and present context.
+
+## Example
+**Scenario:** Session starts with compaction summary
+
+User message: "<summary>Summary unavailable due to context limits...</summary>"
+User message: "did this happen?"
+
+**Agent executes:**
+1. Detects compaction via `<summary>` tag
+2. `message:read channel=discord channelId=1460342116516364533 limit=50`
+3. Calculates time span: 2.5 hours — sufficient, no expansion needed
+4. Parses messages, finds last action: "Now let me extract the key orchestration decisions..."
+5. Checks session context APIs — extracts recent user requests
+6. Responds:
+
+> "Context recovered. Your last request was to extract orchestration decisions from Nexus archived sessions for PR #137 (Skills & Agents System). This action did not complete before context was truncated.
+>
+> **Recovered state:**
+> - PR #137: 15,053 additions, 91 files, CONFLICTING merge state
+> - Spec location: `content/spec-skills-agents-system.md` (2,067 lines)
+> Shall I proceed with the extraction?"

package/skills/context-recovery/_meta.json

@@ -0,0 +1,6 @@
+{
+  "ownerId": "kn73ft5fmjrf1h9n78fc61tgfs7yp8ez",
+  "slug": "context-recovery",
+  "version": "1.2.2",
+  "publishedAt": 1772258477063
+}

package/skills/conversion-flow-cro/SKILL.md

@@ -0,0 +1,248 @@
+---
+name: conversion-flow-cro
+description: "Optimizes multi-step conversion flows including signup, onboarding, upgrade, and checkout. Maps each step, identifies friction and drop-off risks,..."
+allowed-tools: []
+---
+
+# Conversion Flow CRO
+
+## Purpose
+
+Audit and optimize any multi-step conversion flow — signup, onboarding, trial-to-paid, checkout, upgrade. Map every step, find where people drop off, and fix each screen with specific copy and UX changes.
+
+## Reads
+
+- `brand/audience.md` — Personas, pain points, motivation levels at each stage
+- `brand/positioning.md` — Value props for reinforcement copy at each step
+- `brand/voice-profile.md` — Brand voice for all copy suggestions
+
+## Brand Integration
+
+- **audience.md** — Persona determines friction tolerance. A developer persona accepts more setup steps; a non-technical buyer needs fewer. Pain points inform which value reminders to show at each step.
+- **positioning.md** — Value proposition reinforcement copy at each step should echo the positioning angle. If the brand positions on "saves time," every motivation booster references time savings.
+- **voice-profile.md** — All redesigned copy (headlines, CTAs, supporting text) must match brand voice. A casual brand writes "Almost there!" while a professional brand writes "One final step."
+
+## Workflow
+
+### Step 1: Map the Current Flow
+
+Get the flow information. Try these in order:
+1. **User provides screenshots or screen recordings** — Best source, map directly
+2. **Read the codebase** — If accessible, find route files, page components, and form definitions
+3. **User walks through the flow verbally** — Accept but flag that recommendations will be more accurate with actual screens
+4. **Use browser tool on live URL** — Walk through the flow step by step
+
+If the flow is partially provided (only some screens), audit what's available and note which steps need investigation.
+
+Document every screen/step in the flow:
+
+```
+Flow: [Signup / Onboarding / Upgrade / Checkout]
+
+Step 1: [Page/Screen name]
+- URL/Route: [path]
+- Fields/Actions: [what user must do]
+- Copy: [headline, body, CTA]
+- Friction points: [identified issues]
+
+Step 2: [Next screen]
+...
+
+Total steps: [N]
+Total required fields: [N]
+Total decisions: [N]
+Estimated completion time: [X minutes]
+```
+
+### Step 2: Identify Drop-Off Points
+
+For each step, assess drop-off risk:
+
+| Risk Factor | Score 1-5 | Notes |
+|------------|-----------|-------|
+| Too many fields | | More than 3 per step = high risk |
+| Unclear value | | User doesn't know why this step matters |
+| Unexpected ask | | Requesting info that feels premature |
+| No progress signal | | User doesn't know how far along they are |
+| Decision fatigue | | Too many choices without guidance |
+| Trust gap | | Asking for sensitive info without context |
+| Technical friction | | Slow load, validation errors, mobile issues |
+
+### Step 3: Apply Friction Reduction
+
+For each step, apply these principles:
+
+#### Progressive Disclosure
+- Ask for minimum info at each step
+- Defer optional fields to later (post-signup settings)
+- Start with the easiest, most natural question
+- Example: Email only -> Name -> Company -> Role (not all at once)
+
+#### Single-Field Starts
+- First interaction should be ONE field or ONE click
+- "Enter your email to get started" > 5-field signup form
+- Google/GitHub OAuth as primary option, email form as secondary
+
+#### Smart Defaults
+- Pre-select the most common option
+- Use detection (timezone, language, company size from email domain)
+- Show recommended plan with visual emphasis
+
+#### Motivation Maintenance
+- Show progress (Step 2 of 4)
+- Remind of value at each step ("You're 1 step away from [outcome]")
+- Use micro-commitments (each step delivers a small win)
+- Show social proof inline ("12,000 teams completed this step today")
+
+#### Social Proof Injection Points
+- Before payment: "Join [X] companies already using [Product]"
+- During onboarding: "[Role] at [Company] set this up in 3 minutes"
+- At upgrade prompt: "[X]% of free users upgrade within [Y] days"
+
+#### Urgency Without Sleaze
+- Real deadlines: "Trial ends in 7 days" (if true)
+- Opportunity cost: "Teams using [feature] save [X] hours/week"
+- Progress anchoring: "You've already set up [X] — unlock [Y] to get full value"
+- Never: fake countdown timers, "only 2 left", manufactured scarcity
+
+### Step 4: Redesign Each Step
+
+For every step in the flow, output:
+
+```markdown
+### Step [N]: [Name]
+
+**Current State:**
+- Headline: "[current]"
+- Fields: [list]
+- CTA: "[current]"
+- Issues: [specific problems]
+
+**Redesigned:**
+- Headline: "[new — ties to value]"
+- Fields: [reduced/reordered list]
+- CTA: "[new — action + outcome]"
+- Supporting copy: "[anxiety reducer or motivation booster]"
+- Social proof: "[inline proof element]"
+
+**Changes Made:**
+1. [Specific change + reasoning]
+2. [Specific change + reasoning]
+
+**Expected Impact:** [Drop-off reduction estimate]
+```
+
+### Step 5: A/B Test Suggestions
+
+For each high-impact change, define a test:
+
+```markdown
+## A/B Test: [Test Name]
+
+**Hypothesis:** Changing [element] from [A] to [B] will increase [metric] by [X]% because [reasoning].
+
+**Control:** [Current version]
+**Variant:** [New version]
+**Primary metric:** [Conversion rate at this step]
+**Secondary metric:** [Overall flow completion rate]
+**Sample size needed:** [Estimate based on current traffic]
+**Duration:** [Minimum 2 weeks or X conversions]
+```
+
+## Flow-Specific Patterns
+
+### Signup Flow
+- Goal: Minimize time-to-value
+- Ideal: 1-2 steps max before product access
+- Pattern: Email -> Magic link -> Product (skip password creation)
+- Anti-pattern: Email -> Password -> Verify email -> Profile -> Team -> Product
+
+### Onboarding Flow
+- Goal: Reach "aha moment" fast
+- Ideal: 3-5 steps, each delivering visible value
+- Pattern: Welcome -> Import data OR use template -> See first result -> Invite team
+- Anti-pattern: Long feature tour -> Settings configuration -> Empty state
+
+### Trial-to-Paid Flow
+- Goal: Demonstrate value before asking for money
+- Ideal: Usage triggers upgrade prompt, not calendar
+- Pattern: Hit feature limit -> See what you'd unlock -> One-click upgrade
+- Anti-pattern: Day 13 email -> Pricing page -> Checkout -> Success
+
+### Checkout Flow
+- Goal: Reduce payment anxiety
+- Ideal: 1-2 steps with full transparency
+- Pattern: Plan summary -> Payment (with guarantees visible) -> Confirmation
+- Anti-pattern: Plan -> Billing info -> Review -> Confirm -> Upsell -> Success
+
+## Worked Example
+
+**Before:** 8-step signup requiring name, email, password, company, role, team size, use case, phone
+**After:** 3-step progressive flow:
+1. Email only → instant access to limited features
+2. After first value moment → ask name + role (contextualized: 'Help us personalize your experience')
+3. After 3 sessions → ask company + team size (gated behind upgrade)
+
+**Expected impact:** 40-60% improvement in signup completion rate. Progressive disclosure works because each ask feels justified by the value already delivered.
+
+## Copy Templates Per Step
+
+### First Touch (Signup)
+- "Get started free — no credit card required"
+- "Create your [product] in 60 seconds"
+- "Join [X] [role]s already using [Product]"
+
+### Mid-Flow (Onboarding Step)
+- "Nice — you're [X]% set up"
+- "Most [role]s complete this in under 2 minutes"
+- "This step unlocks [specific feature/outcome]"
+
+### Commitment Point (Payment/Upgrade)
+- "You've already [achievement] — unlock [next level]"
+- "Plans start at $[X]/mo. Cancel anytime."
+- "[X]-day money-back guarantee. No questions asked."
+
+### Completion
+- "You're all set. Here's what to do first:"
+- "[Product] is ready. Your first [outcome] is [X] away."
+
+See `references/flow-benchmarks.md` for completion rate benchmarks by flow type, step-by-step drop-off patterns, mobile-specific data, and A/B test priorities. Use these to ground recommendations in real numbers.
+
+## Output
+
+Each flow audit produces:
+- Visual flow map (current state with step count, fields, decisions)
+- Drop-off risk assessment per step
+- Redesigned copy and UX for each step
+- Prioritized A/B test suggestions
+- Before/after comparison of total flow friction score
+- Implementation checklist ordered by impact
+
+## Anti-Patterns
+
+- Don't remove security steps (2FA, email verification) — flag them as necessary friction and suggest making them smoother, not removing them
+- Don't skip legally required fields (KYC, age verification, GDPR consent) — these stay; optimize their placement and copy instead
+- Don't simplify past compliance requirements — if a step exists for legal reasons, note it and move on
+- Don't suggest removing steps without understanding the business logic behind them — ask first
+- Don't use fake urgency (countdown timers, "only 2 left") — the "Urgency Without Sleaze" principles apply
+- Don't optimize for signup completion at the expense of user quality — vanity signups that never activate are worse than fewer, engaged signups
+
+## Edge Cases
+
+- **Partial flow information:** Audit available steps, clearly flag gaps, and ask the user for the missing screens before finalizing recommendations.
+- **Mobile vs. desktop divergence:** If the flow differs by platform, audit both. Mobile-specific issues: tap targets, keyboard types for input fields, thumb-zone CTA placement.
+- **Legally required steps:** Mark as "required — optimize, don't remove." Focus copy and UX improvements within the constraint.
+- **Enterprise/B2B flows:** Longer flows are acceptable when the buyer expects a consultative process. Don't force a consumer-style 2-step signup on an enterprise product.
+
+## Quality Checks
+
+- [ ] Total steps reduced or justified
+- [ ] Every field has a clear reason to exist at that step
+- [ ] Progress indicator present throughout
+- [ ] Value reminder at each step
+- [ ] Social proof placed at high-anxiety moments
+- [ ] CTA copy is action + outcome, not generic
+- [ ] Mobile experience considered for every step
+- [ ] Error states are helpful, not punishing
+- [ ] Security and compliance steps preserved (not removed)
+- [ ] Copy rewrites match brand voice (if voice-profile.md exists)

package/skills/conversion-flow-cro/references/flow-benchmarks.md

@@ -0,0 +1,158 @@
+# Flow Conversion Benchmarks & Patterns
+
+Completion rates, drop-off patterns, and optimization benchmarks for multi-step conversion flows.
+
+---
+
+## Flow Completion Rates by Type
+
+### Signup Flows
+
+| Flow Length | Typical Completion Rate | Notes |
+|-------------|----------------------|-------|
+| 1 step (email only) | 40-60% | Highest completion, lowest data capture |
+| 2 steps (email + password) | 30-45% | Standard for most SaaS |
+| 3 steps (email + profile + preferences) | 20-35% | Acceptable if each step shows value |
+| 4+ steps | <20% | High risk — justify every step |
+
+**Social login impact:** Adding Google/GitHub OAuth as primary option typically increases signup completion by 20-40% — it removes the password creation step entirely.
+
+**Magic link vs. password:** Magic link signup (email only, click to verify) achieves 15-25% higher completion than email + password, because it eliminates the "create a secure password" friction point.
+
+### Onboarding Flows
+
+| Metric | Poor | Average | Good | Excellent |
+|--------|------|---------|------|-----------|
+| Completion rate | <30% | 30-50% | 50-70% | >70% |
+| Time to complete | >10 min | 5-10 min | 3-5 min | <3 min |
+| Steps to "aha moment" | 7+ | 5-6 | 3-4 | 1-2 |
+
+**Onboarding patterns that work:**
+- Template-first: Show a populated template, let user customize (Notion, Airtable)
+- Quick win: Get the user to their first success in <2 minutes (Canva, Figma)
+- Progressive: Ask for info only when the product needs it, not all upfront (Slack)
+
+**Onboarding patterns that fail:**
+- Feature tour: Showing every feature before the user can use any of them
+- Empty state: Dropping the user into a blank workspace with no guidance
+- Settings-first: Making the user configure preferences before seeing value
+
+### Trial-to-Paid Flows
+
+| Metric | Below Average | Average | Good | Best-in-Class |
+|--------|--------------|---------|------|---------------|
+| Trial-to-paid conversion | <5% | 5-15% | 15-25% | >25% |
+| Opt-in trial (no card upfront) | 2-8% | 8-15% | 15-20% | >20% |
+| Opt-out trial (card required upfront) | 25-40% | 40-55% | 55-70% | >70% |
+
+**Opt-in vs. opt-out tradeoff:** Requiring a credit card at signup reduces trial signups by 50-70% but increases trial-to-paid conversion 3-5x. The right choice depends on whether your bottleneck is top-of-funnel volume or activation quality.
+
+**Usage-triggered upgrades vs. calendar-based:**
+- Usage-triggered ("You've hit your 5-project limit") converts 2-3x higher than calendar-triggered ("Your trial expires tomorrow")
+- The user is more motivated to pay when they've experienced the value limit, not an arbitrary deadline
+
+### Checkout Flows
+
+| Flow Length | Typical Completion Rate |
+|-------------|----------------------|
+| 1-page checkout | 55-65% |
+| 2-step checkout | 45-55% |
+| 3+ step checkout | 30-45% |
+
+**Cart abandonment benchmarks:** ~70% of e-commerce carts are abandoned. For SaaS checkout, ~40-60% abandon at the payment page.
+
+**Top checkout abandonment reasons:**
+1. Extra costs (shipping, tax, fees) — 48%
+2. Account creation required — 24%
+3. Too long/complicated — 17%
+4. Couldn't calculate total cost upfront — 16%
+5. Didn't trust site with card info — 13%
+
+---
+
+## Step-by-Step Drop-Off Patterns
+
+### Where People Drop Off Most
+
+| Drop-Off Point | Why | Fix |
+|----------------|-----|-----|
+| First form field | Commitment anxiety — the first field is the hardest | Start with the easiest, lowest-friction field (email) |
+| Password creation | Users hate creating passwords | Use magic links, social login, or passwordless |
+| Payment info request | Trust gap — why do you need my card? | Show security badges, guarantee, explain clearly |
+| Profile completion | "Why do you need this?" feeling | Explain the benefit of each field inline |
+| Email verification | Leaves the flow (checks email, gets distracted) | Use magic links that auto-verify, or defer verification |
+
+### The "Step 2 Cliff"
+
+The biggest drop-off in any multi-step flow is between step 1 and step 2. After step 2, completion rates stabilize because the commitment-consistency bias kicks in — users who've invested effort are more likely to continue.
+
+**Implication:** Make step 1 as frictionless as possible (single field, single click). The goal of step 1 is just to get the user to step 2. Once they're past step 2, the flow's gravity carries them forward.
+
+---
+
+## Progress Indicator Benchmarks
+
+| Type | Impact |
+|------|--------|
+| Step numbers ("Step 2 of 4") | +10-15% completion |
+| Progress bar (visual fill) | +15-20% completion |
+| Percentage ("75% complete") | +10-15% completion |
+| Checklist style | +20-25% completion |
+| No progress indicator | Baseline |
+
+**Checklist-style progress** performs best because it creates a visible "to-do list" effect — the Zeigarnik effect makes people want to complete incomplete tasks. Show what's done (checked) and what's left (unchecked).
+
+---
+
+## Mobile Flow Benchmarks
+
+| Metric | Desktop | Mobile | Gap |
+|--------|---------|--------|-----|
+| Flow completion rate | 45-55% | 25-35% | -20pp |
+| Avg. time per step | 15-20s | 25-35s | +50-75% |
+| Form abandonment | 25-35% | 40-55% | +15-20pp |
+| Payment completion | 55-65% | 35-45% | -20pp |
+
+**Mobile-specific optimizations:**
+- Use number keyboards for phone/zip fields (inputmode="numeric")
+- Larger tap targets (min 44x44px, ideally 48x48px)
+- Autofill support for address and payment fields
+- Sticky CTA buttons that stay visible during scroll
+- Avoid dropdowns — use segmented controls or radio buttons for <5 options
+
+---
+
+## Social Proof Placement in Flows
+
+| Placement | Impact | Best For |
+|-----------|--------|----------|
+| Before signup form | +10-20% signup rate | Building initial trust |
+| During onboarding | +5-10% completion | Keeping momentum ("X people completed this step today") |
+| Before payment | +15-25% payment rate | Reducing purchase anxiety |
+| After trial expiry warning | +10-15% conversion | Reinforcing value during pressure |
+
+**Context-specific proof works better than generic:** "Teams like yours" > "12,000 teams" > "Lots of people." The more specific to the user's situation, the more persuasive.
+
+---
+
+## A/B Test Priorities for Flows
+
+Priority order by typical impact on flow completion:
+1. **Reduce step count** — removing one step typically lifts completion 10-20%
+2. **Add social login / magic link** — 20-40% lift on signup specifically
+3. **Add progress indicator** — 10-25% lift across all flow types
+4. **Rewrite step headlines** — 5-15% lift (value reminder at each step)
+5. **Reduce fields per step** — 5-10% lift per field removed
+6. **Add inline social proof** — 5-10% lift at high-anxiety steps
+7. **Improve error handling** — 5-10% recovery (users who hit errors are 2x more likely to abandon)
+
+---
+
+## Using These Benchmarks
+
+When auditing a flow:
+- Compare current completion rates against the relevant flow type benchmarks
+- Identify where the flow falls below average — those are the optimization targets
+- Use the impact ranges to estimate expected lift from each recommendation
+- Reference the "why" behind each benchmark so the user understands the psychology, not just the number
+- Acknowledge that these are industry medians — specific results vary by product, audience, and traffic quality