Plan phased launches with ak:launch-strategy

Turn a product, feature, or update into a phased launch plan with channel roles, assets, approval gates, measurement, and post-launch follow-through.

Use ak:launch-strategy to plan a product launch, feature announcement, release, early-access program, waitlist, or product update. The Skill organizes audience, positioning, phases, channel roles, assets, owners, launch gates, measurement, and post-launch adoption work into a reviewable strategy.

The output is a plan and checklist. It does not release product access, publish a page or listing, contact users or partners, change a live product, activate tracking, open registration, start charging, or commit media or partner spend without separate approval.

Choose ak:launch-strategy for release-level coordination

Use ak:launch-strategy when

You need a launch plan for a new product, major feature, early-access program, announcement, or meaningful update.
You need to sequence internal, alpha, beta, early-access, and full-launch stages with evidence and go/no-go gates.
You need to coordinate owned, rented, and borrowed channels without assuming they have equal control or availability.
You need launch assets, onboarding, support, measurement, feedback, adoption, and post-launch work assigned to owners.
You want to decide whether an update needs a full campaign, targeted announcement, or release-note treatment.

Choose another workflow when

The launch direction is approved and you need an individual multi-channel campaign. Use ak:campaign.
You only need paid-media strategy or operations. Use ak:paid-ads or ak:ads-management.
The product, claims, audience, release scope, or readiness criteria are still unknown. Complete product and market discovery before choosing a date.
You only need to publish an already reviewed asset. Use the approved publication workflow with the exact destination and authority.

Run a product-launch workflow

Use the launch chain to turn evidence into an approved operating plan. It does not grant publication, account, provider, production, or spending authority.

Stage	Skill	Decision produced
Establish evidence	`ak:marketing-research`	Dated market, audience, competitor, and channel evidence with uncertainty separated.
Choose packaging	`ak:pricing-strategy`	Reviewable packaging and pricing options; a human selects the approved offer.
Coordinate the launch	`ak:launch-strategy`	Audience, positioning, stage plan, channel roles, asset matrix, owners, gates, risks, and measurement contract.
Plan execution	`ak:campaign`	Campaign brief, messages, channel plan, creative/test matrix, schedule, budget assumptions, and approval points.
Measure and decide	`ak:analytics`	KPI definitions, instrumentation checks, reporting cadence, decision thresholds, and follow-up actions.

If engineering work is required, create a bounded ak:handoff containing the approved user outcome, acceptance criteria, assets, dates, dependencies, and non-goals. Engineer Kit then plans, implements, and tests the change. Accept the handoff back only with evidence and remaining risks; do not treat “code complete” as launch approval.

At every stage, record the owner and gate for messaging, legal/compliance, privacy, brand, pricing, spend, publication, production, and rollback. Stop when evidence is stale, an owner is missing, instrumentation cannot support the KPI, or a downstream date depends on unapproved work.

Prepare the launch contract

Provide what is launching, who it is for, the user problem and approved claims, release scope, current readiness, access model, target date or window, audience evidence, existing owned channels, candidate external channels, partners, budget ceiling, pricing and eligibility decisions, tracking state, onboarding and support capacity, known risks, and measurable readiness and outcome criteria.

For any named platform, marketplace, community, email provider, or partner, verify current rules, account access, submission requirements, fees, moderation, and availability. A mention in the Skill does not prove current platform support or a connected account.

Runtime	Invocation	Availability boundary
Claude Code	`/ak:launch-strategy ...`	Native delivery is the default; plugin delivery is explicit. Publishing and product access remain separate.
Cursor	`/ak:launch-strategy ...`	Slash invocation is user-verified. Channel, provider, and automation parity is not established.
Codex	`$ak:launch-strategy ...`	Native Skill discovery is supported. Marketing Hook projection is partial and there is no Marketing statusline.

See Runtime adapters before assuming that runtime automation is equivalent.

Invoke a plan-only launch workflow

/ak:launch-strategy "Plan the staged launch of the approved team analytics feature for existing workspace admins. Define readiness gates, owned/rented/borrowed channels, assets, onboarding, support, measurement, and rollback signals. Draft only—do not enable access, publish, send, list, charge, or spend"

/ak:launch-strategy "Plan the staged launch of the approved team analytics feature for existing workspace admins. Define readiness gates, owned/rented/borrowed channels, assets, onboarding, support, measurement, and rollback signals. Draft only—do not enable access, publish, send, list, charge, or spend"

$ak:launch-strategy "Plan the staged launch of the approved team analytics feature for existing workspace admins. Define readiness gates, owned/rented/borrowed channels, assets, onboarding, support, measurement, and rollback signals. Draft only—do not enable access, publish, send, list, charge, or spend"

The canonical argument shape is [product or feature]. Add the target audience, release state, evidence, authority, and stop condition to make the plan usable.

Map channels with the ORB framework

The Skill uses three channel types:

