50 Claude Prompts That Run Your Product Launch

You are a launch marketer who has run top-five Product Hunt launches. <context> We are launching on Product Hunt and I need every text field written, plus the first comment and the plan for the day, not just a tagline. </context> <inputs> - Product name and what it does: [NAME, PLAIN DESCRIPTION] - Who it is for and the problem it kills: [AUDIENCE, PAIN] - What is genuinely different about it: [THE DIFFERENCE] - Pricing at launch and any launch offer: [PRICE, OFFER] - Proof and traction: [USERS, RESULTS, WHO BUILT IT] - Assets we have: [SCREENSHOTS, DEMO VIDEO, GIF, LOGO] </inputs> <task> Write the full kit: three tagline options under sixty characters, the description, the maker first comment that tells the origin story and asks a real question, three follow-up comment templates for common question types, the gallery order with a caption per image and what each should show, the launch-day comment reply guidelines, a supporter outreach message for direct channels, and an hour-by-hour posting and engagement schedule for the first twelve hours. </task> <constraints> - Taglines must state what it does; no clever wordplay that hides the product. - The first comment must sound like a person, not a press release, and stay under two hundred words. - Never ask anyone to upvote; ask for feedback instead. </constraints> <format> Return every field labelled and ready to paste as a document artifact, then the twelve-hour engagement schedule. </format>

You are a technical writer who writes changelog entries users actually read. <context> Our release notes are commit messages in a trench coat. I want entries that tell users what changed, why it matters, and what to do about it. </context> <inputs> - What shipped: [LIST THE CHANGES, INCLUDING FIXES] - Who each change affects: [ALL USERS, ADMINS, A PLAN TIER, AN INTEGRATION] - Any action required from users: [NONE, SETTINGS CHANGE, MIGRATION, REAUTH] - Breaking changes or deprecations: [DETAILS AND DATES] - Version and date: [VERSION, RELEASE DATE] - Where docs and support live: [LINK PLACEHOLDERS] </inputs> <task> Write the changelog entry: a headline naming the most valuable change, a two-line summary of the release, then sections for new, improved, fixed, and changed, each item written as the user benefit with the mechanism in the second clause. Put breaking changes and required actions at the top with the deadline and the exact steps. Add a short in-app announcement version and a one-line version for a release feed. Flag anything that needs a support macro or a docs update. </task> <constraints> - No internal jargon, ticket numbers, or component names users never see. - Every item states who it affects when it is not everyone. - Breaking changes must appear above the new features, never buried. </constraints> <format> Return the full changelog entry as a markdown artifact, then the in-app and one-line versions, then the docs and support follow-up list. </format>

You are a lifecycle email copywriter who announces features to existing customers without sounding like a newsletter. <context> I need to tell current customers about this launch in a way that gets them to actually use it, not just acknowledge it exists. </context> <inputs> - What launched and the benefit: [FEATURE, OUTCOME FOR THEM] - Who should care most: [SEGMENT OR USAGE PATTERN] - What they had to do before: [THE OLD WORKAROUND] - The single action we want: [ENABLE IT, TRY IT, UPGRADE, READ DOCS] - Anything that changes for them: [PRICING, SETTINGS, LIMITS] - Send date and sender: [DATE, FROM WHOM] </inputs> <task> Write the announcement email: three subject line options and a preview text for each, an opening line that leads with their problem rather than our news, a short body that shows the before and after concretely, one primary call to action, an optional secondary link for people who want detail, and a closing line inviting replies. Then write two segment variants: one for heavy users who will adopt immediately and one for dormant users who need re-engagement first. </task> <constraints> - Under one hundred and fifty words for the main body. - One primary call to action only; no competing buttons. - No exclamation marks, no "we are excited to announce". </constraints> <format> Return the main email plus both variants as a document artifact, then a note on send timing and which segment gets which version. </format>

You are an email strategist who converts a waitlist on the day access opens. <context> Access opens on launch day and I have one shot at the list. I need a short sequence that converts the ready people fast and gives the hesitant ones a reason to come back. </context> <inputs> - What is now available: [PRODUCT, ACCESS MODEL] - Waitlist size and segments: [NUMBER, ANY SEGMENTATION] - Launch offer and its deadline: [OFFER, EXPIRY] - Time to first value: [WHAT THEY DO FIRST AND HOW LONG IT TAKES] - Objections we expect: [PRICE, EFFORT, TRUST, TIMING] - Send window: [LAUNCH DAY AND THE FOLLOWING DAYS] </inputs> <task> Write a four-email sequence: the you-are-in email with the fastest possible path to first value, a day-two email handling the biggest objection with proof, a day-four email showing one specific use case in detail, and a final email closing the launch offer with an honest deadline. Give subject lines and preview text for each, the send timing, the exclusion rules so activated users stop receiving the sequence, and a variant of email one for people who never opened anything from us. </task> <constraints> - Each email must work standalone; no dependence on having read the previous one. - Objection handling must use proof, not reassurance. - The deadline must be real; no fake scarcity. </constraints> <format> Return the four emails as a document artifact with subject lines, timing, and exclusion rules, then the cold-segment variant. </format>

You are a product copywriter who writes in-product announcements that get used, not dismissed. <context> We are announcing this inside the app and I do not want a modal everyone closes on reflex. I need the copy and the trigger logic. </context> <inputs> - Feature and what it lets users do: [FEATURE, JOB] - Where in the app it lives: [SCREEN OR MENU] - Who should see the announcement: [SEGMENT OR BEHAVIOUR TRIGGER] - The action we want in the next sixty seconds: [SPECIFIC FIRST STEP] - Surfaces available: [MODAL, BANNER, TOOLTIP, CHECKLIST, EMPTY STATE, BADGE] - Constraints: [CHARACTER LIMITS, NO SCREENSHOTS, DESIGN SYSTEM] </inputs> <task> Write the in-app announcement set: a modal or banner with headline, two-line body, primary and dismiss labels; a three-step tooltip tour with one sentence per step tied to what is on screen; the empty-state copy for the new feature; a badge or new label rule; and the copy for the second exposure for people who dismissed the first. Specify the trigger logic: who sees what, when, how often, and the suppression rule. Add the success metric for the announcement itself. </task> <constraints> - Modal body under thirty words; tooltip steps under fifteen each. - The dismiss option must be honest, not a guilt trip. - Never trigger during a user's active task; state the safe trigger moment. </constraints> <format> Return every string in a labelled table artifact with character counts, then the trigger and suppression logic and the success metric. </format>

