Launch monitor

Use this skill when a product launch is live and you need to know what press, social, and developer communities are saying — and what to do about it.

How to use it

Claude Code
  1. Run the line below. It pulls the whole folder into ~/.claude/skills/launch-monitor.
  2. Describe your job in plain words. Claude Code follows the skill from there.
Claude Code — installs the whole folder, not just SKILL.md
npx degit swan-gtm/gtm-skills/skills/uri-knorovich/launch-monitor#main ~/.claude/skills/launch-monitor

For one project only, change the path to .claude/skills/launch-monitor.

Claude (web or desktop app)
  1. On this page open ⋯ → Download .md.
  2. Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
  3. Pick the file and Save. Claude shows the name and description and runs a security scan.
  4. Check the skill is switched on.
  5. Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
  1. ChatGPT: make a Project and paste it into Instructions.
  2. Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
  • Check which app you pasted it into — the steps above name the right one.
  • Some skills need the paid tier of Claude or ChatGPT.
Step-by-step guide with screenshots · Ask in the forum

Paste into Claude, ChatGPT or Cursor.

Source of Launch monitor

Show the full text78 lines
nametitledescriptioncategorytags
launch-monitorLaunch monitor| Use this skill when a product launch is live and you need to know what press, social, and developer communities are saying — and what to do about it. Produces a response war room report: a triaged signal feed with urgency levels and action badges, a mischaracterization tracker with copy-ready corrections, a competitor response panel, and a sentiment velocity read. Reach for it when someone says "monitor this launch", track the launch", "what's being said about the launch", "what's the reaction to the announcement", "flag any mischaracterizations", "check press coverage for the launch", post-launch coverage", or "how are competitors responding to our launch". Not for steady-state brand monitoring outside a launch window.Signals[Marketing]

Applies from the moment a launch is public until the coverage wave dies — typically two to four weeks. Produces a triaged response war room report where every signal carries an urgency level, an action badge, and an exact source link, so the team knows what to respond to, correct, amplify, or escalate — in that order.

Replace before enabling: {{ALERTS_CHANNEL}} — where act-now items get flagged to the team; {{COMMS_OWNER}} — who receives escalations (comms, legal, or leadership).

Before the first sweep

Do two research steps before asking the user anything:

  1. Resolve alternate names silently. Search the live web for the product's codenames, former names, version names, API/SDK/repo names, and model identifiers — they are often different from the marketing name, and coverage splits across all of them. Fold every confirmed variant into your query list without showing the user this step. Query patterns are in references/sources.md.
  2. Confirm the launch date from evidence. Search for when the product actually launched. Present what you found for confirmation; if announcement date and general availability differ, surface both and ask which window matters.

Then confirm in a single message: launch date, lookback window (default: launch to now), depth (quick scan vs deep sweep — default deep), and competitors to prioritize or exclude (default: on, identified automatically). If the user says "just run it", take every default. If the product name is ambiguous after research, disambiguate before spending a single search on the wrong product.

Profile the product before querying. Answer five questions from the announcement and a quick search: What category is it? What ecosystem does it live in? Who is the audience? What are the key launch claims? And — most important — what would a mischaracterization look like: wrong category, wrong price, wrong capability, wrong comparison? This profile decides which communities you sweep, and you cannot flag a mischaracterization without knowing what "correct" looks like.

The sweep

Run parallel searches across four fronts — press, community, social, competitors — highest-reach sources first, because that is where a wrong claim does the most damage before you catch it. The full tiered source list, per-platform query patterns, and consumer-launch additions are in references/sources.md; read it before the first sweep of any launch.

Alongside the discovery queries, run the mischaracterization hunt every pass: targeted queries built from the context profile — the wrong claim you fear, the price, the wrong category, the capability it does not have, the wrong competitor comparison. Wrong information rarely surfaces in a generic sweep; you find it by searching for the specific error.

Use shallow, fast searches for discovery; extract the full page only for signals that survive triage and need exact quotes or reach estimates.

Triage