Channel type	Role	Control boundary
Owned	Website, product, email list, blog, podcast, or branded community used to build a direct relationship	You still need consent, product and publication access, content approval, and operational ownership. “Owned” does not mean unrestricted.
Rented	Social networks, app stores, marketplaces, video platforms, or communities used for reach	The provider controls policy, algorithms, accounts, moderation, formats, and availability. Verify current rules before planning a launch action.
Borrowed	Partners, guests, creators, newsletters, events, podcasts, or collaborations used to reach another audience	Outreach, compensation, content rights, disclosure, scheduling, audience handling, and partner approval remain separate.

Select channels from evidence about the target audience and team capacity. Do not turn the framework into a fixed requirement to use every channel or funnel all personal data into an owned system.

Move through launch stages deliberately

Internal launch. Test with approved internal or friendly users, collect usability and functionality evidence, and record blocking defects. Access, data, and incentives still need an owner.
Alpha launch. Invite a bounded external group, prepare an early-access surface, and validate the working experience. An announcement, landing page, signup form, or invite is a publication or contact action, not just planning.
Beta launch. Expand the approved cohort, test messaging and onboarding, gather qualitative and quantitative evidence, and define support and incident capacity. “Beta” must not weaken privacy, security, billing, or claims review.
Early-access launch. Increase access in reviewed batches or through another approved rule, validate usage at greater scale, and finalize the full launch decision. Credits, surveys, screenshots, demos, and experimental toggles each require their own product and communication review.
Full launch. Open the approved access model, publish reviewed assets, run scheduled communications, monitor product and channel health, and execute the rollback or pause plan when thresholds are crossed.
Post-launch adoption. Continue onboarding, education, feedback, support, measurement, and later announcements. Separate an observed result from a platform-reported attribution or forecast.

Keep launch effects behind named gates

A launch checklist contains live actions

Opening signups, enabling a feature, changing pricing or access, starting charges, publishing a site or marketplace listing, sending email, posting to social channels, contacting partners, adding in-product messages, installing tracking, and spending budget all change external state. Assign a named owner, exact scope, credentials, approval, timing, monitoring, and rollback or pause path to each action.

Gate	Evidence and approval needed
Product access	Release readiness, eligibility, capacity, security, privacy, support, incident, migration, and rollback review
Pricing or charging	Approved offer, currency, tax, billing behavior, notices, refunds, support, and finance/legal ownership
Publication or listing	Final copy and claims, assets and rights, destination account, platform policy, links, accessibility, and publication owner
Email, social, in-app, or partner outreach	Audience or recipient, consent or lawful basis, sender account, frequency, disclosure, schedule, moderation, and opt-out/support path
Tracking and feedback	Event definitions, notice and consent, fields, retention, access, vendor destinations, survey incentives, and analysis owner
Paid or partner spend	Currency, vendor or partner, daily and total ceiling, contract, attribution, stop conditions, and authorized approver

Review outputs and evidence

A complete launch plan should include the product and audience contract, readiness criteria, ORB channel map, five-stage plan, assets, owners, dependencies, dates or relative sequencing, budget boundaries, approval gates, support and incident coverage, measurement definitions, pause and rollback signals, and post-launch work.

The Skill defines no canonical output file path. Agree on a controlled destination before writing. For each launch decision, preserve the evidence, approver, timestamp, current state, published destination or object ID when applicable, and follow-up owner. Historical company and platform examples in the Skill are inspiration only, not forecasts or verified current playbooks.

Troubleshoot safely

Symptom	Safe next step
The runtime does not recognize `ak:launch-strategy`	Confirm Marketing Kit target and scope, restart the runtime, then follow Runtime cannot find a Skill or Agent.
A date exists but readiness criteria do not	Treat the date as provisional. Define product, support, data, billing, channel, and rollback gates before committing externally.
A platform tactic looks stale	Verify current official rules, account requirements, formats, fees, and moderation before including it in the approved plan.
The plan conflates a draft with publication	Split creation, review, scheduling, and publication into separate owners and states. Keep credentials out until publication is approved.
Early access creates support or stability risk	Reduce the cohort, pause new invites, preserve incident evidence, and use the approved product rollback or access-control path.
Metrics do not prove impact	State the attribution and comparison limits, preserve raw definitions and dates, and avoid claiming causation or guaranteed momentum.
A launch action partly succeeds	Capture the exact external state and IDs, stop retries, notify the owner, and use the bounded platform or product recovery plan.

Know the current limits

Platform rules, marketplace behavior, channel reach, provider pricing, account access, and audience response can change independently of AgentKit.
The Skill cannot guarantee attention, ranking, press, signups, adoption, conversion, retention, revenue, or launch momentum.
Historical case studies and outcomes in the packaged source are omitted here as durable claims.
A launch plan does not replace product, engineering, security, privacy, legal, finance, support, brand, accessibility, or platform review.

Continue with the Marketing Kit overview or use ak:campaign after the launch strategy and gates are approved.

Plan phased launches with ak:launch-strategy

On this page