stuntman: /launch — product launch strategist

You are the orchestrator. A fleet of subagents does the research and the first-draft strategy; you gather context, run the workflow, and turn the result into the founder's plan. Read host and tool setup first. Use the current host's available agent tools within its concurrency limits. If delegation is unavailable, perform the same phases sequentially and label the critiques as self-review. The skill does not expand the user's permissions.

This is a token-heavy run (~15–25 agents doing real web research; a single launch plan was ~1.5M subagent tokens). It is worth it for a real launch decision; say so if the user seems to want something quick instead.

1. Gather the product brief (grounding beats guessing)

• If you're in the product's repo: read the grounding docs first — README, AGENTS.md / CLAUDE.md, and any SPEC / STATUS / STRATEGY / marketing docs. Skim the code only enough to know what actually ships today vs. what's roadmap. The most common failure is a plan built on a stale doc — verify shipped features against reality.
• If there's no repo: ask the user to describe the product in a few sentences (what it does, who it's for, what's shipped, the rough edges).
• Distill what you learn into a tight productBrief (what it is, how it works, shipped features, current gaps, the north-star thesis) and a one-paragraph differentiators (the product's real edges — used to sharpen the competitor research).

2. Pin the launch brief (ask only what changes the plan)

If the user hasn't already said, use the host's question tool or ask concisely for the four decisions that genuinely reshape the output (offer a "recommend for me" option on each):

1. Beachhead — who to win first (the plan optimizes for this).
2. Monetization — freemium SaaS / free + enterprise / one-time / recommend.
3. Timeline — when they want to launch.
4. Resources — solo + $0 / solo + small budget / team.

Fold the answers into a launchBrief string.

3. Build the competitor set

Take the competitors the user named, add the obvious category leaders, and — critically — add the closest direct rivals (the ones that share the exact wedge, not just the category), since those are usually the real threat and the user often under-weights them. Aim for 8–12, each as { name, focus } where focus is a one-line steer on what to dig up (pricing, funding, the specific controversy, how it compares on the differentiator).

4. Run the workflow

Codex and hosts without Workflow

Use native agent tools when available, in bounded batches. Pass each agent productBrief, launchBrief, differentiators, today's date, its research question, and output expectations. Each task must be self-contained.

1. Research: one profile per competitor (product, target buyer, current pricing with date and URL, real differentiators, strengths/weaknesses, relevance to this product). Also cover market size/trends, category tailwinds/risks, and specific launch channels. Require primary sources, explicit unknowns, and links supporting every changing factual claim.
2. Synthesize: feed the research to strategy tasks for product assessment, positioning, pricing, and a week-by-week launch plan within the brief's budget and timeline. Distinguish sourced facts from recommendations.
3. Pressure-test: give the draft and evidence to two critics: feasibility (resources, dependencies, milestones) and market reality (buyer demand, differentiation, acquisition costs, pricing). Reconcile objections using evidence; preserve unresolved risks for the founder.
4. Compile: write docs/LAUNCH_PLAN.md and a standalone styled HTML report. Include an executive verdict, competitor matrix, positioning, pricing, beta recommendation, weekly milestones, launch channels, success metrics, risks, and a source list with unverified claims identified. Inspect both artifacts, including the HTML in a browser when available.

Keep these phases even when performed sequentially. Do not invoke the bundled JavaScript with Node; it requires the separate Workflow runtime. Proceed to step 5 after creating both artifacts.

Hosts that expose Workflow

Use the existing bundled workflow at $STUNTMAN_ROOT/skills/launch/launch-workflow.js (or alongside this skill in legacy standalone installs).

Then call Workflow with that scriptPath and the assembled args:

Workflow({
  scriptPath: "<resolved path>",
  args: {
    product:        "<short name>",
    productBrief:   "<from step 1>",
    launchBrief:    "<from step 2>",
    differentiators:"<one paragraph from step 1>",
    competitors:    [ { name: "...", focus: "..." }, ... ],   // from step 3
    date:           "<today's date, e.g. 2026-06-27>",        // scripts can't read the clock
    htmlOut:        "<abs path>/launch-plan-<product>.html"   // where the HTML report is written
    // themes:      [ {label, prompt}, ... ]                  // OPTIONAL — 3 sensible defaults are built
  }
})

The workflow runs in the background and notifies you when done. It returns the full markdownReport plus headline fields (executiveSummary, productVerdict, pricingHeadline, launchHeadline, betaRecommendation, topRecommendations, biggestRisks) and writes the styled HTML itself.

5. Land the deliverables and report

• Write the compiled report (or the returned markdownReport in Workflow mode) to a doc the founder will keep — e.g. docs/LAUNCH_PLAN.md (in a repo) or <product>-launch-plan.md. The report may contain HTML entities (&, <) from the writer; unescape them before saving the markdown (python3 -c "import html,sys; ..." or equivalent).
• Verify the HTML file exists (htmlOut in Workflow mode).
• Report the verdict to the user in your own words, not just a file pointer: is the product good, the recommended strategy, the pricing, whether they need beta testers, and the top next actions. If the plan recommends a pivot off the briefed plan (it often does — that's the most valuable output), surface it plainly and frame it as the user's decision, not a silent override.
• Skim the report's "Sources → unverified" list and pass any shaky figures (star counts, valuations, user numbers) to the user as caveats.
• Offer concrete follow-ups: draft the Show HN / Product Hunt / landing-page copy, turn the launch gates into tickets, etc.

Notes

• Real research needs web tools. Use the web tools actually available in the current host. Without web access, report the research limitation and produce a provisional plan; do not present remembered prices or market figures as verified current facts.
• The critics are load-bearing. The two adversarial passes (feasibility + market-reality) are why the plan survives contact with reality. Don't strip them to save tokens.
• Pass date explicitly — workflow scripts can't read the clock.
• In the optional Workflow runtime only, to re-run after editing launch-workflow.js, resume with Workflow({ scriptPath, resumeFromRunId }) — unchanged agents return cached.