Go-to-market launch engine. Use when converting a validated offer spec into ready-to-execute landing page copy, launch posts, GitHub README, email sequence, launch checklist, A/B test spec, and kill criteria.

Pitch

Transform an offer-scope build spec into a complete go-to-market launch kit. Produces ready-to-execute landing page copy, platform-specific launch posts, a GitHub product README (with product structure sketch for technical domains), a post-purchase email sequence, an hour-by-hour launch checklist, an A/B test spec, and refined kill criteria — all grounded in persona data, SWOT findings, and offer-scope positioning.

Step 0: Load Conventions

Before doing ANYTHING, read the shared conventions file:

Read ${SKILLS_DIR}/_conventions.md

This file defines: canonical vault path, folder-to-type mapping, frontmatter contract, valid statuses, tag hierarchy, cross-reference syntax, and the PipelineEnvelope schema. All output from this skill MUST conform to those conventions. If there is a conflict between this SKILL.md and _conventions.md, the conventions file wins.

Pipeline Position

signal-scan -> decision-log -> persona-extract -> swot-analysis -> offer-scope -> positioning -> **pitch** -> hunter-log

This skill consumes the output of offer-scope, persona-extract, swot-analysis, decision-log, and signal-scan, and feeds into hunter-log for execution tracking. The pitch output is the complete “go live” package — everything needed to launch the product.

When to Use

Converting a validated offer spec into ready-to-execute launch materials
Generating landing page copy grounded in persona language and offer-scope positioning
Creating platform-specific launch posts that follow the 80/20 value-first rule
Building a GitHub product README that serves as both documentation and conversion engine
Drafting a post-purchase email sequence for nurturing and community building
Planning a day-by-day launch execution sequence with specific times and platforms
Defining what to test (headlines, prices, channels) once traffic is flowing
Sharpening kill criteria inherited from offer-scope with pitch-level specifics

Trigger Phrases

“Build the launch kit for [product]”
“Create pitch materials from this offer spec”
“I need landing page copy for [product]”
“Generate the go-to-market package”
“Turn this offer scope into launch-ready materials”
“/pitch [offer-scope output]”
“Deploy artifacts from [pitch doc]”
“Split the pitch into deployable files”
“/pitch —deploy-only [pitch-slug or path]“

Deploy-Only Mode

Reads an existing pitch document from the vault and splits/deploys its artifacts without re-generating content. Use when:

A pitch was generated before the deployment extensions existed
You want to re-deploy artifacts after editing the pitch document
Testing the deployment pipeline against an existing pitch

Deploy-Only Input

One of:

Pitch slug: e.g., devops-decision-kit-pitch-2026-02-08 (searches Admin/Product-Discovery/Pitches/)
Full vault path: e.g., Admin/Product-Discovery/Pitches/devops-decision-kit-pitch-2026-02-08.md
Absolute path: the full filesystem path to the pitch markdown

Optional:

Launch date: ISO date for kanban task dates. If omitted, uses relative dates (T-7, T+0, T+1, etc.)
Skip list: Deployment phases to skip (e.g., --skip emails,kanban if those are already deployed)

Deploy-Only Workflow

Existing pitch markdown (from vault)
    |
Step 1: Parse pitch document into sections
    |
Step 2: Check what is already deployed (launchpad branch? seeds exist? kanban exists?)
    |
Step 3: Deploy missing artifacts only
    |    ├── Phase 2.4: Launch posts → Obsidian content seeds
    |    ├── Phase 3e: Landing page copy → index.html on launchpad branch
    |    ├── Phase 4.6: Email sequence → individual files on launchpad branch
    |    ├── Phase 5.6: Launch checklist → Obsidian kanban
    |    └── Phase 7.6: Kill criteria → Obsidian Tasks on pitch doc
    |
Step 4: Update Pipeline tracker
    |
Output: Report of what was deployed and where

Parsing Contract

