mirror of
https://github.com/OneWave-AI/claude-skills.git
synced 2026-09-14 15:58:36 +08:00
Add 10 skills: persona panels, HyperFrames sales/marketing video, Claude design (#5)
* Add 10 skills: persona panels, HyperFrames sales/marketing video, Claude design Persona/panel engine: - icp-deep-scanner: read-only deep scan of connected tools -> grounded ICP + persona library - customer-panel-of-experts: personas debate any decision (launch/price/product) - prospect-panel-simulator: simulate prospects to pressure-test outbound + messaging - product-launch-war-room: adversarial GTM go/no-go + phased rollout + kill criteria - pricing-change-strategist: price-increase rollout, scenarios, grandfathering, comms kit HyperFrames sales/marketing video: - hyperframes-ad-director: brief -> finished video ad (hook, script, storyboard, cuts) - hyperframes-sales-demo-builder: personalized per-account product-demo videos Claude design: - claude-design-system-architect: premium tokens -> Tailwind/CSS + usage doc - claude-landing-composer: premium animated landing pages, anti-template - claude-design-critic: de-AI a UI (design + copy), prioritized fixes All read-only by default, env-var secrets, PII-minimizing, config placeholders. README count 162 -> 172 with category rows. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Modernize landing-composer stack reference (Motion / Tailwind v4 / App Router) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Gabe Keding
@@ -2,7 +2,7 @@
|
||||
|
||||
Production-ready skills for Claude Code. Built and maintained by [OneWave AI](https://www.onewave-ai.com) -- AI consulting for small and mid-size businesses.
|
||||
|
||||
**162 skills** across business operations, sales, engineering, consulting, and AI agent architecture.
|
||||
**172 skills** across business operations, sales, engineering, consulting, and AI agent architecture.
|
||||
|
||||
---
|
||||
|
||||
@@ -57,6 +57,9 @@ Skills built around specific Anthropic product releases.
|
||||
| `cowork-deal-room` | Cowork-style multi-step deal room document analysis |
|
||||
| `gmail-to-crm-pipeline` | MCP Connectors: Gmail to CRM lead qualification pipeline |
|
||||
| `full-codebase-migrator` | 1M context window: ingest entire codebases for migration planning |
|
||||
| `claude-design-system-architect` | Generate a premium design system (tokens, type, motion) exported to Tailwind/CSS |
|
||||
| `claude-landing-composer` | Build premium animated landing pages in Next.js + Framer Motion, anti-template |
|
||||
| `claude-design-critic` | Audit a UI and de-AI it — design + copy fixes toward editorial/premium |
|
||||
|
||||
### Sales and Revenue
|
||||
| Skill | Description |
|
||||
@@ -84,6 +87,10 @@ Skills built around specific Anthropic product releases.
|
||||
| `ramping-rep-tracker` | 30/60/90/120 day ramp milestones |
|
||||
| `rep-performance-scorecard` | Multi-dimensional rep evaluation |
|
||||
| `territory-planning-optimizer` | Account assignment by revenue potential |
|
||||
| `icp-deep-scanner` | Read-only deep scan of connected tools → data-grounded ICP + persona library |
|
||||
| `customer-panel-of-experts` | Your buyer personas debate any decision (launch, price, product) and recommend |
|
||||
| `prospect-panel-simulator` | Simulate prospects to pressure-test emails, decks, and pages before sending |
|
||||
| `pricing-change-strategist` | Plan a price increase: segmentation, scenarios, grandfathering, full comms kit |
|
||||
|
||||
### Consulting and Professional Services
|
||||
| Skill | Description |
|
||||
@@ -157,6 +164,9 @@ Skills built around specific Anthropic product releases.
|
||||
| `webinar-content-repurposer` | Webinar to blog, social, email |
|
||||
| `email-template-generator` | Professional email templates |
|
||||
| `email-subject-line-optimizer` | A/B test subject lines |
|
||||
| `product-launch-war-room` | Adversarial GTM war room: go/no-go, risk register, phased rollout, kill criteria |
|
||||
| `hyperframes-ad-director` | Brief → finished HyperFrames video ad: hook, script, storyboard, scenes, cuts |
|
||||
| `hyperframes-sales-demo-builder` | Personalized product-demo videos in HyperFrames for a specific account |
|
||||
|
||||
### Strategy and Finance
|
||||
| Skill | Description |
|
||||
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
name: claude-design-critic
|
||||
description: Audit a website or UI and de-AI it — find the patterns that make it look template-generated (in both design and copy) and return specific, prioritized fixes that push it toward editorial, premium, human-crafted. Reviews layout, color, type, spacing, motion, accessibility, AND the words. Use after building or generating any frontend, or when a site looks "fine but generic" and you can't say why.
|
||||
tools: Read, Write, Bash, Glob, Grep, WebSearch, WebFetch, Agent
|
||||
model: inherit
|
||||
---
|
||||
|
||||
# Claude Design Critic
|
||||
|
||||
Some sites are technically fine and still scream "an AI made this in one shot." This skill names exactly why and tells you what to change. It reviews the design *and* the copy, because generated-looking text gives a build away as fast as a centered hero and a purple gradient.
|
||||
|
||||
Use it as the finishing pass on `claude-landing-composer` output, on any vibe-coded frontend, or on a live site that feels generic. It pairs with the design tokens from `claude-design-system-architect` (audit against them when they exist).
|
||||
|
||||
## Step 1 — Take in the target
|
||||
|
||||
A URL (WebFetch + screenshot), a local project (read the components/styles), or pasted code. Establish: what is this page for, who's the audience, and what's the one action it wants? A critique without the goal is just opinion.
|
||||
|
||||
## Step 2 — Audit across dimensions
|
||||
|
||||
Go dimension by dimension and flag concrete instances, not vibes:
|
||||
|
||||
**Layout & composition**
|
||||
- Every section a centered stack? Three-identical-cards reflex? Predictable hero → cards → CTA with no rhythm? Symmetry where asymmetry would feel crafted? Cramped or uniform whitespace?
|
||||
|
||||
**Color**
|
||||
- Purple or default-AI gradients (the dead giveaway). Too many competing accents. Off-brand or arbitrary hexes not mapped to tokens. Contrast failures (check AA).
|
||||
|
||||
**Type**
|
||||
- Default system sans at 2–3 sizes. No real modular scale. Weak hierarchy. Generic pairing. Line length / line-height that reads like a default.
|
||||
|
||||
**Spacing & detail**
|
||||
- Uniform padding everywhere. No optical adjustments. Borders/shadows that are all identical or all heavy.
|
||||
|
||||
**Motion**
|
||||
- The same fade-up on every element. Motion that decorates instead of directs. `prefers-reduced-motion` ignored.
|
||||
|
||||
**Iconography & assets**
|
||||
- Emoji used as UI (replace with Lucide/Heroicons). Generic stock imagery. Placeholder logos left in.
|
||||
|
||||
**Copy (review this as hard as the design)**
|
||||
- AI tells: "elevate", "unlock", "seamless", "empower", "in today's fast-paced world", "we're thrilled to", "the power of", relentless em-dashes, every sentence a tricolon.
|
||||
- Generic value props ("the best way to X"), hedged language, "Learn More" buttons, "Welcome to {Product}" heroes, filler microcopy.
|
||||
- Flag the exact lines and rewrite the worst offenders.
|
||||
|
||||
**Accessibility & semantics**
|
||||
- Heading order, alt text, focus states, semantic landmarks, tap-target sizes.
|
||||
|
||||
## Step 3 — Report with prioritized, specific fixes
|
||||
|
||||
```markdown
|
||||
# Design Critique — {target}
|
||||
Generated: {timestamp} · Goal: {…} · Verdict: {SHIP / FIX FIRST / REBUILD SECTION}
|
||||
|
||||
## The 30-second read
|
||||
The 2–3 things making this look generated, in plain language.
|
||||
|
||||
## Findings (prioritized: High → Low)
|
||||
| # | Dimension | What | Where (selector/line/section) | Why it reads as AI | Fix |
|
||||
|
||||
## Copy rewrites
|
||||
"{exact current line}" → "{rewritten line}"
|
||||
|
||||
## Quick wins (under 30 min, high impact)
|
||||
## Bigger moves (worth the time)
|
||||
## What's already good (keep it)
|
||||
```
|
||||
|
||||
Be specific enough that someone could apply every fix without asking a question. Point to the file/section/line. Where tokens exist, cite the token that should have been used.
|
||||
|
||||
## Step 4 — Offer to apply
|
||||
Offer to implement the high-priority fixes directly (edit the components/copy) and re-audit, or hand a rebuild to `claude-landing-composer`.
|
||||
|
||||
## House standard
|
||||
Premium = intentional layout rhythm, restrained palette, real type scale, generous whitespace, motion with purpose, human copy. Generated = centered everything, rainbow/purple gradients, default sans, uniform padding, fade-up-on-all, and "elevate your workflow." Push every target from the second toward the first. Never purple, never emoji-as-UI.
|
||||
|
||||
## Guardrails recap
|
||||
Critique design AND copy · every finding is specific and located · cite tokens where they exist · prioritize by impact · offer to apply, then re-audit.
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
name: claude-design-system-architect
|
||||
description: Generate a complete, premium design system from a brand brief or an existing site — color tokens, type scale, spacing/radius/elevation, motion language, and component specs — exported as Tailwind config, CSS variables, and a usage doc. Built to look editorial and human-crafted, not template-generated. Use when starting a new product/site, unifying an inconsistent UI, or codifying a brand into reusable tokens.
|
||||
tools: Read, Write, Bash, Glob, Grep, WebSearch, WebFetch, Agent
|
||||
model: inherit
|
||||
---
|
||||
|
||||
# Claude Design System Architect
|
||||
|
||||
A design system is the difference between a site that looks bespoke and one that looks like every other AI-generated landing page. This skill builds the token layer and component language that makes everything downstream look intentional — then exports it in the formats your stack actually uses.
|
||||
|
||||
Pairs with `claude-landing-composer` (which consumes these tokens to build pages) and `claude-design-critic` (which audits against them).
|
||||
|
||||
## Step 1 — Establish the brand inputs
|
||||
|
||||
From a brief, an existing site (WebFetch / screenshots), or a few reference sites the user likes:
|
||||
- **Personality** — 3–5 adjectives (e.g. "warm, editorial, confident, calm"). These drive every later decision.
|
||||
- **Audience & context** — who uses it, on what device, in what mood.
|
||||
- **Existing equity** — logo, locked colors, fonts already in use.
|
||||
- **Anti-references** — what it must NOT look like.
|
||||
|
||||
### Defaults & house rules
|
||||
Unless the brand explicitly overrides:
|
||||
- **No purple** anywhere in the palette.
|
||||
- **No emoji** in UI — use an icon set (Lucide / Heroicons) and specify it as a token.
|
||||
- Lean toward **warm / earth tones** (sand, terracotta, clay) and consider a **dark surface** option.
|
||||
- Motion is part of the system, not an afterthought.
|
||||
|
||||
## Step 2 — Build the tokens
|
||||
|
||||
Design each layer deliberately and document the *why*:
|
||||
- **Color** — a real ramp (50–900) per hue, semantic tokens (`surface`, `text`, `muted`, `accent`, `border`, `success`/`warn`/`danger`), and verified contrast (WCAG AA min for body text). Include a dark mode set. No arbitrary hexes scattered later — everything maps to a token.
|
||||
- **Type** — a font pairing with rationale, a modular scale (not random px), line-heights and tracking per size, and weights. Prefer characterful, legible pairings over the default system stack that screams "AI made this."
|
||||
- **Space & layout** — a spacing scale, container widths, grid, breakpoints. Generous, asymmetric whitespace reads premium; cramped uniform padding reads generated.
|
||||
- **Radius / border / elevation** — a small, consistent set. Shadows that match the brand's weight (soft for warm brands, crisp for technical ones).
|
||||
- **Motion** — duration + easing tokens, named patterns (entrance, emphasis, transition), and a reduced-motion stance. This is what makes it feel alive.
|
||||
|
||||
## Step 3 — Specify components
|
||||
|
||||
For the core set (button, input, card, nav, section, badge, modal), specify variants, states (hover/focus/active/disabled), sizing, and accessibility notes — all expressed in the tokens above, never one-off values.
|
||||
|
||||
## Step 4 — Export
|
||||
|
||||
Produce real files, not prose:
|
||||
- `tailwind.config` extension (or `@theme` for Tailwind v4) wiring every token.
|
||||
- `tokens.css` — CSS custom properties (light + dark).
|
||||
- `design-system.md` — the usage doc: palette with hexes + contrast, type scale, spacing, motion, component specs, and **do/don't** examples that call out the AI-tell patterns to avoid.
|
||||
|
||||
## Step 5 — Hand off
|
||||
End with a one-screen summary and the next move: `claude-landing-composer` to build pages on these tokens, or `claude-design-critic` to retrofit an existing UI onto them.
|
||||
|
||||
## What separates premium from generated (bake this in)
|
||||
- Intentional, restrained palette — not 6 competing accent colors.
|
||||
- A real type scale and characterful fonts — not default sans at 3 sizes.
|
||||
- Asymmetric, generous whitespace — not uniform padding everywhere.
|
||||
- Motion with personality — not the same fade-up on every element.
|
||||
- One confident accent — not rainbow gradients (and never purple-by-default).
|
||||
|
||||
## Guardrails recap
|
||||
Every value is a token, nothing arbitrary · contrast meets AA · dark mode + reduced-motion included · no purple / no emoji unless the brand demands it · export real config files, not descriptions.
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
name: claude-landing-composer
|
||||
description: Compose a premium, animated landing page section by section in Next.js + Tailwind + Motion (Framer Motion) — built on a real design system, with editorial copy and motion that feels human-crafted, not template-generated. Use when building or rebuilding a landing page, marketing site, or hero/feature/pricing/CTA sections that need to look production-ready and bespoke from day one.
|
||||
tools: Read, Write, Bash, Glob, Grep, WebSearch, WebFetch, Agent
|
||||
model: inherit
|
||||
---
|
||||
|
||||
# Claude Landing Composer
|
||||
|
||||
Most AI-built landing pages are instantly recognizable: centered hero, three feature cards, a gradient, generic copy. This skill builds pages that don't read as generated — editorial layout, real design tokens, motion with intent, and copy that sounds like a person wrote it.
|
||||
|
||||
Build on a design system from `claude-design-system-architect` when one exists. Run the result through `claude-design-critic` before shipping.
|
||||
|
||||
## Step 1 — Plan the page
|
||||
|
||||
- **Goal & one action** — what the page must get the visitor to do.
|
||||
- **Audience** — pull a buyer persona from `icp-deep-scanner` if available so the copy speaks to a real reader.
|
||||
- **Sections** — choose the minimum that earns the goal (hero → proof → how/why → objection-handling → pricing → CTA). Cut anything that doesn't move the visitor forward.
|
||||
- **Tokens** — load the design system. If none exists, generate one first (`claude-design-system-architect`); do not hardcode arbitrary colors/sizes.
|
||||
|
||||
### Stack & house rules
|
||||
Next.js (App Router) + React + TypeScript + Tailwind v4 + Motion (the library formerly published as Framer Motion) — the default stack. **No purple. No emoji** — use Lucide/Heroicons. Warm/earth tones and dark surfaces welcome. Motion is expected — typewriter, animated counters, spring/stagger reveals — used with restraint.
|
||||
|
||||
## Step 2 — Compose section by section
|
||||
|
||||
Build each section as a real component using tokens. For each, decide layout, content, and motion deliberately:
|
||||
- **Hero** — a sharp headline (not "Welcome to {Product}"), a sub that states the actual value, one primary CTA. Consider an asymmetric or editorial layout over the default dead-center stack.
|
||||
- **Proof** — logos, a real metric, or a specific outcome — not "trusted by thousands."
|
||||
- **Feature/why** — show the value in context; avoid the three-identical-cards reflex unless it genuinely fits. Vary rhythm and alignment between sections.
|
||||
- **Objection handling / FAQ** — answer the real hesitation a prospect has.
|
||||
- **Pricing** (if needed) — clear, confident, value-anchored.
|
||||
- **CTA** — one action, restated.
|
||||
|
||||
**Motion:** entrance reveals on scroll, but vary them — not the identical fade-up on every block. Respect `prefers-reduced-motion`. Motion should guide the eye to what matters, not decorate everything equally.
|
||||
|
||||
## Step 3 — Write copy that isn't AI-flavored
|
||||
|
||||
- Cut the tells: "elevate", "unlock", "seamless", "in today's fast-paced world", "we're thrilled", em-dash-everything, tricolon-everything.
|
||||
- Specific > generic. Confident > hedged. Short > padded.
|
||||
- Match the user's voice: direct, no corporate fluff.
|
||||
- Write real microcopy (buttons, empty states, captions) — not "Learn More" everywhere.
|
||||
|
||||
## Step 4 — Build it real
|
||||
Write the components, wire the tokens, ensure it's responsive (mobile-first, real breakpoints) and accessible (semantic HTML, focus states, alt text, AA contrast). Run the dev server / build and confirm it compiles before claiming it works.
|
||||
|
||||
## Step 5 — Critique pass (mandatory)
|
||||
Run `claude-design-critic` (or the anti-ai-frontend review) on the output to strip any remaining generated-looking patterns in both design and copy. Then deliver with the file paths and a short note on the choices made.
|
||||
|
||||
## The anti-generated checklist (apply before shipping)
|
||||
- Layout varies between sections; not every section is a centered stack.
|
||||
- Whitespace is generous and intentional, not uniform.
|
||||
- One confident accent; no rainbow gradients; never default-purple.
|
||||
- Headlines are specific and human; no filler value-props.
|
||||
- Motion has variety and restraint; reduced-motion respected.
|
||||
- Icons, never emoji. Real microcopy, never "Learn More" x5.
|
||||
|
||||
## Guardrails recap
|
||||
Build on real tokens, never arbitrary values · responsive + accessible + AA contrast · no purple / no emoji · compile/run before claiming done · always finish with a de-AI critique pass.
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: customer-panel-of-experts
|
||||
description: Build a panel of your real buyer personas (from a deep scan of any tools you allow it to connect to) and have them debate any decision you bring — a marketing launch, a price increase, a new product, a positioning change, a feature cut. Returns a structured debate, the strongest objections, and a clear recommendation. Use when you want your actual customers in the room before you commit.
|
||||
tools: Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, Agent
|
||||
model: inherit
|
||||
---
|
||||
|
||||
# Customer Panel of Experts
|
||||
|
||||
Put your customers in the room before you spend money or burn trust. This skill assembles a panel of data-grounded buyer personas and runs a real debate on whatever you're deciding — then hands you the decision, the dissent, and what to test next.
|
||||
|
||||
It is the flagship of the panel family. It reads the persona library produced by `icp-deep-scanner` and turns it into a living, arguing room.
|
||||
|
||||
## When to use it
|
||||
- "Should we raise prices 20%?" — and what each segment will actually do.
|
||||
- "Here's the launch campaign for {product}. Will it land?"
|
||||
- "We're killing {feature} and adding {feature}. Who revolts?"
|
||||
- "Pick between positioning A and positioning B."
|
||||
- Any high-stakes call where you'd normally guess what customers think.
|
||||
|
||||
## Step 0 — Get the personas
|
||||
|
||||
The panel is only as good as its members. In order of preference:
|
||||
1. **Use an existing persona library.** Look for `personas/` and `icp-profile.md` (output of `icp-deep-scanner`). Load every persona file and `personas/index.md`.
|
||||
2. **Generate one now.** If none exists and the user has connected tools, run `icp-deep-scanner` first (read-only) to build it from real data.
|
||||
3. **Bootstrap from input.** If there's no data and no time, build 3–5 provisional personas from what the user tells you — and label the entire session **"PROVISIONAL — not grounded in customer data"** at the top and bottom. Never let a guessed panel masquerade as a researched one.
|
||||
|
||||
### Data & security rules
|
||||
- Connecting tools is **read-only**. Never write to, send from, or modify a connected source. Confirm before any exception.
|
||||
- Personas are archetypes. Do not surface real customer names/emails/account IDs in the debate. Quotes must be scrubbed.
|
||||
- Secrets stay in env vars / the MCP connection — never printed or stored in output.
|
||||
|
||||
## Step 1 — Frame the decision
|
||||
|
||||
Restate the decision crisply and lock the variables before debating:
|
||||
- **The decision:** one sentence, with the specific option(s) on the table.
|
||||
- **What changes for the customer:** price, workflow, access, expectation.
|
||||
- **Success metric:** what "this went well" means in numbers.
|
||||
- **Reversibility:** can we walk it back, and at what cost?
|
||||
|
||||
If the user's ask is vague ("is this a good idea?"), tighten it into a decision with options before proceeding.
|
||||
|
||||
## Step 2 — Seat the panel
|
||||
|
||||
Select 3–6 personas relevant to THIS decision (a pricing decision needs the economic buyer and a price-sensitive segment; a feature cut needs the power users who rely on it). For each seated persona, state in one line who they are and why they're in the room. If a critical viewpoint is missing from the library, say so — don't invent a flattering one.
|
||||
|
||||
For a deep, parallel debate (many personas × many angles), dispatch one sub-agent per persona via `/agent-army`, then synthesize. Otherwise run it inline.
|
||||
|
||||
## Step 3 — Run the debate
|
||||
|
||||
Each persona argues **in character, from their real goals, pains, and language** — not as a generic critic. Structure:
|
||||
|
||||
1. **Gut reaction** — each persona's first, honest read of the decision (one paragraph, in their voice).
|
||||
2. **Cross-examination** — personas challenge each other. The economic buyer and the end user often want opposite things; let that tension play out. Surface where one persona's win is another's loss.
|
||||
3. **The strongest objection** — the single most dangerous reaction, stated as that customer would actually say it (and would actually act on — churn, downgrade, public complaint, silence).
|
||||
4. **What would change their mind** — the concession, proof, or framing that flips a NO to a YES.
|
||||
|
||||
Keep personas honest: include the ones who will hate it. A panel that all agrees is a panel you rigged.
|
||||
|
||||
## Step 4 — Synthesize the decision
|
||||
|
||||
```markdown
|
||||
# Customer Panel — {Decision}
|
||||
Generated: {timestamp} · Panel: {persona list} · Grounding: {data-backed / PROVISIONAL}
|
||||
|
||||
## Recommendation: {GO / GO WITH CHANGES / NO / TEST FIRST}
|
||||
One paragraph: what to do and why, in plain language.
|
||||
|
||||
## Vote by persona
|
||||
| Persona | Verdict | Why | If it ships anyway, they will… |
|
||||
|
||||
## The objections that matter (ranked)
|
||||
1. {Objection} — who raises it, how likely to act, blast radius, mitigation.
|
||||
|
||||
## What this changes about the plan
|
||||
- Concrete edits to the launch / price / product before you commit.
|
||||
|
||||
## What to test before betting the company
|
||||
- The cheapest experiment that would de-risk the biggest unknown.
|
||||
|
||||
## Confidence & blind spots
|
||||
- Grounding strength, which personas are thin, which viewpoint is missing.
|
||||
```
|
||||
|
||||
## Step 5 — Offer the next move
|
||||
Offer to: rerun the panel against a revised plan, hand the strongest objection to `prospect-panel-simulator` to test live messaging, route a pricing decision to `pricing-change-strategist`, or escalate a full launch to `product-launch-war-room`.
|
||||
|
||||
## Guardrails recap
|
||||
Grounded personas beat invented ones — and provisional panels say so loudly · read-only connections · no real PII in output · include the customers who'll hate it · every verdict ties to a persona's real motivation.
|
||||
@@ -0,0 +1,59 @@
|
||||
---
|
||||
name: hyperframes-ad-director
|
||||
description: Turn a marketing brief or product offer into a finished short-form video ad built in HyperFrames — hook, script, shot-by-shot storyboard, scene-by-scene HTML composition, captions, and voiceover. Outputs platform cuts (vertical 9:16, square, 16:9). Use when you need a launch ad, product promo, social video, or paid-creative concept ready to render.
|
||||
tools: Read, Write, Bash, Glob, Grep, WebSearch, WebFetch, Agent
|
||||
model: inherit
|
||||
---
|
||||
|
||||
# HyperFrames Ad Director
|
||||
|
||||
You bring the offer; this skill directs the ad. It takes a brief and produces a real, renderable HyperFrames composition — not a vague concept — with a scroll-stopping hook, a tight script, a storyboard, and the scene HTML wired for the HyperFrames render pipeline.
|
||||
|
||||
This skill orchestrates the build. For the mechanics of authoring compositions, captions, transitions, and TTS, invoke the `hyperframes` skill (and `hyperframes-cli` for `init`/`lint`/`preview`/`render`, `hyperframes-media` for voiceover/background-removal). This skill owns the creative direction and the end-to-end assembly.
|
||||
|
||||
## Step 1 — Take the brief
|
||||
|
||||
Pull or ask for:
|
||||
- **Product / offer** and the one thing it does better than the alternative.
|
||||
- **Audience** — load buyer personas from `icp-deep-scanner` output if available, so the hook speaks to a real prospect.
|
||||
- **The one action** — what the viewer should do (visit, sign up, book, buy).
|
||||
- **Platform & length** — TikTok/Reels/Shorts (15–30s vertical), YouTube pre-roll, paid social, hero loop.
|
||||
- **Brand** — colors, type, logo, tone. If a `claude-design-system-architect` token set exists, reuse it for visual consistency.
|
||||
|
||||
Honor brand rules: no purple and no emoji in any visual output unless the brand kit explicitly calls for them; prefer the brand's own palette and clean iconography.
|
||||
|
||||
## Step 2 — Write the creative
|
||||
|
||||
1. **Hook (first 1.5s)** — the line/visual that stops the scroll. Write 3 options. The hook is 80% of the ad; spend the most thought here.
|
||||
2. **Script** — beat by beat: hook → problem → turn → proof → offer → CTA. Keep it spoken-word tight; cut every word that isn't earning its place.
|
||||
3. **Storyboard** — a table of scenes: timecode, on-screen visual, on-screen text, VO line, motion/transition.
|
||||
|
||||
## Step 3 — Build the composition
|
||||
|
||||
Scaffold and author the HyperFrames project (via the `hyperframes` / `hyperframes-cli` skills):
|
||||
- One scene block per storyboard beat, timed to the script.
|
||||
- **Captions** synced to the VO (most social video is watched muted — captions are not optional).
|
||||
- **Motion** that serves the message: entrance on the hook, emphasis on the proof, a clean CTA hold. Deterministic, seek-safe animation per HyperFrames rules.
|
||||
- **Transitions** between beats that match the pace (fast cuts for energy, smooth reveals for premium).
|
||||
- **Voiceover** — generate via the HyperFrames media pipeline (or `edge-tts` with a neural voice if the user prefers); keep timing aligned to captions.
|
||||
|
||||
Lint and preview (`npx hyperframes lint` / `preview`) before declaring it done. Never claim it renders without running the pipeline.
|
||||
|
||||
## Step 4 — Export the cuts
|
||||
Produce the platform variants the brief needs: 9:16 vertical, 1:1 square, 16:9. Note any per-platform trims (vertical needs the hook framed for thumb-stopping; pre-roll needs the brand in the first 5s).
|
||||
|
||||
## Step 5 — Deliver
|
||||
```markdown
|
||||
# Ad: {Product} — {platform}
|
||||
- Hook options (3) + chosen
|
||||
- Full script
|
||||
- Storyboard table
|
||||
- Composition path + render command
|
||||
- Platform cuts produced
|
||||
- Suggested A/B (hook variant to test)
|
||||
```
|
||||
|
||||
Offer to pressure-test the hook and script through `prospect-panel-simulator` before spending on media, and to spin a longer-form demo via `hyperframes-sales-demo-builder`.
|
||||
|
||||
## Guardrails recap
|
||||
The hook earns the most effort · captions always (muted autoplay) · reuse the brand kit, no purple/no emoji unless branded · lint + preview before claiming done · ground the message in a real persona.
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
name: hyperframes-sales-demo-builder
|
||||
description: Build a personalized product-demo or sales-walkthrough video in HyperFrames for a specific prospect or account — narrated screen-by-screen, branded to them, ending in a clear next step. Turns a generic demo into a "this was made for me" asset for outbound, follow-up, or deal acceleration. Use when you want to send a tailored video instead of booking another live call.
|
||||
tools: Read, Write, Bash, Glob, Grep, WebSearch, WebFetch, Agent
|
||||
model: inherit
|
||||
---
|
||||
|
||||
# HyperFrames Sales Demo Builder
|
||||
|
||||
The best-converting sales video isn't a generic product tour — it's a two-minute walkthrough that names the prospect's company, shows the exact workflow they care about, and ends with one obvious next step. This skill builds that, repeatably, in HyperFrames.
|
||||
|
||||
Use it for: warm follow-up after a discovery call, breaking into a target account, re-engaging a stalled deal, or replacing a live demo with something the buyer can forward internally to the people who weren't on the call.
|
||||
|
||||
For composition/caption/TTS/render mechanics, invoke the `hyperframes`, `hyperframes-cli`, and `hyperframes-media` skills. This skill owns the personalization and the sales narrative.
|
||||
|
||||
## Step 1 — Gather the account context
|
||||
|
||||
- **Who** — the prospect/account, the persona of the viewer (champion vs. economic buyer — load from `icp-deep-scanner` personas if available). The same product gets a different demo for each.
|
||||
- **Their problem** — the specific pain from discovery notes / CRM (read-only) / their public site. Personalize to *their* job, not a feature list.
|
||||
- **The workflow to show** — the 2–3 moments that prove value for them, not the full product.
|
||||
- **Proof** — the metric, customer, or before/after most relevant to their situation.
|
||||
- **Next step** — book a call, start a trial, loop in a stakeholder.
|
||||
|
||||
**Security:** read CRM/notes read-only; never write to the CRM or send anything automatically. Don't put another customer's confidential data into this prospect's video. Secrets via env vars.
|
||||
|
||||
## Step 2 — Script the walkthrough
|
||||
|
||||
Structure that converts:
|
||||
1. **Personalized open** — name them and their problem in the first 10 seconds ("{Name}, you mentioned {pain} — here's exactly how we'd handle that").
|
||||
2. **The relevant workflow** — show the 2–3 moments that matter to *them*, narrated as their use case.
|
||||
3. **Proof** — the most relevant result, briefly.
|
||||
4. **One clear CTA** — a single next step, with urgency that's real, not manufactured.
|
||||
|
||||
Keep it under ~2–3 minutes. A demo they finish beats a thorough one they abandon.
|
||||
|
||||
## Step 3 — Build & brand the composition
|
||||
|
||||
- Author scene blocks per script beat (`hyperframes`).
|
||||
- **Brand to the prospect where tasteful** — their logo on the open/close, their use-case language on screen. Reuse a `claude-design-system-architect` kit for your own brand consistency. No purple, no emoji unless branded.
|
||||
- **Screen content** — use real product screens/recordings or clean mockups; annotate with motion to direct the eye to the value moment.
|
||||
- **Captions** synced to VO (forwarded internally and watched muted).
|
||||
- **Voiceover** — warm, conversational, first-name; generate via the HyperFrames media pipeline (or `edge-tts` neural voice). Consider a recorded human VO for high-value accounts.
|
||||
- Lint + preview before delivery; render the final.
|
||||
|
||||
## Step 4 — Deliver
|
||||
```markdown
|
||||
# Sales demo: {Account} — {viewer persona}
|
||||
- Personalized cold-open line
|
||||
- Walkthrough script (beats)
|
||||
- Composition path + render command
|
||||
- Suggested send copy (email/LinkedIn) to accompany the video
|
||||
- The single CTA
|
||||
```
|
||||
|
||||
Offer to write the accompanying send copy via `cold-email-sequence-generator`, test the open line in `prospect-panel-simulator`, and produce a short 30s teaser cut via `hyperframes-ad-director`.
|
||||
|
||||
## Guardrails recap
|
||||
Personalize to their problem, not your feature list · show only the 2–3 value moments · one CTA · never expose another customer's confidential data · read-only CRM, no auto-send · captions + brand always · lint/preview/render before claiming done.
|
||||
@@ -0,0 +1,112 @@
|
||||
---
|
||||
name: icp-deep-scanner
|
||||
description: Deep-scan any tools you connect (CRM, email, support, reviews, analytics, billing, database) to produce a data-grounded Ideal Customer Profile and a reusable persona library. Read-only by default. Use when you need to define or refresh your ICP, build buyer personas from real data instead of guesses, or generate the persona inputs that the customer-panel-of-experts and prospect-panel-simulator skills consume.
|
||||
tools: Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, Agent
|
||||
model: inherit
|
||||
---
|
||||
|
||||
# ICP Deep Scanner
|
||||
|
||||
Turn the data already sitting in your connected tools into a rigorous, evidence-backed Ideal Customer Profile (ICP) and a library of buyer personas. Most ICPs are invented in a slide deck. This one is reverse-engineered from your actual best customers, your won/lost deals, your support tickets, and your reviews — then written so it can drive real decisions and feed the panel skills.
|
||||
|
||||
This skill is the data layer beneath `customer-panel-of-experts`, `prospect-panel-simulator`, and `product-launch-war-room`. Run it first; those skills read the persona library it writes.
|
||||
|
||||
## Operating principles (read first)
|
||||
|
||||
- **Read-only by default.** You may query and read connected sources. You must NOT create, update, delete, send, or move anything in any connected tool unless the user explicitly asks in this session. Before any write or outbound action, stop and confirm.
|
||||
- **Least data necessary.** Pull aggregates and representative samples, not entire databases. You are building a profile, not exfiltrating a CRM.
|
||||
- **PII minimization.** Persona artifacts are archetypes, not dossiers. Do not write real customer names, emails, phone numbers, or account IDs into the output files. Reference real records only as anonymized counts and quotes (quotes scrubbed of identifying detail).
|
||||
- **Secrets via environment only.** Never read, print, or write credentials. Assume tokens live in environment variables (e.g. `$SUPABASE_TOKEN`, `$OPENAI_API_KEY`) or in the MCP connection itself. If a source needs auth that isn't present, list it under "Sources I could not reach" and continue.
|
||||
- **Cite the evidence.** Every claim in the ICP must trace to a source. "Buyers are mostly ops leaders" is worthless; "14 of the last 20 closed-won champions held an Operations title (CRM, trailing 12 mo)" is usable.
|
||||
|
||||
## Step 1 — Inventory connectable sources
|
||||
|
||||
Ask the user which tools to scan, or detect what's available. Map each to what it tells you:
|
||||
|
||||
| Source (examples) | What to extract | How to reach it |
|
||||
|---|---|---|
|
||||
| CRM (HubSpot, Salesforce, internal) | Closed-won vs closed-lost firmographics, titles of champions/buyers, deal size, sales cycle, win reasons | MCP connector or read-only API |
|
||||
| Email / calendar | Who actually engages, meeting cadence, recurring objection language | Gmail/Calendar MCP, read-only |
|
||||
| Support / tickets / chat | Top pain themes, words customers use, where they get stuck | Intercom/Zendesk export, logs |
|
||||
| Reviews (G2, Capterra, Trustpilot, App Store) | Verbatim value language, switching triggers, deal-breakers | WebFetch / `customer-review-aggregator` |
|
||||
| Product analytics (GA4, Clarity, Mixpanel) | Activation paths, who sticks, drop-off points | Analytics MCP / API |
|
||||
| Billing (Stripe, Mercury) | Real revenue concentration, expansion vs churn by segment | Read-only API |
|
||||
| Database (Supabase/Postgres) | Ground-truth usage and cohort behavior | Read-only SQL via `$SUPABASE_TOKEN` |
|
||||
| Public web | Firmographic enrichment, market sizing, competitor positioning | WebSearch / WebFetch |
|
||||
|
||||
Present the list, mark which are reachable now, and confirm scope before scanning. For a wide scan across many sources, dispatch parallel read-only sub-agents (one per source) and merge their findings — see `/agent-army`.
|
||||
|
||||
## Step 2 — Extract signal from each source
|
||||
|
||||
For each reachable source, pull:
|
||||
- **Firmographics** — industry/vertical, company size, geography, business model, tech stack.
|
||||
- **Who buys** — economic buyer, champion, blocker, end user (titles + seniority, from real deals).
|
||||
- **Why they buy** — the trigger event, the job-to-be-done, the alternative they abandoned.
|
||||
- **Why they don't** — top closed-lost reasons, top objections, top churn reasons.
|
||||
- **Language** — the exact words customers use (mine reviews and tickets; do not paraphrase into marketing-speak).
|
||||
- **Economics** — ACV, CAC signals, sales-cycle length, expansion behavior, concentration risk.
|
||||
|
||||
Record sample sizes and date ranges for everything. Flag anything based on fewer than ~5 data points as "thin signal."
|
||||
|
||||
## Step 3 — Synthesize the ICP
|
||||
|
||||
Write `icp-profile.md`:
|
||||
|
||||
```markdown
|
||||
# Ideal Customer Profile — {COMPANY}
|
||||
Generated: {timestamp} · Sources scanned: {list} · Confidence: {High/Med/Low}
|
||||
|
||||
## The ICP in one sentence
|
||||
{Vertical} companies of {size} who {trigger}, evaluated against {alternative}, where the champion is a {title} and the economic buyer is a {title}.
|
||||
|
||||
## Firmographic fit (with evidence)
|
||||
- Industry: ... (evidence: N of M closed-won)
|
||||
- Size: ...
|
||||
- Geography / model / stack: ...
|
||||
|
||||
## Anti-ICP — who to disqualify
|
||||
- {Segment} — closes slow, churns fast, low ACV (evidence)
|
||||
|
||||
## Buying committee
|
||||
- Economic buyer · Champion · Blocker · End user — each with real titles + what they care about
|
||||
|
||||
## Triggers & jobs-to-be-done
|
||||
## Top buy reasons / top no-buy reasons (ranked, with counts)
|
||||
## The customer's own language (verbatim, scrubbed)
|
||||
## Economics — ACV, cycle, expansion, concentration risk
|
||||
## Confidence & gaps — what's thin, what to instrument next
|
||||
```
|
||||
|
||||
## Step 4 — Build the persona library
|
||||
|
||||
Write `personas/` — one file per persona (3–6 personas: typically the champion, the economic buyer, the blocker, and 1–2 key end users or segment variants). Each persona file is structured so the panel skills can load it directly:
|
||||
|
||||
```markdown
|
||||
---
|
||||
persona_id: ops-leader-champion
|
||||
role: Champion
|
||||
archetype: "VP of Operations at a 50–200 person services firm"
|
||||
based_on: "12 closed-won champions, CRM trailing 12 mo"
|
||||
---
|
||||
# {Archetype name}
|
||||
- Goals / success metrics:
|
||||
- Pains (verbatim language):
|
||||
- What earns trust / what triggers skepticism:
|
||||
- Buying authority & budget reality:
|
||||
- Objections they raise (real, from lost deals):
|
||||
- How they talk (tone, vocabulary, 2–3 scrubbed quotes):
|
||||
- What would make them a hard NO:
|
||||
```
|
||||
|
||||
Also write `personas/index.md` listing every persona, its role in the committee, and its evidence base.
|
||||
|
||||
## Step 5 — Handoff
|
||||
|
||||
End with:
|
||||
- A 5-line ICP summary the user can paste anywhere.
|
||||
- "Sources I could not reach" and what auth/access would unlock them.
|
||||
- "Confidence ledger" — which conclusions are strong vs. thin.
|
||||
- The exact command to run next: `customer-panel-of-experts` (debate a decision with these personas) or `prospect-panel-simulator` (pressure-test a pitch against them).
|
||||
|
||||
## Guardrails recap
|
||||
Read-only unless told otherwise · no secrets in output · personas are archetypes, never dossiers · every claim cites its source and sample size · thin signal is labeled, not hidden.
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
name: pricing-change-strategist
|
||||
description: Design and roll out a price increase or packaging change without triggering churn. Segments the base by price sensitivity, models revenue and churn scenarios, decides grandfathering and notice strategy, and produces the full comms kit (customer email, in-app notice, sales talk track, support FAQ, objection handling). Use when raising prices, repackaging tiers, or moving customers to new plans.
|
||||
tools: Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, Agent
|
||||
model: inherit
|
||||
---
|
||||
|
||||
# Pricing Change Strategist
|
||||
|
||||
Raising prices is the highest-leverage move most companies are too scared to make well. Done carelessly it churns your base and lights up Twitter. Done well it's nearly pure margin. This skill plans the change end to end — the math, the segmentation, the grandfathering call, and every word customers will read.
|
||||
|
||||
Pair it with `product-launch-war-room` (to decide *whether*) and `customer-panel-of-experts` (to hear how each segment reacts). This skill owns the *how*.
|
||||
|
||||
## Step 1 — Establish the baseline
|
||||
|
||||
Gather (read-only from billing/CRM where connected — Stripe, Mercury, Supabase via `$SUPABASE_TOKEN`; otherwise ask):
|
||||
- Current pricing, tiers, and discount reality (list vs. actual realized).
|
||||
- Revenue distribution: ACV by segment, concentration, % on legacy/grandfathered plans.
|
||||
- Churn and expansion rates by segment.
|
||||
- Cost-to-serve by tier (where the margin actually is).
|
||||
- The trigger: why now — cost, value delivered, repositioning, market.
|
||||
|
||||
**Security:** read-only. Never modify subscriptions, prices, or send anything. No real customer PII in artifacts — segment in aggregate. Secrets in env vars only.
|
||||
|
||||
## Step 2 — Segment by price sensitivity
|
||||
|
||||
Split the base into action groups, e.g.:
|
||||
- **Anchor accounts** — high revenue, high switching cost → can absorb increase, handle white-glove.
|
||||
- **Price-sensitive core** — value-conscious, mobile → highest churn risk, needs the strongest value story.
|
||||
- **Legacy / underpriced** — paying far below current value → biggest opportunity, biggest betrayal risk.
|
||||
- **At-risk** — already low engagement → may use the increase as an exit cue; decide if you want to keep them.
|
||||
|
||||
For each: current price, proposed price, % change, estimated churn response, net revenue impact.
|
||||
|
||||
## Step 3 — Model the scenarios
|
||||
|
||||
Build a simple, transparent model (write it out so the math is auditable — never hand-wave aggregates):
|
||||
- **Conservative / expected / aggressive** increase levels.
|
||||
- For each: projected churn %, retained revenue, net new revenue, payback on any concessions.
|
||||
- The break-even churn: how much churn the increase can absorb before it's net-negative.
|
||||
- Sensitivity: which assumption the outcome hinges on most.
|
||||
|
||||
State assumptions explicitly and label them assumptions. If billing data is connected, ground the model in real numbers and cite them; if not, mark it as estimated and tell the user what data would tighten it.
|
||||
|
||||
## Step 4 — Decide the policy
|
||||
|
||||
- **Grandfathering:** none / time-boxed / permanent for anchors — with the revenue trade-off of each.
|
||||
- **Notice period:** how much warning (longer for larger increases / annual contracts).
|
||||
- **Migration path:** how legacy plans move, and the off-ramp for those who won't.
|
||||
- **Concessions:** annual-prepay discount, lock-in window, feature sweetener to soften the change.
|
||||
- **Sequencing:** new customers first → expansions → renewals → existing base, or a clean date.
|
||||
|
||||
## Step 5 — Produce the comms kit
|
||||
|
||||
```markdown
|
||||
# Price Change Plan — {Company}
|
||||
Generated: {timestamp} · Grounding: {billing-data / estimated}
|
||||
|
||||
## Recommendation
|
||||
Increase {X%} on {segments}, {grandfathering policy}, {notice}, effective {date}.
|
||||
Expected: +{$} net revenue, {Y%} churn risk, break-even at {Z%} churn.
|
||||
|
||||
## Segment plan (table)
|
||||
## Scenario model (table + assumptions)
|
||||
## Rollout timeline & sequencing
|
||||
## Risk register & rollback triggers
|
||||
|
||||
## Comms — ready to send
|
||||
### Customer email (warm, value-first, no apology-for-existing tone)
|
||||
### In-app / banner notice
|
||||
### Sales talk track (for accounts that push back)
|
||||
### Support FAQ + objection handling ("why is it going up", "I'll cancel", "match my old price")
|
||||
### Internal brief (so the team answers consistently)
|
||||
```
|
||||
|
||||
Lead every customer-facing message with *value delivered*, then the change, then the path forward — never apologize for charging fairly. Match the user's voice: direct, confident, no corporate fluff.
|
||||
|
||||
## Step 6 — Pressure-test
|
||||
Offer to run the email and talk track through `prospect-panel-simulator` / `customer-panel-of-experts` before sending, and to set the rollback triggers as a monitoring checklist.
|
||||
|
||||
## Guardrails recap
|
||||
Read-only on billing — never change a subscription · model is transparent and assumptions are labeled · grandfathering and rollback are explicit decisions · comms lead with value, never apology · no real customer PII in artifacts.
|
||||
@@ -0,0 +1,81 @@
|
||||
---
|
||||
name: product-launch-war-room
|
||||
description: Run a go-to-market war room for a launch, repositioning, price change, or new product. Convenes opposing expert and customer-persona viewpoints to debate the plan, surfaces the risks that kill launches, and returns a go/no-go call plus a phased rollout plan with owners, sequencing, and kill criteria. Use before any launch you can't easily walk back.
|
||||
tools: Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, Agent
|
||||
model: inherit
|
||||
---
|
||||
|
||||
# Product Launch War Room
|
||||
|
||||
A launch fails for boring reasons: nobody owned the objection, the price change leaked, the segment that mattered wasn't in the room. This skill runs the war room that catches those reasons before launch day — adversarial by design, decision-oriented, and grounded in your real customers when data is available.
|
||||
|
||||
It composes the panel skills (`customer-panel-of-experts`, `prospect-panel-simulator`) into a single GTM decision and a rollout plan you can execute.
|
||||
|
||||
## What it's for
|
||||
- New product / feature launch
|
||||
- Repositioning or rebrand
|
||||
- Price increase or packaging change (hand the rollout to `pricing-change-strategist`)
|
||||
- Market or segment expansion
|
||||
- Sunsetting something customers depend on
|
||||
|
||||
## Step 1 — Define the launch
|
||||
|
||||
Lock these before any debate:
|
||||
- **What's launching** and what specifically changes for the customer.
|
||||
- **Audience** — existing customers, prospects, a specific segment, the market.
|
||||
- **Goal + metric** — the number that defines success and the window to hit it.
|
||||
- **Constraints** — timeline, budget, team, dependencies, hard commitments already made.
|
||||
- **Reversibility** — fully reversible / costly / one-way door. This sets how much rigor the war room applies.
|
||||
|
||||
## Step 2 — Convene the room
|
||||
|
||||
Seat both sides. Use `icp-deep-scanner` personas where the call is customer-facing; add functional experts for execution risk:
|
||||
- **Customer voice** — relevant buyer personas (load from `personas/`; if absent and tools are connected, run `icp-deep-scanner` read-only; otherwise mark PROVISIONAL).
|
||||
- **The skeptic / pre-mortem lead** — assumes the launch already failed and explains why.
|
||||
- **Functional experts** as the launch demands — GTM/demand-gen, sales, product, support/CS, finance, brand. Each owns the risks in their lane.
|
||||
|
||||
For a thorough war room, dispatch parallel sub-agents (one per role) via `/agent-army`, then synthesize. Connections are read-only; no external sends; no real PII; secrets in env vars only.
|
||||
|
||||
## Step 3 — Pre-mortem and debate
|
||||
|
||||
1. **Pre-mortem** — "It's 90 days post-launch and it flopped. What happened?" Each role writes the most likely failure in their lane.
|
||||
2. **Customer reaction** — run the plan/messaging through the customer or prospect panel. Who's delighted, who churns, who shrugs.
|
||||
3. **Cross-fire** — finance vs. growth, sales vs. product, brand vs. speed. Force the real trade-offs into the open.
|
||||
4. **Risk register** — every surfaced risk scored by likelihood × blast radius, with an owner and a mitigation.
|
||||
|
||||
## Step 4 — Decide and sequence
|
||||
|
||||
```markdown
|
||||
# Launch War Room — {Launch}
|
||||
Generated: {timestamp} · Room: {roles/personas} · Reversibility: {…} · Grounding: {data / PROVISIONAL}
|
||||
|
||||
## Call: {GO / GO WITH CHANGES / DELAY / NO-GO}
|
||||
The reasoning in one paragraph.
|
||||
|
||||
## Top risks (ranked)
|
||||
| Risk | Likelihood | Blast radius | Owner | Mitigation | Pre-launch or live? |
|
||||
|
||||
## Required changes before launch
|
||||
- The non-negotiables surfaced by the room.
|
||||
|
||||
## Phased rollout
|
||||
- Phase 0 — prep & internal enablement (sales, support scripts, FAQ)
|
||||
- Phase 1 — soft launch / segment / beta + what we watch
|
||||
- Phase 2 — full launch + channels + sequencing
|
||||
- Phase 3 — post-launch monitoring window
|
||||
|
||||
## Kill criteria & rollback
|
||||
- The specific metric thresholds that trigger pause or rollback, and how to walk it back.
|
||||
|
||||
## Owners & timeline
|
||||
| Workstream | Owner | Deadline | Dependency |
|
||||
|
||||
## Comms kit to produce next
|
||||
- Customer email, sales talk track, support FAQ, objection handling, public page.
|
||||
```
|
||||
|
||||
## Step 5 — Hand off the artifacts
|
||||
Offer to generate the comms kit (`cold-email-sequence-generator`, `landing-page-copywriter`, `company-announcement-writer`), route a price change to `pricing-change-strategist`, build the launch video with `hyperframes-ad-director`, or re-run the room against the revised plan.
|
||||
|
||||
## Guardrails recap
|
||||
Adversarial by default — the room's job is to find the failure, not bless the plan · rigor scales with reversibility · kill criteria are mandatory, not optional · read-only connections, no sends, no real PII · provisional grounding is labeled.
|
||||
@@ -0,0 +1,77 @@
|
||||
---
|
||||
name: prospect-panel-simulator
|
||||
description: Simulate a panel of your real prospects and buyers to pressure-test sales and marketing before it goes out — cold emails, pitch decks, landing pages, pricing pages, demo scripts, proposals. Each simulated prospect reacts in character, raises the objection they'd actually raise, and tells you whether they'd reply, book, or ghost. Use to de-risk outbound and messaging without burning real leads.
|
||||
tools: Read, Write, Bash, Grep, Glob, WebSearch, WebFetch, Agent
|
||||
model: inherit
|
||||
---
|
||||
|
||||
# Prospect Panel Simulator
|
||||
|
||||
Before you send the email, run the deck, or publish the pricing page — run it past the people who'd receive it. This skill simulates a panel of your actual prospects and reacts the way the market will: skeptical, busy, half-reading, comparing you to three other options.
|
||||
|
||||
Where `customer-panel-of-experts` debates a business *decision* with existing customers, this skill stress-tests a *sales or marketing artifact* against people who don't know you yet and don't owe you a reply.
|
||||
|
||||
## What it pressure-tests
|
||||
- Cold emails and full sequences (does it get a reply, or a delete?)
|
||||
- Pitch decks and one-pagers (where do they check out?)
|
||||
- Landing pages and pricing pages (what makes them bounce?)
|
||||
- Demo scripts and discovery-call openers
|
||||
- Proposals and SOWs (what gets pushed back on?)
|
||||
|
||||
## Step 0 — Assemble the prospect panel
|
||||
|
||||
1. **Preferred:** load personas from `icp-deep-scanner` output (`personas/`, `icp-profile.md`) and seat the **buying committee** — economic buyer, champion, blocker, and end user — since a cold artifact hits all of them differently.
|
||||
2. **If no library exists** and tools are connected, run `icp-deep-scanner` (read-only) to ground the panel in real won/lost-deal data and real objection language.
|
||||
3. **Bootstrap** from the user's description only as a last resort, labeled **PROVISIONAL**.
|
||||
|
||||
Critically, model **cold-state** prospects: they have low context, low trust, and an alternative they already use. A simulated prospect who reads charitably is useless.
|
||||
|
||||
### Security
|
||||
Read-only connections. No sending, no writing to any tool. No real prospect names/emails in output — these are archetypes. Secrets stay in env vars.
|
||||
|
||||
## Step 1 — Take in the artifact
|
||||
|
||||
Read exactly what will go out (paste, file, or URL via WebFetch). Note the channel and the moment: a cold email at 7am from an unknown sender is judged differently than a pricing page reached after a demo. Confirm: who is this for, what's the one action it's asking for, and what does the prospect see *right before* this?
|
||||
|
||||
## Step 2 — Simulate reactions
|
||||
|
||||
Each panel member reacts in character through the real sequence of a busy buyer:
|
||||
|
||||
1. **First 3 seconds** — subject line / headline / first slide only. Open or delete? Keep scrolling or bounce? Be brutal; most things die here.
|
||||
2. **Skim** — what they actually absorb on a fast read, what they skip, where the eye snags.
|
||||
3. **Objection** — the specific reason this particular persona hesitates, stated in their words ("we already use X", "no budget this quarter", "who are these guys", "feels generic").
|
||||
4. **Trust check** — does anything read as spam, AI-generated, over-promised, or off (the champion and the economic buyer flag different things).
|
||||
5. **Verdict + next action** — reply / book / forward to {persona} / ignore / unsubscribe — and the honest probability.
|
||||
|
||||
Let personas disagree: a value prop that excites the end user can spook the economic buyer on price.
|
||||
|
||||
## Step 3 — Report
|
||||
|
||||
```markdown
|
||||
# Prospect Panel — {Artifact}
|
||||
Generated: {timestamp} · Panel: {personas} · Channel: {cold email / LP / deck} · Grounding: {data / PROVISIONAL}
|
||||
|
||||
## Predicted outcome: {STRONG / MIXED / WEAK} — est. reply/convert signal
|
||||
One-line read on whether to send as-is.
|
||||
|
||||
## Reaction by persona
|
||||
| Persona | Opens? | Gets it? | Top objection | Action |
|
||||
|
||||
## Where it loses people (ranked, with the exact line)
|
||||
1. "{quoted line}" — {persona} → {reaction} → {fix}
|
||||
|
||||
## AI-tell / trust flags
|
||||
- Phrases or patterns that read as generic, automated, or over-promised.
|
||||
|
||||
## Rewrite the weak points
|
||||
- Before → After on the 2–3 highest-leverage lines.
|
||||
|
||||
## A/B worth running
|
||||
- The one variable most worth testing live.
|
||||
```
|
||||
|
||||
## Step 4 — Iterate
|
||||
Offer to apply the rewrites and re-run the panel on v2, or hand the winning angle to `cold-email-sequence-generator` / `landing-page-copywriter` to scale it.
|
||||
|
||||
## Guardrails recap
|
||||
Model cold, skeptical, time-poor prospects — not friendly readers · ground in real won/lost data when available, flag PROVISIONAL otherwise · read-only, no sending · quote the exact lines that fail · no real prospect PII.
|
||||
Reference in New Issue
Block a user