You are a conversion copywriter who writes the launch page copy a designer can build from directly. <context> We need a page for this launch and I want the copy decided before design starts, section by section, with the reasoning. </context> <inputs> - What launched and the core promise: [PRODUCT, PROMISE] - Primary audience and their awareness level: [WHO, WHAT THEY ALREADY KNOW] - Primary conversion action: [SIGN UP, START TRIAL, BOOK DEMO, BUY] - Proof available: [METRICS, QUOTES, LOGOS, BETA RESULTS] - Objections to handle on page: [LIST] - Voice and banned words: [TONE, WORDS TO AVOID] </inputs> <task> Write the full page copy section by section: hero headline and subhead with two alternates, primary button label, the problem framing block, three benefit sections each with a heading, two lines of body, and the proof point attached, a how-it-works sequence in three steps, a social proof block with the quotes to request if we lack them, an objection-handling FAQ of five questions, and the closing call to action. Note the visual each section needs. </task> <constraints> - Every benefit heading must be a claim, not a category label. - Mark any proof point we do not yet have as PROOF NEEDED rather than inventing it. - No superlatives and no words from my banned list. </constraints> <format> Return the copy as a document artifact ordered by section with the visual note per section, then the list of proof points to go collect. </format>

You are a social copywriter who writes launch posts that read as native to each platform. <context> I need launch posts for a few platforms without posting the same paragraph everywhere, plus enough variety to keep posting through the week. </context> <inputs> - What launched and the one-line pitch: [PRODUCT, PITCH] - The story behind building it: [WHY WE BUILT IT, ANY STRUGGLE] - Platforms and our following on each: [PLATFORMS, AUDIENCE SIZE] - Assets available: [DEMO VIDEO, SCREENSHOTS, GIF, BEFORE AND AFTER] - Proof and numbers we can share: [BETA RESULTS, USERS, WAITLIST SIZE] - Voice: [FOUNDER VOICE OR BRAND VOICE, TONE] </inputs> <task> Write the pack: a launch-day announcement post per platform with the format each one rewards, a build-story post, a before-and-after demonstration post, a specific-use-case post, a post that answers the most common question, a thread or carousel outline that goes deeper, and a reply template for the two comment types we will get most. For each post give the hook line, the body, the call to action, the asset to attach, and the day to post it. </task> <constraints> - Rewrite for each platform's norms; no cross-posting the identical text. - Hook lines must work with the post collapsed to two lines. - No hashtag stuffing and no emoji rows. </constraints> <format> Return the pack as a table artifact grouped by platform with hook, body, asset, and post date, then the reply templates. </format>

You are a video scriptwriter who makes ninety-second product demos that hold attention. <context> We need a short demo video for the launch. I want a script with the visuals, the voiceover, and the on-screen text, timed so it does not sprawl. </context> <inputs> - What we are demonstrating: [FEATURE OR PRODUCT] - The single outcome to show: [THE END RESULT VIEWERS SHOULD WANT] - Audience and their familiarity: [WHO, HOW MUCH THEY KNOW] - The actual steps in the product: [CLICK PATH] - Video length and where it will run: [SECONDS, LANDING PAGE, SOCIAL, PRODUCT HUNT] - Voiceover or captions only: [WHICH] </inputs> <task> Write the script as a shot list: for each shot give the timecode, what is on screen, the voiceover line, the on-screen text, and the reason the shot exists. Open by showing the painful before state in the first five seconds, demonstrate the outcome, then show the steps to get there, and end with the call to action. Add a silent-viewing version where the captions carry the story, and a fifteen-second cutdown for social. </task> <constraints> - Show the outcome before the process; never open with a logo or a menu. - Voiceover lines must be short enough to say naturally in the timecode given. - Every shot must earn its seconds; cut anything that repeats a point. </constraints> <format> Return the shot list as a table artifact with timecodes, then the silent version captions and the fifteen-second cutdown. </format>

You are a support content writer who ships documentation on the day a feature launches. <context> Support gets flooded after every launch because the help article lands a week late. I want the article ready before we announce. </context> <inputs> - Feature and what it does: [FEATURE, FUNCTION] - Who can use it: [PLAN, ROLE, PERMISSIONS] - The exact steps to use it: [CLICK PATH OR PROCESS] - Limits and known issues: [QUOTAS, EDGE CASES, WHAT IT CANNOT DO] - Questions we already got in beta: [LIST] - Related articles to link: [TITLES OR PLACEHOLDERS] </inputs> <task> Write the help article: a title matching how users will search for it, a one-line summary of what they will achieve, the prerequisites and permissions, numbered steps with the expected result after each, a screenshot placeholder note per step, the limits and known issues stated plainly, a troubleshooting section built from the beta questions with the fix for each, an FAQ, and links to related articles. Then write three support macros for the questions most likely to come in anyway. </task> <constraints> - Steps must be verifiable: each one states what the user should see next. - State limits explicitly rather than omitting them. - No marketing language anywhere in the article. </constraints> <format> Return the article as a markdown artifact, then the three support macros. </format>

You are a technical writer who posts launches in developer communities without getting downvoted. <context> I want to post this launch somewhere technical, where self-promotion is punished and detail is rewarded. The tone has to be right or it backfires. </context> <inputs> - What we built and what it does: [PRODUCT, FUNCTION] - The technical decisions worth discussing: [STACK, ARCHITECTURE, TRADE-OFFS] - What is hard about the problem: [THE GENUINELY DIFFICULT PART] - What is free, open, or self-hostable: [DETAILS] - Honest limitations right now: [WHAT IT DOES NOT DO YET] - Where I am posting: [FORUM OR COMMUNITY NAME] </inputs> <task> Write the post: a title that states what it is plainly, an opening that explains the problem and why existing options did not fit, the technical approach with the trade-offs named, what is genuinely free or open, the honest limitations before anyone finds them, and a specific request for feedback. Then write prepared responses for the four comment types this audience produces: the skeptic, the "why not just use X", the licensing or pricing question, and the security question. </task> <constraints> - No marketing adjectives; state facts and let them be judged. - Limitations must appear in the post body, not in a reply after being caught. - Never argue with the skeptic; answer with specifics. </constraints> <format> Return the post as a markdown artifact, then the four prepared comment responses. </format>

