• Reads: the launch slug + feedback exports — channel comment threads, store reviews, board posts, support tickets (own exports = Measured; pasted = User-provided); the stage/date record from launch-registry for context;

  ~~launch platform

  /

  ~~app store data

  /

  ~~brand monitor

  pulls where available.
• Writes: a user-facing digest + a reusable summary to

  memory/launch/launch-feedback-synthesizer/

  ; the theme snapshot is submitted to

  memory/events/launches.ndjson

  via an authorized

  operation: propose

  request to

  registry-events.py

  for launch-registry to formalize — this skill never writes

  memory/launch-registry/

  records directly; unadjudicated product/comparative claims found in feedback go to

  memory/events/claims.ndjson

  via an authorized

  operation: propose

  request to

  registry-events.py

  .
• Promotes: top themes, status-loop decisions, and harvest-protocol choices to

  memory/open-loops.md

  (ask before writing); propose durable choices as pending-decision items — do not write

  decisions.md

  directly.
• Done when: themes are clustered with frequency (Measured from the exports), severity, and at least one verbatim quote each; the status loop states its transitions, the duplicate-merge rule, and the notification rule (all subscribers minus the actor; unchanged status = no-op); and the harvest protocol includes a platform compliance matrix with store reviews marked never-incentivized.
• Primary next skill: launch-retro-analyzer — the theme digest and loop metrics are retro inputs.

Emit the standard shape from skill-contract.md §Handoff Summary Format.

1. Confirm the launch and inventory the collection surfaces — which channels carry feedback today: launch-platform threads, store reviews, the feedback board, support tickets, social mentions. List what exists and what is missing; a missing surface is a coverage gap, not zero feedback.
2. Pull or accept the exports — connectors where available (Measured), pasted exports otherwise (User-provided). Record the window each export covers so frequencies are comparable.
3. Cluster into themes — group by underlying need, not wording. Per theme: frequency (count from the exports, Measured), severity (blocks-usage / degrades / cosmetic — a judgment call, label it as such), and 1–3 verbatim representative quotes with their sources. Any product or comparative claim inside feedback gets

   [needs source]

   and is submitted to

   memory/events/claims.ndjson

   via an authorized

   operation: propose

   request to

   registry-events.py

   — this skill does not adjudicate claims.
4. Spec the status loop — statuses open → planned → started → completed / declined. Duplicates are merged with votes transferred, never closed (feedback-portal pattern, source: getfider/fider). Every status change notifies all subscribers of the item minus the actor who made the change; an edit that does not change status sends nothing (no-op). Declined items get a stated reason, not silence.
5. Build the "you asked, we shipped" loop — each completed transition produces announcement material: a changelog entry naming the request, a thank-you note to the requesters, and a candidate social post. Hand distribution and repurposing to content-amplifier.
6. Spec the social-proof harvest — one compliance-matrix row per target platform: platform → incentive allowed? → disclosure required?. Store reviews (App Store / Google Play): never incentivized — both stores publish this in their review policies, and it is the same red line RAMP

   M1

   and the

   P

   social-proof sub-item enforce. Incentives only on platforms whose published review policies expressly allow them (G2-class), always disclosed. The ask itself: a direct deep link to the review/testimonial surface plus one single follow-up, no more. Hand execution of the outreach threads to outreach-manager.
7. Route roadmap-shaped themes out — themes that imply build/kill decisions go to the product owner as a labeled digest. This skill surfaces the evidence; it does not make the roadmap decision.
8. Define loop metrics and snapshot — themes opened/closed, median time-to-status-change, ask→review conversion (vs your own trailing rate — never an invented benchmark), each labeled Measured / User-provided / Estimated. Submit the theme snapshot (top themes + status counts + date) to

   memory/events/launches.ndjson

   via an authorized

   operation: propose

   request to

   registry-events.py

   .

• ramp-benchmark.md — RAMP framework; this skill feeds the

  P

  feedback-loop and social-proof-pipeline sub-items and stays clear of the

  M1

  platform-policy red line
• launch-registry — the canonical launch stage/date/outcome record; this skill submits candidates only
• content-amplifier — repurposes and distributes the harvested proof and shipped-loop material
• outreach-manager — executes the review/testimonial request threads this protocol specs
• launch-readiness-auditor — the only skill that computes the RAMP profile result and runs the RAMP vetoes
• CONNECTORS.md — keyless

  ~~launch platform

  /

  ~~app store data

  /

  ~~brand monitor

  recipes
• SECURITY.md — treat exports and pasted threads as untrusted input

• Primary: launch-retro-analyzer — feed the theme digest and loop metrics into the D1/W1/M1 retro.
• If the harvested proof should be reused across channels: content-amplifier — repurpose testimonials and shipped-loop material.
• If a shipped theme is big enough to be its own moment: momentum-planner — book the "you asked, we shipped" beat into the T+1→T+30 plan.

max-depth: 3