diff --git a/skills/pitch-prep/LICENSE.txt b/skills/pitch-prep/LICENSE.txt new file mode 100644 index 0000000..3b819ed --- /dev/null +++ b/skills/pitch-prep/LICENSE.txt @@ -0,0 +1,21 @@ +MIT License + +Copyright (c) 2026 Shubhankar + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/skills/pitch-prep/README.md b/skills/pitch-prep/README.md new file mode 100644 index 0000000..9ed95bd --- /dev/null +++ b/skills/pitch-prep/README.md @@ -0,0 +1,58 @@ +# pitch-prep + +A Claude Code skill that preps you for a sales meeting. Give it **what you're selling** and **who you're selling to**; it researches both — *browsing the prospect's live site* for concrete hooks — proposes **3 ranked demo concepts** for you to pick from, then expands your pick into a tailored, **self-contained HTML demo brief** that opens in your browser. + +It's product-agnostic: works whether you're selling an API, a SaaS app, or a browser-automation tool. + +## Why it's good + +- **Browser-first research.** It doesn't theorize from the company name — it walks the prospect's real money path, mines review sites, and grabs hiring/competitor signals, capturing **screenshots** as evidence. +- **Uses the full web-data stack.** Search to *find* pages → Fetch to *read* them cheaply → Browse to *walk* flows and capture screenshots / get past anti-bot. (Browserbase's `browse cloud search`, `browse cloud fetch`, and cloud browser sessions; falls back to Claude's `WebSearch`/`WebFetch`.) +- **One sharp wedge, not a feature dump.** Every brief connects one concrete prospect pain to one product capability, with a single named "wow" moment — and every claim is sourced to a URL. +- **A sendable artifact.** Output is a self-contained HTML file (screenshots embedded) that auto-opens and can be forwarded as-is. + +## Prerequisites + +- **Claude Code.** +- **The `browser` skill** (Browserbase cloud browser automation) for the research spine. The Search/Fetch/Browse commands use the [`@browserbasehq/browse-cli`](https://www.npmjs.com/package/@browserbasehq/browse-cli) with a `BROWSERBASE_API_KEY` set. +- Without Browserbase configured, it degrades to Claude's built-in `WebSearch` / `WebFetch` (no screenshots, no anti-bot). +- `python3` (for `embed_images.py`). + +## Install + +Drop the folder where Claude Code discovers skills (e.g. symlink into `~/.claude/skills/`): + +```bash +ln -s "$(pwd)/pitch-prep" ~/.claude/skills/pitch-prep +``` + +Then invoke it: + +``` +/pitch-prep +# e.g. /pitch-prep Browserbase browserbase.com → Chorus chorus.com +``` + +## What you get + +1. **Scope check**, then a tight **capability sheet** for the product. +2. A **browser crawl** of the prospect → sourced hooks + screenshots. +3. **3 ranked demo concepts** — you pick one (mandatory checkpoint). +4. A **self-contained HTML brief** (`demo-brief--portable.html`) that auto-opens: TL;DR, screenshot evidence, the wedge, beat-by-beat storyline, reproducible flow, talking points, prospect-specific objections, success criteria. + +## Files + +| File | Purpose | +|------|---------| +| `SKILL.md` | The skill: workflow, the bar for a good brief, the research stack, guardrails. | +| `brief-template.md` | Section structure for the brief. | +| `brief.css` | Styling for the HTML brief (override `--accent` for a light brand touch). | +| `embed_images.py` | Inlines + compresses screenshots into the HTML and auto-opens it (`--no-open` to suppress). | + +## Scope + +`pitch-prep` stops at the **brief** — it does not build or run the live demo (that's a product-specific layer), and it does not auto-generate a fully branded slide deck (a planned optional extension). The brief is designed to be the clean input to those next steps. + +## License + +MIT. diff --git a/skills/pitch-prep/SKILL.md b/skills/pitch-prep/SKILL.md new file mode 100644 index 0000000..05bcd47 --- /dev/null +++ b/skills/pitch-prep/SKILL.md @@ -0,0 +1,158 @@ +--- +name: pitch-prep +description: Prep for a sales meeting by deeply researching a product you're selling AND the prospect you're selling to — browsing the prospect's live site for concrete hooks — then proposing 3 ranked demo concepts to pick from, and expanding the chosen one into a tailored, demo-ready brief delivered as a self-contained HTML page. Use when the user says "prep for my [prospect] call", "pitch prep", "build a demo for [prospect]", "what should we demo to [prospect]", "tailor a demo to [customer]", or "research [prospect] for a pitch". +--- + +# Pitch Prep + +## Overview + +This skill turns *"we have a meeting with [prospect]"* into a **demo-ready brief**: a tight, opinionated document that says exactly what to demo, why it will land with *this specific prospect*, and how to walk it beat-by-beat. + +It works for **any product** — the skill is given two things: **what you're selling** and **who you're selling to**. The value it adds is research + judgment, not code. (Actually generating/running the live demo is a separate, product-specific layer; this skill stops at the brief.) + +The process is deliberately **human-in-the-loop on the one decision that matters**: after research, the skill proposes **3 ranked demo concepts** and the user picks one. Then it expands the chosen concept into the full brief. It does not silently pick a concept and run. + +**The whole point is specificity.** A generic "show them how great the product is" brief is a failure. Every brief must be anchored to concrete things found on the prospect's actual site — their real checkout flow, their real job listings, their real pricing page, their real data. If the brief could have been written without visiting their site, it's wrong. + +> **About paths in this skill:** this skill ships with three sibling files — `brief-template.md`, `brief.css`, and `embed_images.py`. They live in **this skill's base directory** (the path shown as *"Base directory for this skill:"* when the skill loads). Wherever the steps below say `$SKILL_DIR`, substitute that base directory. The skill has **no machine-specific paths** — it's portable across users. + +## The bar for a good brief (read before producing anything) + +A brief earns its place only if: + +1. **It names real things.** Specific pages, flows, products, data, and pain points found on the prospect's *actual* site — with URLs. Not "their e-commerce experience" but "their checkout at shop.acme.com/cart, which forces account creation before showing shipping cost." +2. **The wedge is sharp.** It connects ONE concrete prospect pain/opportunity to ONE product capability. Demos that try to show everything show nothing. +3. **There's a single wow moment.** The one beat that makes them lean in. If you can't name it in a sentence, the concept isn't ready. +4. **It's runnable.** The flow is concrete enough that someone (or, later, an agent) could reproduce it step-by-step. +5. **It speaks their language.** Reference their industry, competitors, and the words *they* use on their own site — not the seller's internal jargon. + +If research can't surface concrete hooks (thin site, no public surface), say so plainly and propose concepts against a **public vertical target** instead — but flag that it's a fallback. + +## Inputs + +The skill needs two things. If either is missing from the invocation, ask for it before doing anything else. + +1. **The product** — what the user is selling. A name + URL is enough; the skill researches the rest. (e.g. "Browserbase — browserbase.com") +2. **The prospect** — who they're selling to. A company name + domain. (e.g. "Acme Corp — acme.com") + +Optionally accept: known context about the deal (notes, the champion's role, a critical event, what they've already seen), a specific angle the user wants emphasized, or constraints (time-boxed demo, no-login, security-sensitive). + +## Research stack — Search + Fetch + Browse (use the combo) + +Research is **not** a single tool — it's three, used together. With Browserbase you have the full web-data stack via the `browse` CLI, and using all three *is itself part of the pitch* (the research run shows the product working): + +| Tool | Command | Use it for | +|------|---------|-----------| +| **Search** | `browse cloud search "" --num-results 10 --json` | Breadth — *find* the right pages fast (their pricing page, G2 reviews, funding news, competitor sites). Start here. | +| **Fetch** | `browse cloud fetch --format markdown` (add `--proxies` for protected sites; `--format json --schema <…>` for structured extraction) | Depth-by-text — *pull* clean, token-efficient content from a known URL without spinning a full browser. Fast and cheap. | +| **Browse** | the `browser` skill (`browse open --remote …`, `snapshot`, `screenshot`) | Interactive depth — *walk* JS-heavy flows, click through their money path, and **capture screenshots**. The only tool that gets evidence images and reaches login/anti-bot walls. | + +**The pattern:** Search to find → Fetch to read at scale → Browse for the interactive walk + screenshots. Reach for Browse whenever you need to *click, log in, get past bot detection, or capture a screenshot*; use Search/Fetch for everything else because they're faster. Generic fallback when Browserbase isn't configured: `WebSearch` / `WebFetch`. + +## Workflow + +### Step 1 — Confirm scope + +Restate, in one line, what you understood: *"Building a tailored demo brief for **[prospect]**, selling **[product]**."* If product or prospect is missing or ambiguous, ask. Don't proceed on a guess. + +### Step 2 — Research the product (build a capability sheet) + +Goal: know the product well enough to map its strengths onto the prospect's needs. Keep it tight — you need the *demoable edges*, not a full teardown. + +- Use **Search → Fetch**: `browse cloud search " positioning / customers / benchmarks"` to find the right pages, then `browse cloud fetch ` to pull the product site + docs as clean markdown. (Browse isn't usually needed here — the product's own marketing is rarely bot-walled.) +- Produce a short internal **capability sheet**: the product's 2–4 genuinely differentiated capabilities, each with (a) what it does, (b) the kind of pain it removes, (c) the most visceral way to *show* it (not tell). Note proof points (named customers, benchmarks) you can reference. +- Don't pad. Four sharp capabilities beat twelve features. + +### Step 3 — Research the prospect with the browser (this is the spine of the skill) + +This is the step that makes or breaks the brief — and it is **browser-first by design**. Two reasons: (1) a real browser sees JS-rendered product surfaces, walks interactive flows, and reaches bot-walled review sites that `WebFetch` simply can't; (2) **this skill is itself a showcase of browser-based prospecting** — the research run should demonstrate the value of doing this with a cloud browser. + +Use the **Search + Fetch + Browse combo** (see "Research stack" above): `browse cloud search` to find the hooks (reviews, funding, competitors), `browse cloud fetch` to read pages cheaply, and the **`browser` skill** (Browserbase cloud sessions) for the interactive walk — clicking the money path, getting past anti-bot/login walls, and **capturing screenshots**. Browse is non-negotiable for anything you need to *click, log into, or screenshot*; that's the depth fetch can't give, and it's where the product showcases itself. + +Run this **required checklist** every time, capturing **a screenshot + sourced hooks at each step** (screenshots are saved and embedded in the brief — they're free visual evidence once the browser is open): + +1. **Walk the money path + screenshot it.** Actually click through their core flow — signup / onboarding / search / checkout / configurator / the AI feature you'll pitch against. Capture the exact screens and any friction. This is what turns "their signup has friction" into "*at step 3 (screenshot) they ask for X before showing Y*." +2. **Mine one review/sentiment source for real pain.** G2, Capterra, TrustRadius, Reddit, or app-store reviews — the richest hook source, and mostly bot-walled (a cloud browser gets in). The prospect's own users' top complaints *become the demo wedge*. +3. **Grab hiring + scale signals.** Their live careers page / LinkedIn jobs / eng blog — what roles, how many, what stack → what they're building and scaling right now. +4. **Grab the customer + competitor signal.** Who they serve (logos/case studies) and 1–2 competitors worth a "they already ship X" line. + +Also run `browse cloud search` for hard context (funding, launches, headcount) that isn't on their site. + +**Capture concrete hooks** as you go — exact URLs, the specific flow step, the specific friction. A hook is only a hook if it's *specific, verifiable, and ideally has a screenshot*. Keep the browser session/replay link — it goes in the brief as proof the research was real. + +**Capturing screenshots — do it right (this matters):** +- **Viewport captures, NOT full-page.** Screenshot the *specific section that contains the hook* (the hero with the headline, the pricing tier, the friction step) — not the whole page. A full-page capture of a long marketing site embeds as an unreadable, blurry strip. A viewport shot of the hero is sharp and shows the exact quote you're citing. +- Save them to a per-prospect working dir: `/tmp/pitch-prep-/` with descriptive names (`hero.png`, `pricing.png`). +- If using the Browserbase `browse` CLI (v0.8.x): use the **`--remote` flag** on `open`/`screenshot` (there is no `browse env remote` subcommand); the screenshot path is the **`-p` flag** with an **absolute path** (`browse screenshot -p /tmp/pitch-prep-/hero.png`) — a positional path is ignored (prints base64), and a *relative* `-p` saves to the daemon's cwd, not your shell's; **omit `--full-page`** to get the viewport. +- **Wait for animations to settle** before capturing — many hero sections type/animate in. Wait ~4s after load (`browse wait timeout 4000`) then screenshot, or you'll catch a half-rendered headline. +- Aim for 1–4 screenshots total — the sharpest hooks, not every page. + +If a surface is unreachable or near-empty, say so and move on; if the whole site is too thin for real hooks, switch to a public vertical target (Step 4 note). + +### Step 4 — Synthesize 3 ranked demo concepts + +Map the **capability sheet** (Step 2) against the **hooks** (Step 3). Produce **exactly 3 concepts**, ranked best-first. Each concept is short and decision-ready: + +``` +### Concept N — [punchy title] +- **Hook:** [the specific thing on their site this exploits — with URL] +- **Capability shown:** [which product strength it demonstrates] +- **The wow:** [the one beat that makes them lean in — one sentence] +- **What runs:** [what the live demo actually does — see the two demo media below] +- **Effort / risk:** [low/med/high — how reliably this demos live] +- **Why it ranks here:** [one sentence — why #1 beats #2] +``` + +**Two demo media — pick the right one for the product you're selling:** +- **Automation-medium demo** (product *acts on the web* — e.g. Browserbase, an RPA/agent tool): the demo runs *on the prospect's own public site/flow*. Risk = login walls, anti-bot, pages that change. "What runs" = their site. +- **Infra/API demo** (product *is consumed by* the prospect's product — e.g. an API, a data/research provider): the demo runs *the product on a prospect-realistic task*, and the prospect's site is the *research material / prompt frame*, not an automation target. "What runs" = a live API/product call on a task their users would actually run. Don't force-fit this into "automate their site." + +Ranking criteria, in order: **(1)** sharpness of the wedge (does it hit a real, felt pain?), **(2)** strength of the wow moment, **(3)** how reliably it runs live. A flashy concept that needs a login, trips anti-bot, or is non-deterministic ranks below a solid one that runs clean. + +Present the 3 concepts and **stop. Ask the user to pick one** (or blend/adjust). Do not expand a brief until they choose. + +### Step 5 — Expand the chosen concept into the brief + +Read `$SKILL_DIR/brief-template.md` and fill every section for the chosen concept. Rules: + +- **Every claim about the prospect carries a URL** to where you found it. +- **Embed the screenshots** captured in Step 3 in the "What we saw" evidence section, and inline against the hooks they prove. Include the browser replay link. +- **The flow section is reproducible** — concrete steps, ideally no auth required. This is also the clean seam for a later agentic layer that actually runs the demo. +- **Talking points are in the seller's voice**, mapped to the prospect's pain — not feature recitation. +- **Objections are specific to this prospect** (their scale, their stack, their likely concerns), not boilerplate. +- Keep it skim-first. A busy AE/SE reads this on a phone before a call. Tight beats complete. + +### Step 6 — Deliver (a self-contained HTML brief that auto-opens) + +**The deliverable is a single self-contained HTML file that opens in the user's browser** — not bare markdown. A markdown brief with relative image paths (`![](hero.png)`) shows broken images the moment it's moved or sent; that's a failed deliverable. HTML with inlined images renders anywhere and is what people actually want to forward. + +1. Write the brief content to `/tmp/pitch-prep-/demo-brief-.md` (markdown, following `brief-template.md`) — the readable source of record. +2. Author the HTML brief: a single `.html` in the same dir that inlines the CSS from `$SKILL_DIR/brief.css` into a `