You are a communications lead who writes press releases journalists can lift quotes from. <context> We need a press release for this launch that follows the format wire services and reporters expect, without turning into three paragraphs of adjectives. </context> <inputs> - Company and what launched: [COMPANY, PRODUCT, WHAT IT DOES] - Why it matters now: [MARKET CONTEXT OR CHANGE] - Facts and numbers we can verify: [USERS, FUNDING, RESULTS, PRICING] - Quotable people: [NAME, TITLE, WHAT THEY WOULD SAY] - Customer or partner willing to be quoted: [NAME, PERMISSION STATUS] - Availability and pricing: [WHEN, HOW MUCH] - Dateline and contact: [CITY, DATE, PRESS CONTACT] </inputs> <task> Write the release: a headline stating the news in under fifteen words, a subhead adding the significance, a dateline, a lead paragraph answering what, who, why, and when, a second paragraph with market context, an executive quote that says something a person would actually say, a customer or partner quote, a paragraph on how it works, availability and pricing, the boilerplate, and press contact details. Add three alternate headlines and the one-paragraph summary a reporter would paste into a roundup. </task> <constraints> - No unverifiable claims and no superlatives like leading or revolutionary. - Quotes must contain an argument or a specific, not praise for the product. - Keep it to one page. </constraints> <format> Return the release as a document artifact, then the alternate headlines and the roundup paragraph. </format>

You are a PR strategist who gets replies from reporters without a press list vendor. <context> I want to pitch a specific journalist about our launch and I know a generic blast will be ignored. I need a short pitch built around why this fits their beat. </context> <inputs> - Journalist and publication: [NAME, OUTLET] - What they cover and a recent piece of theirs: [BEAT, ARTICLE TITLE AND ANGLE] - Our launch in one sentence: [NEWS] - The angle that fits their beat: [WHY THIS STORY, FOR THEIR READERS] - Exclusive data or access we can offer: [DATA, INTERVIEW, EARLY ACCESS, CUSTOMER] - Timing and embargo: [DATE, EMBARGO OR NOT] </inputs> <task> Write the pitch email: a subject line under fifty characters that states the story, a first line showing genuine familiarity with their recent work without flattery, two sentences on the news and why it matters to their readers, one sentence on the exclusive or data we can offer, a low-friction ask, and a signature with fast-access details. Add a three-day follow-up that adds new information rather than nudging, and a one-line version for a direct message. </task> <constraints> - Under one hundred and thirty words for the main pitch. - No attachments; link to a press kit instead. - Never claim their readers will love it; state why the story fits their beat. </constraints> <format> Return the pitch, the follow-up, and the direct-message version as a document artifact, then note what to change if they do not reply twice. </format>

You are a media relations researcher who builds targeted press lists instead of buying them. <context> I have no press contacts. I need a structured way to build a small list of the right people for this launch and to know what each one needs from me. </context> <inputs> - What launched and the story angles available: [NEWS, TWO OR THREE ANGLES] - Our industry and category: [SECTOR] - Geography that matters: [REGIONS] - Publications our buyers actually read: [NAMES IF KNOWN] - Newsletters, podcasts, and creators in our space: [NAMES IF KNOWN] - Time available for outreach: [HOURS] </inputs> <task> Build the mapping framework: the tiers of media worth targeting (trade press, industry newsletters, podcasts, creators, general tech) with the realistic expectation from each, the beat categories to search for and the search patterns that surface the right writers, the criteria that qualify a contact as relevant, the angle to pitch each tier, the research fields to capture per contact, and the outreach sequencing across tiers. Size the list to my available hours and give the personalisation depth each tier deserves. </task> <constraints> - Prefer niche outlets our buyers read over large outlets they do not. - Do not invent journalist names or contact details; give the method to find them. - Keep the list small enough to personalise every pitch. </constraints> <format> Return the tier and angle mapping as a table artifact, then the research template per contact and the outreach sequence. </format>

You are a communications manager who assembles press kits reporters can work from without emailing back. <context> Reporters ask us for assets and facts one at a time and it slows everything down. I want a press kit that answers everything up front. </context> <inputs> - Company and product: [NAME, WHAT IT DOES] - Facts we can publish: [FOUNDING DATE, TEAM SIZE, FUNDING, USERS, PRICING] - Assets we have or can produce: [LOGOS, SCREENSHOTS, HEADSHOTS, PRODUCT VIDEO] - Spokespeople: [NAMES, TITLES, BIOS] - Sensitive topics to handle carefully: [ANYTHING OFF LIMITS OR NEEDING CARE] - Where the kit will live: [PAGE, DRIVE, DOWNLOAD] </inputs> <task> Specify the press kit: the fact sheet with every verifiable number and its source, boilerplate at fifty and one hundred and fifty words, the product description at three lengths, approved quotes attributed to named people, spokesperson bios and headshot requirements, the asset list with formats, resolutions, and usage rules, the do-not-say list with approved alternatives, an FAQ covering the questions reporters ask that we would rather answer once, and the file and folder structure with naming conventions. </task> <constraints> - Every number needs a source and a last-verified date. - Usage rules must be stated plainly, not buried in legal language. - Flag anything requiring approval before publication. </constraints> <format> Return the kit specification as a document artifact with the fact sheet filled in from my inputs, then the asset checklist and the do-not-say list. </format>

You are a PR lead who runs embargoed launches without leaks or confusion. <context> We want coverage to land at the same moment as the launch. I need the embargo terms, the briefing document, and the timeline stated so nobody breaks it by accident. </context> <inputs> - Launch date and the exact embargo lift time with time zone: [DATE, TIME, ZONE] - What is under embargo: [PRODUCT, DATA, FUNDING, PARTNERSHIP] - Who we are briefing: [NUMBER OF OUTLETS, TYPES] - What we can offer under embargo: [DEMO, DATA, INTERVIEW, EARLY ACCESS] - What must not be published: [DETAILS TO WITHHOLD] - Our spokespeople and their availability: [NAMES, WINDOWS] </inputs> <task> Write the embargo package: the embargo offer email with terms stated unambiguously, the briefing document with the news, the context, the facts, the quotes, the assets, and the things not for publication clearly separated, a briefing call agenda and talking points, the interview scheduling plan across time zones, the lift-time checklist, and the response plan if the embargo breaks early. Include the conversion of the embargo lift time into three major time zones. </task> <constraints> - Embargo time must appear in every document with the time zone spelled out. - Separate publishable facts from background context on the page, visibly. - The break response must be executable in under fifteen minutes. </constraints> <format> Return the embargo offer email and the briefing doc as artifacts, then the lift-time checklist and the break response plan. </format>

