Claude-skill-registry launch-announcement
Use when creating internal product launch announcements - gathers information from PRDs and user input to write customer-centric feature launch communications for internal teams
git clone https://github.com/majiayu000/claude-skill-registry
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/launch-announcement" ~/.claude/skills/majiayu000-claude-skill-registry-launch-announcement && rm -rf "$T"
skills/data/launch-announcement/SKILL.mdLaunch Announcement
Purpose
Create crisp, clear, customer-centric internal launch announcements for new features and experiments. This skill generates structured communication for cross-functional teams (product, eng, design, data, sales, CS, marketing, leadership) about shipped features.
When to Use This Skill
Activate when:
- User invokes
/launch-announcement - Writing internal launch announcement for shipped feature
- Communicating feature release to internal stakeholders
- Documenting feature launch after deployment
When NOT to use:
- External customer communications (press releases, blog posts)
- Pre-launch feature previews or teasers
- Roadmap updates (use
instead)roadmap-updating
Workflow
Step 1: Announce and Research
Announce to user: "I'm researching existing documentation to pre-fill the announcement template. Looking for PRDs, experiments, and related product documentation."
Search workspace:
- Look in
for matching PRDdatasets/product/prds/ - Check
for feature referencesdatasets/product/roadmap.md - Search
for customer signals related to the featuredatasets/meetings/
Report findings: Tell user what you found and what information you can pre-fill.
Step 2: Gather Missing Information
Ask user for information not found in documentation:
Required inputs:
- Org/Team name: Which team shipped this?
- Feature name: What is the feature called?
- Short descriptor/tagline: Brief descriptor for title
- Rollout details: GA, beta, experiment, A/B test? Who is exposed?
- What actually shipped: Confirm specifics match documentation (often differs)
Optional inputs (ask if not found):
- Customer segment/persona: Who is this for?
- Customer problem details: Expand on PRD's customer statement if needed
- Detailed components that shipped: What specific pieces were delivered?
- Surfaces/pages where it appears: Where in product?
- "Coming soon" items + timing: What's next and when?
- Success metrics (baseline + targets): Actual values, not assumptions
- Monitoring/VOC plans: How will you track this?
- Early success story: Any early customer wins?
- Contributor list by function: Who to thank?
- Resource links: Videos, FAQs, docs, playbooks
CRITICAL: Never fabricate numbers, names, or metrics. Always ask user when information is missing.
Step 3: Structure Announcement
Follow this exact section ordering:
1. Launch Title
Format:
[emoji] [Org/Team name] launches [Feature name] [short descriptor] [emoji]
Example emojis:
:rocket:, :sparkles:, :chart_with_upwards_trend:
2. Context & Overview (1-2 paragraphs)
- Short history of the problem
- How it affected customers
- What this launch changes and why it matters
- Customer-first language (their pain, not just tech)
Source from PRD background section if available.
3. Customer Problem
Structure as persona statement:
I AM [who the customer is] I AM TRYING TO [their goal] BUT [what's blocking them] BECAUSE [root cause] WHICH MAKES ME FEEL [emotional impact]
Source from PRD's customer statement if available.
4. What Was Launched?
- 1-2 sentence summary (GA/beta/experiment, exposure)
- Bullet list of key components with:
- What it is
- How it works (high level)
- Why it matters for customers
- Where it shows up in product
- Coming soon items with timeframes
Always confirm with user - shipped product often differs from PRD.
5. From → To (value shift)
Show before/after in bullets:
- [Old state] → [New state] - [Limited capability] → [Comprehensive capability] - [No insight] → [Clear confidence]
Source from PRD, but confirm with user for accuracy.
6. How Will We Define Success?
List metrics with baseline and target:
- [Metric description] - Baseline: [value and unit] - Target: [desired value and % change]
NEVER assume metrics. Always confirm with user. Source from PRD/EDD but validate.
7. What's Next?
- Current status (experiment, phase 1, etc.)
- What you'll be monitoring
- Future phases or related initiatives
- Dependencies or upcoming improvements
Check roadmap, but validate with user.
8. Early Success Story (optional)
2-4 sentences about real customer impact already observed.
Only include if user provides specific story. Do not fabricate.
9. Shout Outs & HUGE THANKS
- Brief paragraph acknowledging cross-functional effort
- List people grouped by function:
- Product, Design, Engineering, Data Science/Analytics
- PMM, Sales/CSM/Support
- Trust & Safety/Policy/Legal
- Leadership/Sponsors
- Special thanks
10. Resources (optional)
- Demo/walkthrough videos
- Internal docs, FAQs, playbooks
- Enablement materials
Only include if links exist. Do not create placeholder URLs.
Step 4: Write Announcement File
Output location:
datasets/product/launch-announcements/{YYYY}/launch-{feature-slug}.md
Format requirements:
- Markdown with bold section headers
- Blank lines between sections
- Bullet lists where indicated
- Light, work-appropriate emojis (similar to examples)
Tone:
- Clear, confident, customer-first
- Appropriately celebratory ("we shipped!")
- Use "we" for team, "our customers" for users
- Avoid jargon unless standard in org
Acceptable jargon:
- "C1" = customer of ours (brands, businesses)
- "C2" = business' customers (subscribers, members)
Step 5: Confirm with User
Show user the announcement and ask:
- "Does this accurately reflect what was shipped?"
- "Any corrections or additions needed?"
Quality Gates
Information Accuracy:
- No fabricated numbers, names, or metrics
- Shipped features confirmed with user
- All metrics validated (baseline + target)
Citation Requirements:
- Reference PRDs and source documents when used
- Customer quotes attributed with dates
Style Compliance:
- Bold section headers used consistently
- Blank lines between sections
- Emojis used appropriately (not overdone)
Common Mistakes
| Mistake | Fix |
|---|---|
| Fabricating metrics or baselines | Always ask user for actual values |
| Assuming PRD matches shipped product | Confirm what actually shipped with user |
| Creating placeholder URLs | Only include links that exist |
| Over-using emojis | Light, work-appropriate emojis only |
| Making up success stories | Only include if user provides specific story |
| Skipping research phase | Always search for PRD/docs first |
Success Criteria
- Announcement file written to correct location
- All 9 required sections included (10 if resources available)
- No fabricated information (TBD if unknown)
- Customer-centric language throughout
- User confirms accuracy of shipped features
- Metrics validated with user
- Template structure followed exactly
Related Skills
- prd-creation: Source for customer problem and requirements
- meeting-synthesis: Source for customer signals and quotes
- content-style: General content quality standards