Skip to content
Back to skills

Launch Positioning

ASecurity

Find the one-sentence pitch for an open-source project or app — who it's for, what it replaces, why now, the proof, how it beats today's alternatives, and what we must not claim — and save it as the launch brief every post is built from. Use when a repo's pitch is vague, before writing a README or launch posts, or when the user asks 怎么介绍我的项目 / 一句话说清楚 / 定位 / tagline / elevator pitch.

  • 2 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added October 17, 2026
content-marketinggo

Works with

  • cli

Security analysis

A100/100

Scanned October 17, 2026

npx -y skills add 2104178150-ai/megaphone --skill launch-positioning --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Launch Positioning?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Launch Positioning
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/2104178150-ai-launch-positioning/badge)](https://www.skillsdirectory.com/skills/2104178150-ai-launch-positioning)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: launch-positioning
description: Find the one-sentence pitch for an open-source project or app — who it's for, what it replaces, why now, the proof, how it beats today's alternatives, and what we must not claim — and save it as the launch brief every post is built from. Use when a repo's pitch is vague, before writing a README or launch posts, or when the user asks 怎么介绍我的项目 / 一句话说清楚 / 定位 / tagline / elevator pitch.
---

# Launch positioning

Most launch posts fail before they're written: the author can't say in one breath who the
project is for and why it's better than what those people use today. This skill produces
`.megaphone/brief.md`, the single source every other Megaphone skill reads.

## Steps

Read `.megaphone/decisions.md` first if it exists, and record new answers there — or, with
no human available, your assumptions (and mark inferred fields `[inferred]` in the brief).

1. **Read before asking.** README (look for *why*, *motivation*, 初衷 sections), docs,
   examples, the oldest issues and the first commits often reveal the original itch. Note
   what the code actually does — features the README doesn't mention are common. Read
   `.megaphone/audit.md` if it exists and copy every do-not-say item from its risk section
   into *Claims we won't make*.
2. **Check the alternatives' current state.** For each alternative you'll contrast with,
   look at its latest release and its open issues/PRs for the feature you're comparing on.
   A competitor may be about to ship it. Date-stamp every contrast claim ("as of 2026-10").
3. **Interview briefly** (skip anything already answered):
   - What were you doing the day you started this? What was annoying?
   - Who else has that problem? Be specific: "Go developers who ship CLIs", not "developers".
   - What do they use today instead? (Another tool, a script, a spreadsheet, nothing.)
   - What's the moment it clicks — the first result that makes someone say "oh nice"?
   - What changed recently that makes this matter now?
   - Any proof: numbers you measured, users, a before/after?

   If the user isn't available, fill fields from the repo, mark them `[inferred]`, and leave
   the origin story as `[TODO]` — never invent it.
4. **Fill the canvas** below. Push for specifics; "fast", "simple" and "powerful" aren't
   positions — every README says them.
5. **Write three one-liners** in different styles, recommend one, and say why:
   - *Outcome*: "Turn X into Y in one command."
   - *Contrast*: "Like A, but for B." (only if A is well known to the audience)
   - *Pain*: "Stop doing X by hand."
6. **Check them** against the tests below, then save `.megaphone/brief.md`.

## Canvas

Two example columns: a developer tool and an end-user app.

| Field | Question | Developer tool | End-user app |
|---|---|---|---|
| Audience | Who exactly? | maintainers of small open-source repos launching for the first time | 网易云 users with years of playlists they don't want to lose |
| Trigger | When do they reach for it? | the night before posting on Hacker News | their membership expires, or songs in a playlist go grey |
| Today they use | What do they do now? | skim old blog posts and guess | screenshots and retyping |
| Promise | What changes for them? | a scored checklist and channel-specific drafts in ten minutes | a spreadsheet of every playlist in one click |
| Aha moment | First moment of value | pasting a repo URL and seeing the three fixes that matter | the exported file opening with every song listed |
| Why now | What changed recently? | AI agents can now do the drafting, but don't know community rules | more people switching between music apps |
| Proof | Why believe it? | public rubric; rules link to each platform's own guidelines | works on the five biggest platforms (list them) |
| Contrast | Why not the alternative? (dated) | generic marketing prompt packs don't know V2EX or Show HN etiquette (2026-10) | <tool X> doesn't support Chinese platforms (checked 2026-10) |
| Category | What shelf does it sit on? | launch checklist / developer marketing | playlist backup tool |

## Tests for a one-liner

- **Stranger test**: would someone who's never heard of it understand it out of context,
  e.g. in a list of post titles?
- **Swap test**: if you swap in a competitor's name, is it still true? If yes, it's not a
  position. In a crowded category where any plain outcome line fails this, let the
  bullets carry the difference — and say so.
- **Breath test**: can it be said aloud in one breath? (≈ 12 English words or ≈ 20 Chinese
  characters; Latin brand names inside Chinese count as one character each.)
- **No-buzzword test**: remove "AI-powered", "blazing", "next-gen", "revolutionary",
  「神器」「颠覆」. Does it still say something?
- **Founder-voice test**: every sentence in the author's voice ("I built it because…") is
  the author's own words or a `[TODO]`.
- **Claims test**: nothing in it appears under *Claims we won't make*.

## Template for `.megaphone/brief.md`

Write it in the user's language. Include the Chinese one-liner only if a Chinese channel or
README is planned (and the English one only if an English channel is).

```markdown
# Launch brief — <project>

**One-liner (EN):** …
**一句话(中文):** …
**Alternatives considered:** … / … (and why the chosen one wins)

| | |
|---|---|
| Audience | … |
| Trigger | … |
| Today they use | … |
| Promise | … |
| Aha moment | … |
| Why now | … |
| Proof | … |
| Contrast (as of <date>) | … |
| Category | … |

## Origin story (author's words only)
[TODO: ask the author] / "<quote>"

## Three bullets (for README and posts)
- **<benefit>** — <how>
- …

## Words to use / avoid
- Use: <words the audience itself uses — from issues, forum threads, reviews>
- Avoid: <jargon, buzzwords, internal names>

## Claims we won't make
- Legal or safety guarantees ("legal", "zero risk", "official", "零风险")
- Wording that reads as circumvention ("bypass", "破解", "突破限制", "抓包")
- Uses that invite misuse (e.g. looking up other people's data)
- <anything from audit.md → Risk & readiness>

## Standard disclaimer (for README and posts, if the project touches other platforms)
"<Project> is not affiliated with <platforms>. It <scope>; it does not <what it doesn't do>."

## Open questions
- [TODO] …
```

Write the Chinese one-liner natively, not as a translation: Chinese audiences respond to
concrete pain ("再也不用手动…") and a clear 「适合谁」.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.