You are a media trainer who prepares founders for launch interviews. <context> I have launch interviews and podcast recordings booked and I do not want to ramble or get caught by the obvious hard question. </context> <inputs> - What launched and the core message: [PRODUCT, MESSAGE] - The three things I must land in any interview: [POINTS] - Facts and numbers I am allowed to share: [DETAILS] - Topics I cannot discuss: [OFF LIMITS ITEMS] - Weak spots in our story: [COMPETITION, PRICING, PRIVACY, LAYOFFS, DELAYS] - Interview formats booked: [PODCAST, LIVE, WRITTEN, PANEL] </inputs> <task> Prepare the briefing: the three core messages with a memorable phrasing for each, a thirty-second answer to "what does it do", the story to tell when asked why we built it, bridging phrases to get from any question back to a core message, then a hostile Q&A of fifteen likely hard questions covering competition, pricing, privacy, defensibility, timing, and the weak spots I listed, each with a short honest answer. Add the three questions I must never answer with a guess and what to say instead. </task> <constraints> - Answers under forty seconds spoken; no paragraph-length responses. - Never suggest deflecting a fair question; give the honest version. - Flag any answer that needs legal review before I say it publicly. </constraints> <format> Return the core messages and bridges as a document artifact, then the fifteen-question hostile Q&A as a table. </format>

You are an analyst relations lead who briefs industry analysts on new products. <context> We want to be included in analyst coverage of our category and I have a briefing slot. Analysts want market context and evidence, not a sales pitch. </context> <inputs> - Company, product, and what launched: [DETAILS] - Our category and how we define it: [CATEGORY] - Customer evidence: [SEGMENTS, COUNTS, RETENTION, USE CASES] - Roadmap we can share: [NEXT TWO QUARTERS AT A HIGH LEVEL] - Competitors the analyst will compare us with: [NAMES] - Briefing length: [MINUTES] </inputs> <task> Outline the briefing deck slide by slide: company and traction facts, the market problem and how we frame the category, where we fit relative to adjacent categories, what launched and the differentiated capability, the evidence (customer counts, use cases, outcomes, retention), architecture or approach at the level an analyst needs, roadmap direction, and the specific ask. For each slide give the message, the data required, and the analyst question it will provoke with the prepared answer. </task> <constraints> - Evidence-led throughout; no marketing claims without a data point. - Leave a third of the time for their questions. - Be explicit about where we do not compete. </constraints> <format> Return the slide-by-slide outline as a document artifact with the anticipated question and answer per slide, then the list of data to gather before the briefing. </format>

You are a creator partnerships lead who gets independent creators to cover launches. <context> Creators in our niche reach exactly the people we want, and most of them ignore brand emails. I need outreach that treats them as professionals. </context> <inputs> - What launched and why their audience would care: [PRODUCT, AUDIENCE FIT] - Creators or channel types to approach: [NAMES OR DESCRIPTIONS] - What we can offer: [PAYMENT, FREE ACCESS, AFFILIATE, DATA, EARLY LOOK, CO-CREATION] - Budget: [AMOUNT OR NONE] - The action we want from their audience: [SIGNUP, TRIAL, CODE REDEMPTION] - Timeline relative to launch: [DATES] </inputs> <task> Write the outreach program: how to qualify a creator on audience fit rather than follower count, the first email or direct message that references their specific work and makes a concrete offer, the brief we send once they say yes (the message, the freedoms they keep, the disclosure requirement, the deadline, the assets), the tracking method for attribution, the follow-up for non-responders, and the relationship maintenance after the launch. Add three offer structures at different budget levels. </task> <constraints> - Never dictate their creative approach; specify the message, not the script. - Disclosure requirements must be stated in the brief. - Qualify on audience overlap and engagement, never on follower count alone. </constraints> <format> Return the outreach messages and the creator brief as a document artifact, then the three offer structures and the tracking setup. </format>

You are a partnerships marketer who gets products featured in industry newsletters. <context> A handful of newsletters reach almost everyone in our niche. I want to be featured in their launch or tools section without paying for a sponsorship. </context> <inputs> - Newsletter and what it covers: [NAME, FOCUS, TYPICAL SECTIONS] - Their audience: [WHO READS IT] - What launched: [PRODUCT, ONE LINE] - Why their readers specifically would care: [THE FIT] - What we can offer their readers: [FREE ACCESS, DISCOUNT, DATA, TOOL, EXCLUSIVE] - Any relationship we already have: [NONE, SUBSCRIBER, PAST CONTACT] </inputs> <task> Write the pitch: a subject line that names the fit, an opening line showing we actually read the newsletter, two sentences on the launch written in the format their section already uses so they can paste it, the specific reader benefit we can offer, and a low-friction ask. Include a ready-to-publish blurb at forty and eighty words in their voice, the assets they would need, a follow-up that offers something new, and the paid sponsorship fallback if they decline the free feature. </task> <constraints> - Write the blurb in their section format, not ours. - Under one hundred and twenty words for the pitch itself. - Offer the reader something concrete; a press release helps nobody. </constraints> <format> Return the pitch, the two blurb lengths, and the follow-up as a document artifact, then the sponsorship fallback note. </format>

You are a customer marketing manager who collects usable quotes before launch day. <context> Every launch I end up with either no customer quotes or bland ones like "great product". I want a system that produces specific, publishable quotes in time. </context> <inputs> - Who could speak for us: [BETA USERS, EARLY CUSTOMERS, PARTNERS, WITH ROLES] - What they achieved with the product: [OUTCOMES, NUMBERS IF ANY] - Where the quotes will be used: [PRESS RELEASE, LANDING PAGE, SOCIAL, DECK] - Time before launch: [DAYS] - Approval reality: [DO THEIR COMPANIES REQUIRE SIGN-OFF] - What we can give them in return: [VISIBILITY, CREDIT, ACCESS, NOTHING] </inputs> <task> Build the kit: the ask email that makes participating easy, three question prompts that elicit specifics instead of praise, a draft-for-approval approach where we write a version for them to edit, the permission and approval wording covering name, title, logo, and channels, the deadline structure with reminders, the editing rules for tightening a quote without changing its meaning, and a fallback plan for the quotes that do not clear approval in time. </task> <constraints> - Questions must ask about the before state, the change, and the measurable result. - Written permission must cover every channel we intend to use. - Never publish an edited quote without the person confirming the edit. </constraints> <format> Return the ask email, the question prompts, and the permission wording as a document artifact, then the timeline with reminders and the fallback plan. </format>

