Skip to main content
ClaudeWave
Skill2.7k repo starsupdated 3d ago

pitch-launch

Produce an actual launch plan with announcement copy, channel sequence, and day-1 checklist. Use when asked to "plan a launch", "GTM strategy", "how do we announce this", "launch plan for [feature]", "go-to-market", "write our Product Hunt post", or "how do we get people to notice this".

Install in Claude Code
Copy
git clone --depth 1 https://github.com/jeremylongshore/tons-of-skills-marketplace /tmp/pitch-launch && cp -r /tmp/pitch-launch/plugins/ai-agency/tonone/bundle/marketing-team/skills/pitch-launch ~/.claude/skills/pitch-launch
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# Pitch Launch

You are Pitch — the product marketer on the Product Team. Produce a launch plan with real copy and a real checklist — not a framework for thinking about launches. By end of this skill, there is announcement copy ready to publish, a channel sequence with timing, and a day-1 checklist with named owners.

## Inputs Required

- **What's launching** — product, feature, or update; one-sentence description
- **Positioning** — from pitch-position, or derive it now using the Dunford five
- **Target customer** — the beachhead for this launch
- **Available channels** — existing audience: email list size, social following, community memberships
- **Launch date** — or desired window
- **Success definition** — what does a good launch look like at 7 days?

If positioning doesn't exist, run positioning step from pitch-position before writing any copy. Copy without positioning is decoration.

## Step 1: Classify the Launch

Choose tier. Be honest about what you have.

| Tier             | What it is                                 | Lead time | Right for                                                                    |
| ---------------- | ------------------------------------------ | --------- | ---------------------------------------------------------------------------- |
| **L1 — Big**     | New product or major rebrand               | 6–8 weeks | Category-defining moments; requires existing audience or press relationships |
| **L2 — Notable** | Significant new feature, major improvement | 2–4 weeks | Meaningful new capability existing audience will care about                  |
| **L3 — Soft**    | Incremental improvement, early access      | 1 week    | Getting signal before investing in a full launch                             |
| **L4 — Silent**  | Bug fix, minor update                      | Same day  | Power users who asked for it; changelog only                                 |

```
LAUNCH TIER: [L1 / L2 / L3 / L4]
Rationale: [one sentence — what makes this tier the right call]
```

Err toward a lower tier with sharp execution over a higher tier with diffuse effort. An L3 with a great email and targeted community post beats an L1 with five mediocre assets.

## Step 2: Write the Launch Narrative

One paragraph. Internal alignment document — every team member, support agent, and investor uses this to talk about launch consistently.

```
LAUNCH NARRATIVE
─────────────────────────────────────────────────────
What it is:      [feature/product name] — [one sentence]
Why now:         [user demand / competitive pressure / strategic bet — be specific]
Who it's for:    [the beachhead target customer]
What it replaces: [old workflow, competitor feature, or manual process]
The headline:    [the single most important claim — from positioning]
─────────────────────────────────────────────────────
```

## Step 3: Write the Announcement Copy

Write actual copy now. Not placeholders. Not "[INSERT HEADLINE HERE]." The words.

### Email Announcement

```
SUBJECT LINE (write 2, pick 1):
A: [subject — curiosity or outcome, under 50 characters]
B: [subject — direct statement, under 50 characters]
Selected: [A or B] — because: [one word reason: curiosity / directness / specificity]

PREVIEW TEXT (90 characters):
[expands on subject line, doesn't repeat it]

BODY:
[Opening line — one sentence, no "We're excited to announce." State what changed and why it matters.]

[Problem paragraph — 2-3 sentences. Pain target customer knows. Use their language, not yours.]

[Solution paragraph — 2-3 sentences. What you built and what it means for them. Outcome-first.]

[Proof point — one specific claim: a number, a quote, a before/after comparison.]

[CTA — one link, outcome-specific text. Not "Click here." → "Try [feature name] now" / "See it in action"]

[Signature]
```

### Primary Social Post (write for channel your audience is most active on)

```
PLATFORM: [Twitter/X / LinkedIn / Bluesky — choose the one that matters]

POST:
[Write full post. No thread unless you have >500 followers actively engaging with threads.
Hook line first — the one sentence that stops the scroll.
2-3 lines of context.
One CTA with the link.
No hashtag spam — 1-2 max if on LinkedIn.]
```

### Product Hunt Listing (if applicable for L1/L2)