Every signal gets four labels: an urgency level (act now / monitor / good signal / noise), an action badge (RESPOND, CORRECT, AMPLIFY, ESCALATE, WATCH, IGNORE), a signal type, and the exact URL of the article, thread, or post — never a homepage, never fabricated. The full rubric — urgency definitions, badge semantics, reach heuristics, and the materiality threshold that filters noise — is in references/triage.md; apply it to every signal, every run.

For each piece of coverage that gets something wrong, extract the six-field mischaracterization record (claim, source and reach, what's wrong, correct version, spread risk, suggested one-sentence correction) per the same reference — including a secondary search to see whether other outlets are already citing the wrong claim. Spread status (SPREADING / CONTAINED / CORRECTED) decides urgency more than the original outlet's size does.

Sentiment velocity

Break the window into intervals — hourly for the first 24 hours, daily after — and count positive, negative, and neutral signals per interval. Identify the inflection point (when did sentiment peak or flip?) and flag any velocity spike, positive or negative: a sudden surge in mentions is itself a signal even before you read a single post.

Memory and re-runs

Keep a running file per launch in your workspace. On every run, load it and dedup before writing output: fingerprint each signal as {url, signal_type, published_date} with URLs normalized (strip query params and trailing slashes). Already-known and unchanged → suppress from the main feed (appendix only, on request). Returning with changed urgency → keep in the feed, marked as returning. Lead the report with the honesty line: X net-new · Y returning (urgency changed) · Z suppressed. After the run, append the new fingerprints and carry forward every unresolved mischaracterization and open action item — a wrong claim is not done until its status is CORRECTED.

Re-run cadence: every 1–2 hours for the first 6 hours post-launch, every 3–4 hours until hour 24, then once or twice daily until momentum dies. On a re-run, sweep only since the last run timestamp and surface only what is new.

The report

One format, every run: TL;DR first (sentiment read, act-now count, single most urgent item), the war room body in fixed section order, "What this means" last (trajectory read plus the one action to take now). The full section-by-section format spec — card fields, mischaracterization tracker layout, competitor panel, source index, and tone rules — is in references/report-format.md; follow it exactly.

After the report is delivered, flag act-now items to {{ALERTS_CHANNEL}} and route ESCALATE items to {{COMMS_OWNER}} — only after the user approves what gets posted. Suggested responses and corrections are always drafts for a human to send, never sent by you.

What good looks like

  • The best operator hunts for what's wrong, not what's said: the mischaracterization queries built from the context profile find the "it's just an X reskin" thread hours before it hits press, and the spread-risk search shows whether it is one Reddit comment or three outlets already citing each other.
  • The mediocre version is a clipping service: a flat list of links, no urgency, no suggested action, homepage URLs, positive and negative mixed together — the user still has to do all the thinking. Or worse: a re-run that re-reports Tuesday's signals as if they were news.
  • Output is good when the user can act in sixty seconds: the TL;DR names the single most urgent item, every act-now card carries a specific suggested action ("reply in the HN thread with the pricing page link", not "consider responding"), every correction is copy-ready, and every source link lands on the exact thread.

Rules

  • MUST include the exact article/thread/post URL for every signal, as returned by search. NEVER a homepage. NEVER a fabricated or reconstructed URL.
  • MUST run the mischaracterization hunt on every pass, not just the first.
  • MUST dedup against the launch's running file before output and lead with the net-new/returning/suppressed counts.
  • MUST keep suggested responses and corrections as drafts — NEVER post, reply, comment, or send anything publicly or to a channel without explicit human approval.
  • NEVER report a claim as spreading, or attach a reach number, without evidence found in the sweep — say "unverified" when it is.
  • NEVER treat accurate neutral coverage as a problem to fix; flag it, don't prioritize it.
  • NEVER count syndicated wire copy as multiple signals.
1---
2name: launch-monitor
3title: Launch monitor
4description: |
5 Use this skill when a product launch is live and you need to know what press, social,
6 and developer communities are saying — and what to do about it. Produces a response
7 war room report: a triaged signal feed with urgency levels and action badges, a
8 mischaracterization tracker with copy-ready corrections, a competitor response panel,
9 and a sentiment velocity read. Reach for it when someone says "monitor this launch",
10 "track the launch", "what's being said about the launch", "what's the reaction to the
11 announcement", "flag any mischaracterizations", "check press coverage for the launch",
12 "post-launch coverage", or "how are competitors responding to our launch". Not for
13 steady-state brand monitoring outside a launch window.
14category: Signals
15tags: [Marketing]
16---
17 
18Applies from the moment a launch is public until the coverage wave dies — typically two to four weeks. Produces a triaged response war room report where every signal carries an urgency level, an action badge, and an exact source link, so the team knows what to respond to, correct, amplify, or escalate — in that order.
19 
20Replace before enabling: `{{ALERTS_CHANNEL}}` — where act-now items get flagged to the team; `{{COMMS_OWNER}}` — who receives escalations (comms, legal, or leadership).
21 
22## Before the first sweep
23 
24Do two research steps before asking the user anything:
25 
261. **Resolve alternate names silently.** Search the live web for the product's codenames, former names, version names, API/SDK/repo names, and model identifiers — they are often different from the marketing name, and coverage splits across all of them. Fold every confirmed variant into your query list without showing the user this step. Query patterns are in `references/sources.md`.
272. **Confirm the launch date from evidence.** Search for when the product actually launched. Present what you found for confirmation; if announcement date and general availability differ, surface both and ask which window matters.
28 
29Then confirm in a single message: launch date, lookback window (default: launch to now), depth (quick scan vs deep sweep — default deep), and competitors to prioritize or exclude (default: on, identified automatically). If the user says "just run it", take every default. If the product name is ambiguous after research, disambiguate before spending a single search on the wrong product.
30 
31**Profile the product before querying.** Answer five questions from the announcement and a quick search: What category is it? What ecosystem does it live in? Who is the audience? What are the key launch claims? And — most important — what would a mischaracterization look like: wrong category, wrong price, wrong capability, wrong comparison? This profile decides which communities you sweep, and you cannot flag a mischaracterization without knowing what "correct" looks like.
32 
33## The sweep
34 
35Run parallel searches across four fronts — press, community, social, competitors — highest-reach sources first, because that is where a wrong claim does the most damage before you catch it. The full tiered source list, per-platform query patterns, and consumer-launch additions are in `references/sources.md`; read it before the first sweep of any launch.
36 
37Alongside the discovery queries, run the **mischaracterization hunt** every pass: targeted queries built from the context profile — the wrong claim you fear, the price, the wrong category, the capability it does not have, the wrong competitor comparison. Wrong information rarely surfaces in a generic sweep; you find it by searching for the specific error.
38 
39Use shallow, fast searches for discovery; extract the full page only for signals that survive triage and need exact quotes or reach estimates.
40 
41## Triage
42 
43Every signal gets four labels: an urgency level (act now / monitor / good signal / noise), an action badge (RESPOND, CORRECT, AMPLIFY, ESCALATE, WATCH, IGNORE), a signal type, and the **exact URL** of the article, thread, or post — never a homepage, never fabricated. The full rubric — urgency definitions, badge semantics, reach heuristics, and the materiality threshold that filters noise — is in `references/triage.md`; apply it to every signal, every run.
44 
45For each piece of coverage that gets something wrong, extract the six-field mischaracterization record (claim, source and reach, what's wrong, correct version, spread risk, suggested one-sentence correction) per the same reference — including a secondary search to see whether other outlets are already citing the wrong claim. Spread status (SPREADING / CONTAINED / CORRECTED) decides urgency more than the original outlet's size does.
46 
47## Sentiment velocity
48 
49Break the window into intervals — hourly for the first 24 hours, daily after — and count positive, negative, and neutral signals per interval. Identify the inflection point (when did sentiment peak or flip?) and flag any velocity spike, positive or negative: a sudden surge in mentions is itself a signal even before you read a single post.
50 
51## Memory and re-runs
52 
53Keep a running file per launch in your workspace. On every run, load it and dedup before writing output: fingerprint each signal as `{url, signal_type, published_date}` with URLs normalized (strip query params and trailing slashes). Already-known and unchanged → suppress from the main feed (appendix only, on request). Returning with changed urgency → keep in the feed, marked as returning. Lead the report with the honesty line: `X net-new · Y returning (urgency changed) · Z suppressed`. After the run, append the new fingerprints and carry forward every unresolved mischaracterization and open action item — a wrong claim is not done until its status is CORRECTED.
54 
55Re-run cadence: every 1–2 hours for the first 6 hours post-launch, every 3–4 hours until hour 24, then once or twice daily until momentum dies. On a re-run, sweep only since the last run timestamp and surface only what is new.
56 
57## The report
58 
59One format, every run: TL;DR first (sentiment read, act-now count, single most urgent item), the war room body in fixed section order, "What this means" last (trajectory read plus the one action to take now). The full section-by-section format spec — card fields, mischaracterization tracker layout, competitor panel, source index, and tone rules — is in `references/report-format.md`; follow it exactly.
60 
61After the report is delivered, flag act-now items to `{{ALERTS_CHANNEL}}` and route ESCALATE items to `{{COMMS_OWNER}}` — only after the user approves what gets posted. Suggested responses and corrections are always drafts for a human to send, never sent by you.
62 
63## What good looks like
64 
65- The best operator hunts for what's *wrong*, not what's *said*: the mischaracterization queries built from the context profile find the "it's just an X reskin" thread hours before it hits press, and the spread-risk search shows whether it is one Reddit comment or three outlets already citing each other.
66- The mediocre version is a clipping service: a flat list of links, no urgency, no suggested action, homepage URLs, positive and negative mixed together — the user still has to do all the thinking. Or worse: a re-run that re-reports Tuesday's signals as if they were news.
67- Output is good when the user can act in sixty seconds: the TL;DR names the single most urgent item, every act-now card carries a specific suggested action ("reply in the HN thread with the pricing page link", not "consider responding"), every correction is copy-ready, and every source link lands on the exact thread.
68 
69## Rules
70 
71- MUST include the exact article/thread/post URL for every signal, as returned by search. NEVER a homepage. NEVER a fabricated or reconstructed URL.
72- MUST run the mischaracterization hunt on every pass, not just the first.
73- MUST dedup against the launch's running file before output and lead with the net-new/returning/suppressed counts.
74- MUST keep suggested responses and corrections as drafts — NEVER post, reply, comment, or send anything publicly or to a channel without explicit human approval.
75- NEVER report a claim as spreading, or attach a reach number, without evidence found in the sweep — say "unverified" when it is.
76- NEVER treat accurate neutral coverage as a problem to fix; flag it, don't prioritize it.
77- NEVER count syndicated wire copy as multiple signals.
78 

Discussion

Alternatives

Also in Launch planningSee all 277 in Product →
AI Product Launch PlaybookLaunch your AI product to global attention — the playbook behind Manus, Devin, and AFFiNE's breakout launches. Covers AI-specific GTM strategy, hype cycle management, waitlist tactics, and multi-market rollout for maximum day-one impact.Business & ops · MITShipping and launchPrepares production launches. Use when preparing to deploy to production, or when asking what needs to be in place before shipping. Use when you need a pre-launch checklist, when setting up monitoring, when planning a staged rollout, or when you need a rollback strategy.Business & ops · MITLaunch StrategyWhen the user wants to plan a product launch, feature announcement, or release strategy. Also use when the user mentions 'launch,' 'Product Hunt,' 'feature release,' 'announcement,' 'go-to-market,' 'beta launch,' 'early access,' 'waitlist,' 'product update,' 'how do I launch this,' 'launch checklist,' 'GTM plan,' or 'we're about to ship.' Use this whenever someone is preparing to release something publicly. For ongoing marketing after launch, see marketing-ideas. For the offer being launched (bonuses, guarantees, scarcity, naming), see offers.Marketing · MITPacsomaticOperator toolkit for nf-core/pacsomatic matched tumor-normal workflows from BAM inputs. Use this skill when the user needs to validate run inputs, generate pacsomatic-compliant samplesheets, prepare reproducible Nextflow launch artifacts, run locally or submit to schedulers (LSF/Slurm/PBS/SGE), and triage execution failures. Triggers on requests to run pacsomatic, prepare launch commands/scripts, perform dry-run checks, or troubleshoot pipeline startup and scheduler submission errors.Science · MIT