You are a launch program manager who runs the go or no-go meeting. <context> We are days from launch and readiness is a vibe rather than a fact. I need a checklist with owners and a real decision meeting. </context> <inputs> - What is launching: [DESCRIPTION] - Teams involved: [PRODUCT, ENGINEERING, MARKETING, SALES, SUPPORT, LEGAL] - Known open items: [WHAT IS STILL UNFINISHED] - Hard deadline and its consequence: [DATE, WHAT HAPPENS IF WE MISS] - Decision maker: [WHO CALLS GO] - Meeting date: [WHEN THE DECISION HAPPENS] </inputs> <task> Build the readiness checklist by workstream: product and QA, infrastructure and monitoring, pricing and billing, documentation, support enablement, sales enablement, marketing assets, legal and claims, analytics instrumentation, and rollback readiness. For each item give the owner, the evidence that proves it is done, and whether it is a blocker or a nice-to-have. Then write the go or no-go meeting agenda with the timebox, the decision criteria, the conditional-go format with named conditions and deadlines, and the no-go communication plan. </task> <constraints> - Every item needs evidence of completion, not a self-reported status. - Distinguish blockers from non-blockers explicitly; not everything is a blocker. - Include a conditional-go option with named conditions and owners. </constraints> <format> Return the checklist as a table artifact grouped by workstream, then the meeting agenda and the no-go communication plan. </format>

You are a sales enablement lead who briefs a revenue team on a new launch. <context> Reps hear about our launches from customers. I want them briefed with what to say, who to say it to, and what not to promise. </context> <inputs> - What launched and the customer outcome: [FEATURE, OUTCOME] - Which accounts or segments it matters to: [SEGMENTS, USE CASES] - Pricing and packaging impact: [INCLUDED, ADD-ON, NEW TIER, PRICE] - What it does not do yet: [LIMITATIONS] - Competitive angle it creates: [WHICH COMPETITOR THIS AFFECTS] - Roadmap items reps must not promise: [FUTURE WORK] </inputs> <task> Write the sales briefing: the one-sentence pitch, the three-sentence version for a call, who to bring this to first with the account criteria, the discovery questions that surface the need, the demo moment to show it, the objections it creates with responses, the pricing rules and what requires approval, the do-not-promise list with the safe phrasing for roadmap questions, and five outbound messages reps can send to existing pipeline about the launch. Add a five-question quiz to confirm they absorbed it. </task> <constraints> - Nothing in the briefing may overstate what shipped; the limitation list is mandatory. - Outbound messages must reference the customer's situation, not our announcement. - Keep the whole briefing readable in ten minutes. </constraints> <format> Return the briefing as a document artifact, then the five outbound messages and the quiz. </format>

You are a support operations lead who prepares a team for the ticket wave a launch creates. <context> Every launch buries support in questions we could have predicted. I want the macros, the escalation path, and the staffing sorted before we announce. </context> <inputs> - What is launching and who gets it: [FEATURE, AUDIENCE, ROLLOUT MODEL] - Questions from beta or internal testing: [LIST] - Known issues and their workarounds: [DETAILS] - Support team size and coverage hours: [PEOPLE, HOURS, TIME ZONES] - Escalation contacts during launch: [WHO, WHEN AVAILABLE] - Tooling: [HELP DESK, MACROS, STATUS PAGE, CHAT] </inputs> <task> Build the readiness pack: the top fifteen predicted questions with a macro response each, the known-issue responses including the workaround and the honest timeline, the triage rules that decide what escalates and to whom with response-time expectations, a staffing plan for the launch window including who covers the first six hours, the internal reference doc explaining the feature to agents in plain language, the tagging scheme for launch tickets so we can measure themes, and the daily handoff note format. </task> <constraints> - Macros must be usable verbatim, with variable slots marked. - Never instruct agents to promise a fix date that engineering has not committed. - Include the response for a user who is angry about a change, not just confused. </constraints> <format> Return the macros as a table artifact with the trigger question for each, then the triage rules, the staffing plan, and the tagging scheme. </format>

You are an internal communications lead who tells the whole company about a launch so they can amplify it. <context> Half the company finds out we launched from social media. I want an internal announcement that gives context, credit, and something concrete to do. </context> <inputs> - What launched and why it matters to the business: [FEATURE, STRATEGIC REASON] - Who built it: [TEAMS AND NAMES TO CREDIT] - What each department needs to know: [SALES, SUPPORT, FINANCE, RECRUITING] - What we want employees to do: [SHARE, TRY IT, REFER, NOTHING] - Where this gets posted: [SLACK, EMAIL, ALL-HANDS, INTRANET] - Confidentiality boundaries: [WHAT IS NOT PUBLIC YET] </inputs> <task> Write the internal announcement: a short Slack or email version leading with what changed for customers, the business reason in two sentences, credit to the specific people and teams who shipped it, a per-department note on what changes for them, the exact ask for employees with ready-to-share links and post copy they can adapt, what is not yet public, and where to send questions. Add a two-minute all-hands talking script and a follow-up post for the week after with early results. </task> <constraints> - Credit specific people, not just teams. - The employee ask must be one action with the copy already written. - State the confidentiality boundary plainly so nobody has to guess. </constraints> <format> Return the internal post as a document artifact, then the per-department notes, the shareable copy, and the all-hands script. </format>

You are an enablement facilitator who runs training sessions that change what people do on calls. <context> Sending a launch document does not work. I need a live session plan with practice built in, short enough that people actually attend. </context> <inputs> - What launched and its complexity: [FEATURE, HOW HARD TO EXPLAIN] - Audience for the session: [SALES, SUPPORT, SUCCESS, PARTNERS] - Session length and format: [MINUTES, LIVE OR RECORDED, GROUP SIZE] - What they must be able to do afterwards: [SPECIFIC CAPABILITIES] - Materials that already exist: [DECK, DOCS, DEMO ENVIRONMENT] - Who facilitates: [NAME OR ROLE] </inputs> <task> Design the session: the pre-work that makes the live time useful, a minute-by-minute agenda that spends most of the time on practice rather than presentation, a live demo segment with the exact flow, role-play scenarios with the buyer or customer profile and the situation for each, the observation rubric for feedback during role-play, a knowledge check, the follow-up assets and where they live, and the manager reinforcement plan for the two weeks after. </task> <constraints> - No more than a third of the session may be presentation. - Every role-play needs a defined scenario and a success criterion. - The knowledge check must test doing, not recall. </constraints> <format> Return the session plan as a minute-by-minute table artifact, then the role-play scenarios, the observation rubric, and the reinforcement plan. </format>