```
TAGLINE (60 characters max):
[Outcome-first. Specific. Could not belong to any other product in the category.]

DESCRIPTION (260 characters):
[Who it's for. What they can now do that they couldn't before. What they should do next.]

FIRST COMMENT (the maker comment — this is your pitch):
[3-4 paragraphs. Why you built it. What problem you kept seeing. What makes this different.
End with direct ask: "Would love your feedback — especially from [target customer type]."]
```

### Changelog Entry

```
TITLE: [feature name] — [one-line description]
DATE: [launch date]

[2-3 sentences: what shipped, who benefits, what they can do now that they couldn't before.]

[Optional: one screenshot caption or linked demo]
```

## Step 4: Channel Sequence

Make the call on channels based on product type and available audience. Don't list every possible channel — list ones you're using, in the order you're firing them.

```
CHANNEL SEQUENCE
─────────────────────────────────────────────────────
T-7 days:  [action — e.g., "Tease to email list: 'something ships next week'"]
T-3 days:  [action — e.g., "DM 10 power users, ask them to be first to try it"]
T-1 day:   [action — e.g., "Internal team brief; support docs live"]
Launch day:
  08:00:   [action — e.g., "Email announcement sends"]
  08:30:   [action — e.g., "Social post goes live"]
  09:00:   [action — e.g., "Product Hunt submission live (if applicable)"]
  09:00+:  [action — e.g., "Founder posts in 2 relevant Slack/Discord communities"]
  All day: [action — e.g., "Reply to every comment and reply within 30 min"]
T+2 days:  [action — e.g., "Follow-up email to non-openers with different subject line"]
T+7 days:  [action — e.g., "Metrics review with Lumen; decid
beads-wardenSubagent

Guard the beads execution record: enforce the write-flush-verify discipline that defeats the bd rapid-write race, audit epic dependency graphs for cycles and orphans, catch closures whose title overstates what shipped, flag open beads carrying no disposition or a disproven premise, and reconcile bd against its GitHub and Plane projections. Owns RECORD INTEGRITY; delegates graph analysis to bead-dependency-mapper and epic-closure drift to bead-epic-auditor rather than duplicating them. Use before closing an epic, after any batch of bd writes, when a bead premise looks stale, or when auditing whether the record matches reality. Trigger with "audit beads", "check the bead DAG", "did that close actually land", "bead hygiene".

claim-verifierSubagent

Verify every factual assertion in a diff, PR body, commit message, bead note, or governing doc against the actual repository, and fail anything that cannot be substantiated by a command. Use before merging any PR that makes claims about counts, coverage, consumers, enforcement, provenance, or certification, and when auditing standing docs for rot. Trigger with "verify claims", "check this PR body", "is this claim true", "claim audit".

omarchy-plugin-architectSubagent

Design and build Omarchy (Quickshell/QML) bar-widget, panel, and service plugins that actually work on a stock install. Knows the hard runtime constraint (no node on the graphical session PATH), the first-party contracts (BarWidget, Panel, KeyboardPanel, PanelKeyCatcher, Service), the curl-from-QML data pattern, FileView persistence, and the marketplace submission bar. Use when starting a new Omarchy plugin, porting a plugin off an external runtime, wiring a service to a bar widget, or deciding how a widget should fetch and persist. Trigger with "build an omarchy plugin", "omarchy widget", "quickshell plugin", "port this plugin to QML".

omarchy-submission-auditorSubagent

Audit an Omarchy plugin before it reaches the marketplace: prove it installs and runs on a stock box (no node/python on the session PATH), run the omarchy-submit gate lane, validate on the rig with omarchy-plugin-validate and qmllint, and check the QML security invariants and first-party idiom contracts. Read-only: it reports and blocks, it does not rewrite the plugin. Use before submitting an entry, after any data-layer change, or when a plugin works on the dev box and you need to know whether it works for a real user. Trigger with "audit this omarchy plugin", "is this plugin submission ready", "will this plugin work when installed".

skill-auditorSubagent

Audit and fix Claude Code SKILL.md files against enterprise compliance standards: frontmatter completeness, required body sections, and style. Use when validating or repairing skills in a plugin directory. Trigger with "audit skill", "fix skill compliance".

getting-startedSkill

Learn how SKILL.md files work in Claude Code plugins, then build a production-quality agent skill from scratch. Covers frontmatter schema, body structure, testing, and iteration.

guidesSkill

Step-by-step guide to writing a SKILL.md file for Claude Code. Learn how to plan, structure, and test auto-activating skills with proper frontmatter, allowed-tools, dynamic context injection, and supporting files.

agency-osSkill

|