The deploy-only mode reads the pitch markdown and locates content by H2 section headers. The pitch doc may use either short headers (## Launch Posts) or phase-numbered headers (## Phase 2: Launch Posts). Match on the section name, ignoring any Phase N: prefix.

Pitch Section	Header (either format)	Parser	Deploy Phase
Landing Page Copy	`## Landing Page Copy` or `## Phase 1: Landing Page Copy`	Read all subsections (### Headline through ### Call to Action) and pass to Phase 3e HTML generator	3e (index.html on launchpad branch)
Launch Posts	`## Launch Posts` or `## Phase 2: Launch Posts`	Split by `### {Platform}: {Title}`, `### Reddit r/{sub} Post`, or `### Twitter/X Thread`	2.4 (Obsidian seeds)
Email Sequence	`## Email Sequence` or `## Phase 4: Email Sequence`	Split by `### Email {N}: {Subject} (Day {N})`	4.6 (individual files)
Launch Checklist	`## Launch Checklist` or `## Phase 5: Launch Checklist`	Split by `### Pre-Launch`, `### Launch Day`, `### Week 1`, `### Ongoing Cadence`, `### Month 2-3 Growth`	5.6 (Obsidian kanban)
Kill Criteria	`## Kill Criteria` or `## Phase 7: Kill Criteria`	Read `### 7.1 Week 1 Threshold`, `### 7.2 Month 1 Threshold`, `### 7.3 Month 3 Threshold` (also accepts unnumbered `### Week 1`, etc.)	7.6 (Obsidian Tasks)

If a section is missing or cannot be parsed, skip that deployment phase and warn the operator. Do not fail the entire deploy because one section is malformed.

Deploy-Only Checks

Before deploying each artifact:

Content seeds (Phase 2.4): Check if {vault}/Writing/Content-Briefs/{product-slug}-{platform}-seed-*.md already exists. If yes, skip and warn (or append under ## Update: {timestamp} per conventions).
Landing page HTML (Phase 3e): Check if index.html exists on the launchpad branch root. If yes, skip and warn. If the branch does not exist, warn that Phase 3d (launchpad branch creation) should run first.
Email files (Phase 4.6): Check if emails/ directory exists on the launchpad branch. If yes, skip and warn. If the branch does not exist, warn that Phase 3d (launchpad branch creation) should run first.
Kanban (Phase 5.6): Check if {vault}/Admin/Product-Discovery/Pitches/{product-slug}-launch-checklist.kanban.md exists. If yes, skip and warn.
Review reminders (Phase 7.6): Check if the pitch markdown already has a ## Review Reminders section. If yes, skip and warn.

Deploy-Only Output

Returns a deployment report:

{
  "pitch_ref": "devops-decision-kit-pitch-2026-02-08",
  "deployed": {
    "landing_page_html": "index.html (on {product-slug} branch)",
    "content_seeds": ["path/to/seed-1.md", "path/to/seed-2.md"],
    "email_files": ["emails/email-1-welcome.md", ...],
    "kanban": "path/to/launch-checklist.kanban.md",
    "review_reminders": "appended to pitch markdown"
  },
  "skipped": {
    "kanban": "already exists at path/to/..."
  },
  "warnings": ["No launch date specified; using relative dates"]
}

Prerequisites

Before starting, the following must be available:

Offer-scope output — A completed offer-scope result containing: product name, format, price, value equation, build spec, positioning (headline, subheadline, bullet points, objection handlers, social proof angle, guarantee), distribution plan, revenue model, and kill criteria
Persona extraction output — The persona used by offer-scope, containing: pain stories (with situation/pain/workaround/emotional state/evidence), decision triggers, objections, willingness-to-pay data, and channel behavior
SWOT analysis data — The SWOT for this hypothesis, containing: validated strengths, key weaknesses, opportunities, threats, risk registry, and moat assessment
Positioning data (optional, recommended) — If a positioning skill run exists, its output becomes the PRIMARY source for: landing page headline (from messaging hierarchy lead message), problem section (from competitive alternatives), copy anti-rules (from anti-messaging). When positioning output is available, use it instead of offer-scope Phase 5 positioning. If no positioning output exists, fall back to offer-scope positioning as before.
Decision log entry — The decision record for the chosen opportunity
Signal scan data — The original signal scan with PAIN, SPEND, COMPETITIVE, and AUDIENCE signals

If any of these are missing, prompt the user to run the upstream skill first or provide the data manually. The pitch skill is a synthesis layer — it assembles and refines upstream outputs into execution-ready materials, not a research layer.

Input

The skill expects the following input structure (assembled from upstream skill outputs):

interface PitchInput {
  offer: {
    product_name: string
    format: string
    price_point: string
    ship_time: string
    value_equation: {
      dream_outcome: string
      perceived_likelihood: string
      time_delay: string
      effort_sacrifice: string
    }
    build_spec: {
      deliverable: string
      transformation: string
      sections: { title: string, estimated_time: string, content_type: string }[]
    }
    positioning: {
      headline: string
      subheadline: string
      bullet_points: string[]
      objection_handlers: { objection: string, counter: string }[]
      social_proof_angle: string
      guarantee: string
    }
    distribution_plan: {
      launch_channel: string
      launch_strategy: string
      ongoing_channels: string[]
      email_capture: boolean
    }
    revenue_model: {
      unit_price: number
      first_week_target: { units: number, revenue: number }
      first_month_target: { units: number, revenue: number }
      assumptions: string[]
    }
    kill_criteria: string[]
  }
  persona: {
    persona_name: string
    pain_stories: {
      situation: string
      pain: string
      current_workaround: string
      emotional_state: string
      evidence: string
    }[]
    decision_triggers: { trigger: string, urgency: string, channel: string }[]
    objections: { objection: string, counter: string }[]
    willingness_to_pay: { range: string, evidence: string, anchor_products: string[] }
    channels: { platform: string, behavior: string }[]
  }
  swot: {
    verdict: string
    validated_strengths: string[]
    key_risks: string[]
    modifications: string[]
    moat_assessment: { current_strength: string, timeline: object }
  }
  positioning?: {
    lead_message: string                // headline source (overrides offer.positioning.headline)
    category_frame: string              // subheadline / positioning line
    primary_hook: string                // above-the-fold emotional hook
    anti_messaging: { phrase: string, use_instead: string }[]  // copy rules
    competitive_alternatives: string[]  // problem section source
    icp_title: string                   // copy targeting
    first_conversation_moats: string[]  // credibility claims
    positioning_canvas_ref: string      // artifact slug for cross-reference
  }
  domain: string
  opportunity: string
  offer_ref: string
  persona_ref: string
  swot_ref: string
  positioning_ref?: string  // slug of the positioning-canvas artifact
  decision_ref: string
  signal_scan_ref: string
}

Workflow

Offer Spec + Persona + SWOT + Decision + Signal Scan (from upstream)
    |
Phase 1: Landing Page Copy (complete, ready to paste)
    |
Phase 2: Launch Posts (platform-specific, ready to publish)
    |
Phase 3: GitHub Product Repo (3a: structure + 3b: README + 3c: hero + 3d: branch/PR + 3e: landing page HTML)
    |
Phase 4: Email Sequence (3-5 emails, post-purchase nurture)
    |
Phase 5: Launch Checklist (hour-by-hour execution plan)
    |
Phase 6: A/B Test Spec (what to test once traffic flows)
    |
Phase 7: Kill Criteria Refinement (time-bounded, measurable)
    |
Phase 8: Slide Deck (Slidev presentation with extracted SVG diagrams)
    |
Output: JSON spec + Markdown summary -> vault

Phase 1: Landing Page Copy

Generate complete, paste-ready landing page copy with headline, subheadline, above-the-fold hook, problem section (minimum 3 persona pain story references), solution section, what’s inside breakdown, social proof strategy, pricing with value stack and guarantee, FAQ mapped to persona objections (minimum 5), and primary/secondary CTAs. Every line must trace to persona data or offer-scope positioning.

Read ${SKILLS_DIR}/pitch/references/landing-page-template.md

Phase 2: Launch Posts

Generate 2-3 platform-specific posts following the 80/20 value-first rule. Includes primary channel post, LinkedIn version, and Twitter/X thread. Each post is ready to publish and provides genuine standalone value. Also writes Obsidian content seeds for the content-planner pipeline and integrates with the ::linkedin convention for LinWheel scheduling.

Read ${SKILLS_DIR}/pitch/references/launch-posts-templates.md

2.5 LinkedIn Launch Post Convention (`::linkedin`)

For LinkedIn launch posts, write them to Obsidian with the ::linkedin prefix in the note body (before the post content). This triggers the OpenClaw ambient pipeline:

OpenClaw detects the ::linkedin prefix in the Obsidian note
Pipes the note content to LinWheel (the LinkedIn content generator + scheduler)
The operator reviews and approves the post in LinWheel
LinWheel schedules and publishes to LinkedIn

Format: Write the LinkedIn seed to {vault}/Writing/Content-Briefs/{product-slug}-linkedin-seed-{YYYY-MM-DD}.md with ::linkedin as the very first line of the file (line 1, before frontmatter). NOT after frontmatter — BEFORE it. The ::linkedin trigger must be byte 0 of the file or the OpenClaw pipeline won’t fire. Frontmatter follows on line 2+. This makes it a live launch post that can be approved and scheduled, not just a draft.

The full pipeline: pitch skill → Obsidian seed → OpenClaw → LinWheel → LinkedIn publication.

Phase 3: GitHub Product README

Multi-sub-phase: 3a produces product structure sketch (technical domains only, enriched with buildlog data), 3b produces README conversion copy, 3c generates hero image via ComfyUI (or writes image intent comment), 3d deploys to launchpad repo branch with PR, and 3e generates a single-file dark-theme landing page HTML from Phase 1 copy with full design system, OG tags, and mobile responsiveness.

Read ${SKILLS_DIR}/pitch/references/github-readme-template.md

Phase 4: Email Sequence

Generate 5 post-purchase emails: welcome/delivery (Day 0), quick win (Day 2), story/credibility (Day 4), objection handler (Day 6), and community invite (Day 7). Each email has one job, specific subject lines, and practitioner-to-practitioner tone. Outputs individual email files to the launchpad branch emails/ directory.

Read ${SKILLS_DIR}/pitch/references/email-sequence-template.md

Phase 5: Launch Checklist

Step-by-step execution plan: pre-launch setup (Days -7 to -1) with specific tools and time estimates, hour-by-hour launch day sequence, daily Week 1 follow-up actions, ongoing cadence (Weeks 2-4), and Month 2-3 growth actions. Outputs an Obsidian Kanban board with dated tasks.

Read ${SKILLS_DIR}/pitch/references/launch-checklist-template.md

Phase 6: A/B Test Spec

Define testable variables for solo operators with 100-500 visitors: 2-3 headline variants with rationale, 2-3 price variants cross-referenced with SPEND data, ranked channel priority, metrics with targets and measurement methods, and decision thresholds defined before testing. Sequential testing approach — one variable at a time.

Read ${SKILLS_DIR}/pitch/references/ab-test-spec.md

Sharpen kill criteria from offer-scope and SWOT with pitch-level specifics: Week 1, Month 1, and Month 3 thresholds with exact numbers and actions. Includes qualitative signal interpretation (iterate vs pivot vs kill), pivot triggers with direction, and Obsidian Tasks output with review reminder dates queryable by Dataview.

Read ${SKILLS_DIR}/pitch/references/kill-criteria-template.md

Phase 8: Slide Deck (Slidev)

Generate a Slidev presentation summarizing the validation pipeline output. The deck lives in launchpad/deck/ and deploys alongside the landing page.

8.1 Structure

The deck is a single slides.md file using Slidev’s markdown syntax. Global config in frontmatter, per-slide frontmatter between --- separators. Speaker notes go in  comments at the bottom of each slide.

Required slides (in order):

Cover — product name + validation date (use layout: cover in global frontmatter)
Opportunity — the gap diagram
Evidence Wall — signal count + key stats
Reddit Voices — 3 direct quotes with source citations
SDP Scoring — bar chart of opportunity ranking
Personas — persona cards with WTP
Four Forces — push/pull/inertia/anxiety
Two Offers — offer tiers side by side
Curriculum Stack — week-by-week breakdown
Revenue Model — bar chart of revenue streams
Revenue Breakdown — table with unit economics (Stream / Unit Economics / Annual Estimate)
Competitive Map — price vs depth scatter plot
Execution Calendar — timeline with milestones and kill gate
Kill Criteria — gate cards with thresholds
Bias Check — status indicators per bias type
Next Steps — table with Milestone / Deadline / Kill Condition columns
Appendix — asset map linking to all pipeline artifacts
Closing — pipeline attribution

8.2 SVG Conventions

All diagrams are extracted SVG files in deck/public/. Reference them with <img src="/filename.svg"> tags. NEVER inline complex SVGs in the markdown — Vue’s template compiler will mangle them.

SVG style rules:

Font: font-family="'Inter', sans-serif" on all text elements. Never use Caveat, cursive, or handwriting fonts.
Displacement filter: feDisplacementMap scale="0.4" max. Subtle texture, not wobbly hand-drawn.
Color palette: background #0d1117, text #eee0cc, muted #8b949e, coral #e88072, red #f87171, green #4ade80, yellow #facc15
XML safety: Always escape < as < in SVG text content. Unescaped < breaks the SVG parser.
Sizing: Use viewBox for dimensions. Set style="width:100%;max-width:NNNpx;" on the root <svg> element.
Text overflow: Ensure text fits inside containing boxes. For label text inside bounded shapes, measure the text width against the shape width and reduce font-size or widen the shape if needed.
Overlap: Maintain minimum 50px center-to-center spacing between elements with labels. Check that label text from one element doesn’t collide with the heading of the next.

SVG animation rules:

Use CSS @keyframes inside <style> blocks within the SVG for auto-playing animations (pulse, blink, breathe). These work in <img> tags.
For hover interactivity, use <object data="..." type="image/svg+xml"> instead of <img>. Add :hover CSS rules inside the SVG’s <style> block.
Good candidates for animation: alert indicators (blink), kill/flag states (pulse), highlighted elements (breathe/glow).

8.3 Slidev Config

theme: default
fonts:
  sans: Inter
  mono: Fira Code
  provider: google
transition: slide-left
css: unocss
drawings:
  persist: false

Use style.css for global styles (background, heading colors, v-click animation overrides). Do not use scoped <style> blocks in slides.

8.4 Speaker Notes

Every slide gets presenter notes in  comments. Notes must:

State what the slide shows and why it matters
Reference specific numbers, sources, or upstream pipeline data
Be written in direct, conversational tone — not LLM summary voice
Avoid em-dash chains, tricolons, performative honesty, or “landscape/tapestry/crucible” vocabulary

8.5 Content Seed Trigger

If generating a LinkedIn content seed, the ::linkedin trigger tag MUST be byte 0, line 1 of the file — BEFORE frontmatter. This triggers the OpenClaw → LinWheel → LinkedIn pipeline.

::linkedin

---
type: content-brief
...

Output

The pitch produces multiple output artifacts across the vault and launchpad repo.

Vault path: ${VAULT}/

For the complete output markdown structure (frontmatter, all sections, deployment outputs):

Read ${SKILLS_DIR}/pitch/references/output-template.md

Primary Outputs (Vault)

1. JSON Spec: `{vault}/Admin/Product-Discovery/Pitches/{product-slug}-pitch-{YYYY-MM-DD}.json`

Structured data following the schema in references/output-schema.json. Must validate against that schema.

2. Markdown Summary: `{vault}/Admin/Product-Discovery/Pitches/{product-slug}-pitch-{YYYY-MM-DD}.md`

Human-readable launch kit containing all phase outputs in the structure defined by the output template.

Deployment Outputs (Launchpad Repo + Vault)

3. Launchpad Product Branch: `github.com/Peleke/launchpad` branch `{product-slug}`

Full product directory structure from Phase 3a
Product README from Phase 3b
Hero image from Phase 3c (or HTML comment with image intent)
emails/ directory with individual email files from Phase 4.6
PR opened against main for operator review (Phase 3d)

3b. Landing Page HTML: `index.html` on launchpad branch root

Single-file HTML landing page generated from Phase 1 copy (Phase 3e)
Dark theme, mobile responsive, zero dependencies
Open Graph meta tags for social sharing
Immediately deployable via Vercel branch preview
Preview URL: https://launchpad-git-{product-slug}-kwayet-fs-projects.vercel.app

4. Content Seeds: `{vault}/Writing/Content-Briefs/{product-slug}-{platform}-seed-{YYYY-MM-DD}.md`

One file per launch post (Phase 2.4)
Frontmatter: type: content-brief, status: backlog, platform tag
Picked up by content-planner for full brief generation after operator review

5. Launch Checklist Kanban: `{vault}/Admin/Product-Discovery/Pitches/{product-slug}-launch-checklist.kanban.md`

Obsidian Kanban board with Pre-Launch, Launch Day, Week 1, Ongoing columns (Phase 5.6)
Tasks have dates, checkable on mobile via iCloud sync

6. Review Reminders: Appended to pitch markdown in vault

Obsidian Tasks format with dates and #hunter/review tags (Phase 7.6)
Week 1, Month 1, Month 3 review dates
Queryable by Obsidian Tasks and Dataview plugins

7. Pipeline Tracker: `{vault}/Admin/Product-Discovery/Pipeline.md`

Table of all products with branch links, preview URLs, status
Updated by pitch skill when creating a new product
Format:

| Product | Branch | Preview URL | Price | Status | Pitch Date |
|---------|--------|-------------|-------|--------|------------|
| {name} | [{slug}](https://github.com/Peleke/launchpad/tree/{slug}) | [Preview]({vercel-url}) | ${price} | spec | {date} |

Vault Output Contract

All vault output files are written to the Obsidian vault (iCloud-synced):

${VAULT}/

Pitch files: Admin/Product-Discovery/Pitches/

Filename format: {product-slug}-pitch-{YYYY-MM-DD}.md and {product-slug}-pitch-{YYYY-MM-DD}.json

Content seeds: Writing/Content-Briefs/

Filename format: {product-slug}-{platform}-seed-{YYYY-MM-DD}.md

Launch kanban: Admin/Product-Discovery/Pitches/

Filename format: {product-slug}-launch-checklist.kanban.md

Pipeline tracker: Admin/Product-Discovery/Pipeline.md

Rules:

If a file already exists at the target path: APPEND under ## Update: {ISO timestamp}, do NOT overwrite
Frontmatter MUST include: type: pitch, date, status: draft, tags (minimum: hunter/pitch, hunter/domain/{slug})

Resources

references/

output-schema.json — JSON Schema for the structured pitch output. Load when producing the JSON file to validate against.
landing-page-template.md — Phase 1: landing page copy structure, section breakdown, copy rules
launch-posts-templates.md — Phase 2: platform-specific post templates, 80/20 rule, Obsidian seed output, ::linkedin convention
github-readme-template.md — Phase 3: product structure sketch, README copy, hero image, launchpad branch, landing page HTML design system
email-sequence-template.md — Phase 4: 5-email post-purchase sequence, tone rules, file output format
launch-checklist-template.md — Phase 5: pre-launch through Month 2-3 execution plan, Obsidian Kanban output
ab-test-spec.md — Phase 6: headline/price variants, channel priority, metrics, decision thresholds
kill-criteria-template.md — Phase 7: time-bounded thresholds, qualitative signals, pivot triggers, Obsidian Tasks output
output-template.md — Full markdown output structure and deployment output inventory

README.md

The full Launch Architecture framework reference, including intellectual lineage (Ogilvy, Schwartz, Halbert, Godin, Dunford, Fitzpatrick, Lavingia, Hoy, McKenzie), detailed methodology, anti-patterns, and calibration examples. Consult for deep framework questions during a pitch session.

Quality Checklist

Run this checklist before delivering the pitch:

Use this skill

Option 1 — Claude Code plugin marketplace

Install directly from within Claude Code. Best for interactive use.

Step 1 — Add the brunnr marketplace (one-time):

/ plugin marketplace add Peleke/brunnr

Step 2 — Install the skill:

/ plugin install pitch@brunnr-skills

Step 3 — Use it:

/ pitch

Every skill in the brunnr marketplace passes a 7-class security scan before distribution. See Claude Code plugin docs for more on marketplaces.

Option 2 — brunnr CLI

Best for batch installs, CI pipelines, or managing skills across multiple projects.

Install brunnr (one-time):

$ uv tool install brunnr # recommended

$ pipx install brunnr # or pipx

$ pip install brunnr # or pip

Install the skill:

$ brunnr install pitch

Writes to ./skills/pitch/SKILL.md in your project — Claude Code auto-discovers it as a slash command. brunnr shows you the skill source for review before writing; use --yes to skip.