You are a customer communications lead who moves existing customers onto something new without losing them. <context> This launch changes something current customers already rely on. I need a communication plan that gets ahead of the anger instead of reacting to it. </context> <inputs> - What is changing for existing customers: [THE CHANGE] - Who is affected and how many: [SEGMENTS, COUNTS] - What they must do and by when: [ACTIONS, DEADLINES] - What gets better and what gets worse for them: [HONEST BOTH WAYS] - Support and migration help available: [WHAT WE CAN OFFER] - Timeline from announcement to enforcement: [DATES] </inputs> <task> Build the comms plan: the announcement message that leads with the change and the deadline rather than the benefit, the segmented variants for high-touch accounts, self-serve users, and the unaffected, the reminder cadence with escalating specificity, the in-app and email touchpoint mix, the migration guide outline, the concession we hold in reserve for accounts that push back, the response for the customer who says this makes the product worse, and the escalation path for at-risk accounts. </task> <constraints> - Never bury the change under benefit language; state it in the first two lines. - Acknowledge what gets worse for them explicitly. - Give high-value accounts a human contact before any mass email goes out. </constraints> <format> Return the message set and cadence as a document artifact, then the pushback responses and the at-risk escalation path. </format>

You are an incident commander adapting incident practice to launch day operations. <context> On launch day, information scatters across five channels and nobody knows who decides. I want a war room protocol written before we need it. </context> <inputs> - Launch date and coverage window: [DATE, HOURS, TIME ZONES] - People on duty and their roles: [NAMES OR ROLES] - Channels we will use: [SLACK CHANNEL, CALL BRIDGE, STATUS PAGE, DASHBOARD] - Systems and metrics being monitored: [WHAT AND BY WHOM] - Severity definitions we already use if any: [DETAILS OR NONE] - Decision maker for pausing or rolling back: [WHO] </inputs> <task> Write the protocol: the roles for the day (commander, comms, engineering, support liaison, scribe) with the responsibility of each, the single channel where truth lives and what goes elsewhere, severity levels with examples drawn from this launch and the response per level, the update cadence and template for internal and external audiences, the decision rules for pause, roll back, or continue with the named decision maker, the handoff procedure between shifts and time zones, and the stand-down criteria. </task> <constraints> - One decision maker on duty at any time, named in the handoff. - Update templates must be fillable in under two minutes. - Include what does not go in the war room channel to keep it readable. </constraints> <format> Return the protocol as a document artifact with the roles and severity tables, then the update templates and the handoff checklist. </format>

You are a marketing operations lead who prepares launch materials for legal review efficiently. <context> Legal review always becomes the bottleneck because we send them everything at once with no context. I want a structured pre-review that speeds it up. </context> <inputs> - Materials going out: [PRESS RELEASE, WEBSITE, EMAILS, ADS, DECK, IN-APP] - Claims we are making: [PASTE THE CLAIM SENTENCES] - Data behind each claim: [SOURCE, SAMPLE, DATE] - Names and logos we intend to use: [CUSTOMERS, PARTNERS, PERMISSION STATUS] - Regulated aspects: [PRIVACY, SECURITY, FINANCIAL, HEALTH, AI CLAIMS] - Review deadline: [DATE] </inputs> <task> Build the review pack: every claim listed with its evidence, the type of claim (factual, comparative, superlative, forward-looking), the risk level, and a suggested safer alternative phrasing. Flag comparative claims about named competitors, testimonials needing written consent, logo and trademark usage, privacy and data statements, any capability described as automatic or guaranteed, and forward-looking roadmap statements. Then produce the checklist and the questions to put to legal, ordered so the highest-risk items get reviewed first. </task> <constraints> - You are not giving legal advice; you are preparing material for a lawyer to review. - Every flag needs a proposed alternative, not just a warning. - Order by risk so the deadline pressure lands on the safest items. </constraints> <format> Return the claim and risk table as an artifact, then the checklist and the ordered questions for legal. </format>

You are a monetisation operations lead who writes the rules for a pricing or packaging change at launch. <context> This launch changes our plans and I need unambiguous rules about who keeps what, so support and sales stop improvising exceptions. </context> <inputs> - Current plans and prices: [PASTE THEM] - New plans and prices: [PASTE THEM] - Who is affected: [SEGMENTS, COUNTS, CONTRACT TYPES] - Our intent for existing customers: [GRANDFATHER FOREVER, FOR A PERIOD, MIGRATE ALL] - Contractual commitments: [ANNUAL TERMS, CUSTOM DEALS, ENTERPRISE CLAUSES] - Effective dates: [NEW CUSTOMERS, EXISTING CUSTOMERS, RENEWAL BEHAVIOUR] </inputs> <task> Write the rules document: the mapping from every old plan to a new one, the grandfathering policy with its exact duration and end condition, what happens at renewal, upgrade, downgrade, and reactivation, how mid-cycle changes are prorated, the handling of custom and annual contracts, the exception approval process with who can grant what, the billing system changes required, and a decision table support can use to answer any customer question without escalating. </task> <constraints> - Every rule must resolve to a single answer; no ambiguous cases left open. - List the edge cases explicitly, including paused, trialing, and churned-then-returning accounts. - Flag anything that contradicts an existing contract for legal review. </constraints> <format> Return the plan mapping and the decision table as artifacts, then the exception process and the billing change list. </format>

You are a documentation lead who audits whether the docs can carry a launch. <context> We are about to launch and I do not know which docs are missing, wrong, or about to become wrong. I want an audit with a prioritised fix list. </context> <inputs> - What is launching and what it changes: [FEATURE, AFFECTED WORKFLOWS] - Existing documentation structure: [SECTIONS, HOW MANY ARTICLES] - Docs that mention the affected areas: [TITLES OR PLACEHOLDERS] - Audiences for the docs: [END USERS, ADMINS, DEVELOPERS] - Capacity before launch: [WRITER HOURS AVAILABLE] - Localisation requirements: [LANGUAGES OR NONE] </inputs> <task> Audit and produce: the list of documents that must be created, the ones that must be updated because the launch makes them wrong, the ones that become obsolete and should be redirected or archived, and the screenshots and videos that need reshooting. Prioritise by how many users will hit each path and by support ticket risk. For each item give the owner, the effort estimate, the deadline relative to launch, and the minimum acceptable version if we run out of time. </task> <constraints> - Prioritise by user volume on the path and by ticket risk, not by how easy the fix is. - Every item needs a minimum viable version for the case where time runs out. - Include the redirect plan for archived pages so links do not break. </constraints> <format> Return the audit as a prioritised table artifact with owners and deadlines, then the cut line if capacity runs short. </format>

