Use launch to plan a new product, important feature, or controlled public test. It treats release as a progression from early feedback to continued adoption. This is useful when a team has a date but lacks an actionable preparation list; minor updates do not all need a major campaign.
Install and invoke
Run this in your project terminal to install only this skill for Claude Code:
npx skills add coreyhaines31/marketingskills --skill launch -a claude-code
Node.js and npx must be available. For Codex, replace -a claude-code with -a codex. In the agent conversation, explicitly ask it to use launch and supply your material. The installation command belongs in the terminal, not in your content brief.
Define what is actually launching
Describe one complete task the product supports, current limitations, the target date, and how many new users the team can help. List real email, blog, social, and partnership assets rather than allowing the plan to assume a large audience.
Example brief:
Use launch to plan the collaborative annotation release in two weeks.
Read release.md. We have two people and can handle ten trial-feedback conversations daily.
Check the journey from signup to the first completed annotation, then plan preparation, launch day, and the following week.
Use only our existing email list and LinkedIn. Give every task an owner, material, dependency, and completion condition.
Verify that the chosen scope delivers a complete experience: readers understand the explanation, enter the product, and reach an initial result. Missing core steps may justify a smaller rollout or additional work. Unrelated features should not indefinitely delay an already useful experience.
Give each channel a job
The skill organizes owned channels, external platforms, and access to other people’s audiences. Choose based on where users are and your ability to respond. Email can notify existing users, social posts can demonstrate a specific task, and partner content can introduce relevant newcomers. Each needs an explicit destination and next action.
A small project can start with controlled invitations and expand according to support capacity without reproducing every named phase. Assign production and review responsibilities for demos, screenshots, and announcements. Show the current product accurately and label experimental capabilities. Investigate current platform rules and audience fit before adding a launch competition; ranking alone is not a sufficient objective.
On release day, verify entry pages, registration, core actions, and feedback channels. Continue with onboarding material, fixes, and updates afterward. Separate announcement exposure, visits, usage starts, and completed tasks in the review. A traffic spike demonstrates attention at that moment; retention requires actual usage evidence.
Rehearse a launch that can be run on a calendar
Break “launch” into internal readiness, a small user release, a wider opening, and post-launch adoption. Even for one feature, check that the demo works, support material and pricing agree, and someone owns incoming feedback. The readiness gate is not a demand for perfection; it prevents the first visitors from hitting known problems that nobody has been assigned to resolve.
Ask for a dated task table with owner, channel, asset, CTA destination, and a success or stop condition. Owned channels may include your site and email; borrowed channels may include a partner’s audience. Adapt the angle to each channel instead of copying one announcement everywhere. If Product Hunt is considered, confirm that its audience matches the product and that someone can respond on launch day. It is not a mandatory launch ritual.
After publishing, examine whether newcomers complete the first useful action, which questions recur, and which channels bring relevant visitors. Update help material for common problems and guide interested but inactive people toward an appropriate first step. If views rise but few people activate, repair the gap between the announcement and the actual experience before buying another round of attention.
Example: decide whether a small update needs a launch
Suppose a team has improved its export flow without adding a new feature. Provide before-and-after steps, an estimate of affected users, and support tickets. Ask: “Use launch to decide which channels should announce this change. First check whether the old friction is actually removed. Plan an in-product notice, help-page update, and short email to affected users. If a broad public campaign is unwarranted, say so.”
Every chosen channel should have a clear recipient and action: an in-product notice links to the new export steps, the help page has accurate screenshots, and the email reaches only people affected. A proposal for Product Hunt, a press release, and ten webinars would confuse the update’s value with launch spectacle. One week later, inspect similar tickets, whether users finish exports, and new questions. Those signals matter more than launch-day likes.
Size the launch to the change
Classify the update by novelty and customer value: a major new product, a meaningful improvement for existing users, or feature parity. Intercom’s launch practice uses different channel mixes: every update can enter the changelog, while only major changes need a dedicated landing page, media outreach, or full campaign. Ask launch for an owner, asset, date, and success measure for each channel. A small fix does not need the machinery of a flagship launch.
After trying Corey’s repository, Vugar Javadov said the former launch-strategy (now this page’s launch) gave him a starting frame after product Q&A, but did not send emails or publish posts. Keyword and other API integrations also require separate accounts and setup. Put that boundary in the execution sheet: for each recommendation, name the asset, owner and actually configured account. A timeline is not a launched channel.