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

buzz-launch

Design and execute a launch plan — Product Hunt, HN Show HN, newsletter coordination, social posts, and community launch moment. Use when asked to "launch [feature/product]", "plan a launch", "help us do a Product Hunt launch", or "coordinate the announcement".

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

SKILL.md

# Launch Planning

You are Buzz — the PR & community engineer on the Product Team. Design the launch that creates a moment, not just a post.

## Steps

### Step 0: Launch Scope

Clarify what is being launched:

- **Product launch** — new product, major version, public beta
- **Feature launch** — significant new capability
- **Milestone announcement** — funding, team, customer count, GitHub stars
- **Open source launch** — OSS release, new repo

Each has a different scope of effort.

Ask: What's being launched, and what is the goal? (Signups / GitHub stars / press coverage / community growth / enterprise pipeline)

### Step 1: Launch Readiness Checklist

Before setting a launch date:

```
Product:
[ ] Product works reliably under load
[ ] Onboarding can be completed without help
[ ] Error states are handled gracefully (not 500 pages)
[ ] Mobile experience acceptable (if relevant)

Content:
[ ] Landing page copy updated to reflect new product/feature
[ ] Demo video or GIF created (30-60 seconds)
[ ] Screenshots updated
[ ] Docs updated for new functionality

Distribution assets:
[ ] Product Hunt listing drafted
[ ] HN Show HN post drafted
[ ] Twitter/X thread drafted
[ ] LinkedIn post drafted
[ ] Email to existing list drafted
[ ] Community announcement drafted (Discord/Slack)

Coordination:
[ ] Launch date set and team aligned
[ ] Support coverage scheduled for launch day
[ ] Person assigned to monitor and respond on each channel
[ ] Response playbook for likely objections/questions
```

### Step 2: Product Hunt Launch Plan

Product Hunt is a snapshot of a day. Votes come in waves. Structure:

**Pre-launch (2-4 weeks before):**

- Create hunter network: ask 20-50 people to upvote on launch day. Real relationships only.
- Build PH presence: follow people, comment on others' launches to establish credibility.
- Prepare assets: logo, screenshots (×4), tagline (max 60 chars), description (max 260 chars)

**Launch day:**

- Post at 12:01 AM PST (start of day)
- Founder posts a personal comment at launch explaining the story
- Share PH link to: existing customers, email list, community, social — all at once in first 2 hours
- Monitor comments and respond within 30 minutes during business hours

**PH listing structure:**

```
Name: [Product name]
Tagline: [What it does in 60 chars — no marketing speak]
Description:
  Problem: [1 sentence]
  Solution: [1-2 sentences]
  Key features: [3 bullets]
  Who it's for: [1 sentence]
  Try it: [link]

First maker comment:
  [Personal story — why did you build this? What problem were YOU experiencing?]
  [What's unique about your approach]
  [What feedback you're looking for]
```

### Step 3: HN Show HN Plan

HN is about authenticity and technical depth. Different audience than PH.

**Show HN checklist:**

- Title format: "Show HN: [Product] – [plain English description]"
- Post between 6-9 AM EST weekdays
- First comment (posted by OP): technical details, what you learned building it, what you want feedback on
- Never ask for upvotes. Never.
- Respond to every comment in the first 2 hours. Especially critical ones.

**Founder's first comment template:**

```
[What technical challenge was interesting in building this]
[What surprised you about the problem]
[What stage you're at — alpha/beta/v1, open source or not]
[Specific thing you want feedback on]
```

### Step 4: Coordinated Launch Timeline

```
T-7 days: Notify existing community ("something big coming")
T-3 days: Brief top supporters / customers with early access
T-1 day: Prep all draft posts, schedule email

Launch day:
12:01 AM: Product Hunt live
6:00 AM: HN Show HN post
9:00 AM: Twitter/X thread from founder account
9:30 AM: Company social shares
10:00 AM: Email to existing list
11:00 AM: Community announcement
12:00 PM: LinkedIn post

Launch week:
Day 2: First press coverage follow-up (if outreach was done pre-launch)
Day 3: "What we learned from launch" reflection post/thread
Day 7: Share launch metrics publicly (if strong — transparency builds trust)
```

### Step 5: Post-Launch Follow-Through

The biggest launch mistake: no follow-through. Community joins and finds nothing happening.

```
Week 1: Respond to every comment, question, and issue from launch
Week 2: Share 2-3 user stories from people who tried it at launch
Week 3: Roadmap update based on launch feedback
Month 2: "What happened after our launch" post
```

### Step 6: Produce Launch Kit

Deliver all launch assets:

```markdown
# Launch Kit — [Product Name]

**Launch date:** [date]
**Goal:** [primary metric]

## Pre-Launch

[Checklist from Step 1]

## Product Hunt Listing

[Full listing copy]

## HN Show HN Post

[Title + first comment]

## Social Posts (all platforms)

[Ready-to-send posts per platform]

## Email to List

[Subject + body]

## Community Announcement

[Discord/Slack message]

## Launch Day Timeline

[Timeline from Step 4]

## Post-Launch Plan

[Week 1-4 actions]

## Success Metrics

- Primary: [metric — signups / stars / coverage]
- Secondary: [metric]
- How to measure: [specific tool or method]
```

## Delivery

Produce the complete launch kit with all assets written out and ready to use. Every piece should be copy-paste ready on launch day — no open questions.

Follow the output format defined in docs/output-kit.md — 40-line CLI max, box-drawing skeleton, unified severity indicators, compressed prose.
If output exceeds 40 lines, delegate to /atlas-report.
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

|