You are a growth analyst who reports early launch results without overreading noise. <context> Two days after launch everyone wants to know if it worked. I want an honest read that separates signal from launch-day spike. </context> <inputs> - Metrics captured so far: [TRAFFIC, SIGNUPS, ACTIVATIONS, REVENUE, WHATEVER EXISTS] - Pre-launch baselines: [SAME METRICS BEFORE LAUNCH] - Goals we set: [TARGETS AND WINDOW] - Channel breakdown: [WHERE TRAFFIC AND SIGNUPS CAME FROM] - Qualitative signals: [COMMENTS, TICKETS, REPLIES, REVIEWS] - Anything that went wrong: [ISSUES, OUTAGES, ERRORS] </inputs> <task> Write the report: the headline result against goal, the metrics table with baseline, actual, and variance, the channel performance ranked with cost where relevant, the activation and quality read on whether new users actually did the thing, the qualitative themes from comments and tickets, what went wrong and its impact, and the three things to do in the next seven days. Explicitly separate what we can conclude at forty-eight hours from what needs two more weeks. </task> <constraints> - Do not declare success or failure on a metric that needs more time; say which ones those are. - Every number stated against its baseline, never in isolation. - Keep the report to one page plus the table. </constraints> <format> Return the report as a document artifact with the metrics table, then the seven-day action list and the metrics still pending. </format>

You are a product operations analyst who turns launch feedback noise into a ranked list of decisions. <context> We have hundreds of comments, tickets, replies, and reviews from the launch and no structure. I need themes with counts and a decision per theme. </context> <inputs> - Feedback sources and rough volume: [SUPPORT TICKETS, SOCIAL COMMENTS, REVIEWS, EMAILS, CALLS] - Paste of the raw feedback: [PASTE AS MUCH AS FITS] - What we already know is broken: [KNOWN ISSUES] - Our roadmap for the next quarter: [PLANNED WORK] - Who the feedback came from where known: [SEGMENTS, PLAN TIERS] </inputs> <task> Cluster the feedback into themes with a count and a representative verbatim quote each. Classify every theme as a bug, a usability problem, a missing capability, a pricing objection, a misunderstanding, or praise. For each theme give the affected segment, the severity, whether it blocks adoption or just annoys, and the recommended action: fix now, schedule, document, message differently, or decline. Flag the themes that indicate we described the product wrongly rather than built it wrongly. </task> <constraints> - Give counts, never impressions; if you cannot count it, say so. - Separate loud from widespread and say which is which. - Keep one representative verbatim quote per theme, unedited. </constraints> <format> Return the theme table as an artifact with counts, classification, and recommended action, then the messaging problems separated from the product problems. </format>

You are an engineering program manager who prioritises the defect list a launch produces. <context> The launch surfaced a queue of issues and everything is being called urgent. I need a defensible priority order and a communication plan. </context> <inputs> - Issues reported: [LIST WITH A ONE-LINE DESCRIPTION EACH] - Users affected per issue where known: [COUNTS OR PROPORTIONS] - Workarounds available: [PER ISSUE] - Engineering capacity this week: [PEOPLE, DAYS] - Revenue or contract exposure: [ANY ACCOUNTS AT RISK] - Release cadence: [HOW OFTEN WE CAN SHIP] </inputs> <task> Prioritise the issues using explicit criteria: user impact breadth, severity of the broken outcome, whether a workaround exists, revenue exposure, and fix effort. Produce the ranked queue mapped to the release cadence, the items to fix this week and the ones to defer with the reason, the issues to document rather than fix, and the communication for each group: what we tell affected users, what goes on the status page or changelog, and what support says while a fix is pending. </task> <constraints> - Show the scoring per issue, not just the resulting order. - An issue with a workaround ranks below one without, at equal severity. - Every deferred item needs a user-facing message. </constraints> <format> Return the scored priority queue as a table artifact, then the fix plan against capacity and the communication per group. </format>

You are a product marketing lead presenting launch results to an executive team. <context> I have thirty minutes with the leadership team and a pile of launch data. They care about outcomes and decisions, not the campaign calendar. </context> <inputs> - Goals set before launch: [TARGETS AND WINDOW] - Actual results: [METRICS WITH NUMBERS] - Baselines: [PRE-LAUNCH COMPARISON] - What worked and what did not: [HONEST ASSESSMENT] - Costs incurred: [SPEND, PEOPLE TIME] - Decisions I need from them: [WHAT I AM ASKING FOR] </inputs> <task> Build the readout: a one-slide summary stating whether we hit the goal and the single most important number, results against each goal with the variance explained, the channel and cost efficiency read, what we learned that changes our next launch, the risks or issues leadership must know about, and the specific decisions and resources I am asking for with the trade-off attached to each. Write the talk track and prepare answers to the five questions executives will ask. </task> <constraints> - Lead with the verdict; no chronological narrative of the campaign. - Every claim about causation labelled as evidence or hypothesis. - Each ask must state what happens if the answer is no. </constraints> <format> Return the slide-by-slide readout with the talk track as a document artifact, then the five anticipated questions with answers. </format>

You are a lifecycle marketer who recovers the people who signed up during a launch and never came back. <context> The launch brought in a wave of signups and most of them never reached first value. I want a sequence that gets a share of them back. </context> <inputs> - What the product does and the first value moment: [PRODUCT, THE MOMENT] - Where people drop off: [THE STEP THEY ABANDON] - Signup volume and activation rate: [NUMBERS] - What we know about why they stalled: [FRICTION, MISSING INPUT, CONFUSION, TIMING] - Channels available: [EMAIL, IN-APP, PUSH, SMS, HUMAN OUTREACH] - Incentive we can offer: [EXTENDED TRIAL, SETUP HELP, DISCOUNT, TEMPLATE] </inputs> <task> Build the sequence: segments by how far they got, a first message that removes the specific blocker for each segment rather than asking them to try again, a second message showing the outcome someone like them achieved, a third offering a shortcut such as a template, an import, or a done-with-you setup, and a final message that asks one question and accepts a no. Give timing, subject lines, the in-app counterpart, the exit conditions, and the win-back metric to watch. </task> <constraints> - Never send a message that only says come back; each one must remove a blocker. - Segment by observed drop-off point, not by days since signup alone. - The final message must make it easy to say no and stay on good terms. </constraints> <format> Return the sequence as a document artifact with segments, timing, and copy, then the exit conditions and the metric to track. </format>

You are a product marketer who keeps a launch alive after launch day. <context> Our launches spike and die within seventy-two hours. I want a plan for the following thirty days that keeps compounding without new engineering work. </context> <inputs> - What launched and what is now available: [FEATURE, ACCESS] - Launch day results and what performed best: [METRICS, TOP CHANNEL] - Assets already produced: [BLOG, VIDEO, POSTS, DOCS, CASE MATERIAL] - Audiences not yet reached: [SEGMENTS, CHANNELS, GEOGRAPHIES] - Capacity for the next month: [PEOPLE, HOURS, BUDGET] - The metric we want to move: [THE ONE NUMBER] </inputs> <task> Build the thirty-day plan week by week: the second-wave audiences and the angle for each, how to repurpose existing assets into new formats rather than creating from scratch, the proof that becomes available now that people are using it (usage data, quotes, results) and how to publish it, the always-on placements the launch content should move into (docs, onboarding, sales sequences, help center), the tests to run on messaging, and the weekly metric checkpoint with a decision at each. </task> <constraints> - No new engineering work; work only with what shipped. - Repurposing must produce a genuinely different format, not the same post again. - Fit inside the stated capacity and say what to drop if capacity shrinks. </constraints> <format> Return the week-by-week plan as a table artifact with owners and formats, then the always-on placements list and the weekly checkpoints. </format>

You are a customer marketing writer who turns an early adopter into a publishable case study. <context> One customer got a real result from the launch and I want a case study that a prospect would actually read, not a testimonial paragraph. </context> <inputs> - Customer and their business: [COMPANY, SIZE, INDUSTRY] - Their situation before: [THE PROBLEM, WHAT THEY TRIED, THE COST] - What they did with our product: [IMPLEMENTATION, TIMELINE, WHO WAS INVOLVED] - Results with numbers: [METRICS, BEFORE AND AFTER, TIMEFRAME] - Quotes we have or can get: [VERBATIM, OR THE PERSON TO ASK] - Approval constraints: [WHAT THEY WILL AND WILL NOT LET US PUBLISH] </inputs> <task> Write the case study: a headline stating the result, a summary box with the company, the challenge, the solution, and the outcome numbers, the before-state narrative in their language, the decision process including what else they considered, the implementation with the honest friction included, the results with the measurement method stated, a forward-looking quote, and a closing call to action. Then produce a one-paragraph version, a social version, and the interview questions if I still need to collect details. </task> <constraints> - Every number needs the measurement method and timeframe attached. - Include at least one honest difficulty; frictionless stories read as fiction. - Respect the approval constraints and mark anything needing sign-off. </constraints> <format> Return the case study as a document artifact, then the short versions and the interview questions for missing details. </format>

You are a customer marketing manager who converts launch goodwill into public reviews. <context> Right after the launch is the best moment to ask for reviews and we always miss it. I want a campaign that collects them without begging or bribing. </context> <inputs> - Review platforms that matter for us: [NAMES] - Customers most likely to leave a positive review: [SEGMENT OR BEHAVIOUR SIGNAL] - How we can detect a happy moment in-product: [SIGNAL, EVENT, SUPPORT RESOLUTION] - What we can offer, if anything: [PLATFORM-COMPLIANT INCENTIVE OR NOTHING] - Volume goal and timeframe: [NUMBER, WEEKS] - Channels for the ask: [EMAIL, IN-APP, HUMAN, SUPPORT FOLLOW-UP] </inputs> <task> Design the campaign: the trigger moments that identify a happy customer, the ask copy per channel that makes it a two-minute task, the platform-specific guidance that stays within each platform's rules on incentives, the prompt set that helps a reviewer write something specific instead of "great tool", the follow-up for people who start and abandon, the handling of a negative review including the response template, and the routine for turning reviews into marketing assets. </task> <constraints> - Never suggest an incentive that breaks a review platform's terms; state the rule per platform. - Never script the review content; give prompts that help them recall specifics. - The negative review response must be public-ready and non-defensive. </constraints> <format> Return the campaign plan as a document artifact with the ask copy per channel, then the reviewer prompts and the negative review response template. </format>

You are a facilitator who runs blameless retrospectives that produce actual changes. <context> Our retros turn into either a victory lap or a blame session, and nothing changes before the next launch. I want a facilitated structure. </context> <inputs> - What launched and the headline result: [LAUNCH, OUTCOME] - Teams involved: [WHO] - What visibly went wrong: [ISSUES, DELAYS, MISSES] - What went better than expected: [WINS] - Data available: [METRICS, TIMELINES, TICKET VOLUMES] - Session length and attendees: [MINUTES, WHO IS IN THE ROOM] </inputs> <task> Write the retro doc: the pre-read summarising the timeline and the data so the session is not spent reconstructing events, the ground rules that keep it blameless, a timed agenda covering what we set out to do, what actually happened, where the plan and reality diverged and why, the systemic causes behind each miss rather than individual mistakes, and what to keep, change, and stop. Then the output format: each action with an owner, a due date, and where it gets embedded so it survives, plus the two things to change in the launch process itself. </task> <constraints> - Focus on systems and process, never on individual performance. - Every action needs an owner, a date, and a place it lives, or it does not count. - Include at least one thing to stop doing, not only things to add. </constraints> <format> Return the pre-read and agenda as a document artifact, then the action capture table and the process changes. </format>

You are a product marketing operations lead who turns one launch into a repeatable process. <context> We just launched and everything lived in one person's head. I want the reusable playbook so the next launch does not start from a blank page. </context> <inputs> - What we just launched and its tier: [LAUNCH, TIER] - What worked and should be repeated: [DETAILS] - What failed or wasted time: [DETAILS] - Assets and templates we created: [LIST] - Team structure and who does what: [ROLES] - Launch frequency going forward: [HOW OFTEN WE EXPECT TO LAUNCH] </inputs> <task> Write the playbook: launch tier definitions with the asset list and effort per tier, the standard timeline per tier as T-minus weeks, the roles and decision rights, the checklist per workstream, the templates to reuse with a note on what to customise each time, the metrics and the reporting format, the known pitfalls from this launch with the guard added for each, and the maintenance rule for keeping the playbook current. Mark which steps are mandatory and which are optional by tier. </task> <constraints> - Everything must be derived from what we actually did, not from a generic best-practice list. - Mark each step mandatory or optional by tier so small launches stay small. - Include the pitfalls with a specific guard, not a reminder to be careful. </constraints> <format> Return the playbook as a document artifact with the tier and timeline tables, then the template inventory and the pitfall-to-guard list. </format>