Create marketing delivery plans with ak:plan

Use ak:plan to turn a defined marketing or technical requirement into durable plan files for review. The Marketing-owned variant can create fast, researched, parallel, two-approach, CI-repair, and conversion-rate-optimization plans. It can also validate a plan or change its index visibility after confirmation. It does not implement the plan.

This Skill is not the Engineer Kit's same-named planning workflow. Its own source, subcommands, file shape, CRO route, and dependency limits apply.

Choose ak:plan for a durable handoff

Use ak:plan when

• A marketing site, analytics, automation, content system, or campaign-support change needs phased implementation instructions.
• You want a CRO plan grounded in supplied issues, approved content, or an inspected page.
• You need to compare two implementation approaches or identify parallel phases with exclusive file ownership.
• You need a plan for a GitHub Actions failure after collecting the relevant run URL and logs.
• You want to validate assumptions in an existing plan before coding.

Choose another workflow when

• The outcome or direction is not settled. Use ak:brainstorm.
• You only need technical advice. Use ak:ask.
• You want to execute an accepted technical plan. Use ak:cook.
• You have a concrete defect and need diagnosis plus correction. Use ak:fix.
• You need a broad marketing strategy rather than an implementation or CRO plan. Use the relevant domain planning Skill from the Marketing Kit.

Prepare inputs and planning access

Before invoking the Skill:

• Complete Onboarding and confirm the Marketing Kit installation, runtime, and scope.
• Provide the outcome, constraints, non-goals, and observable success criteria.
• Open the relevant project and allow the Skill to read repository instructions, documentation, source, tests, and existing plans.
• Decide whether local plan-file creation is authorized. Planning is not read-only: creation modes write a plan directory and phase files.
• For ci, provide a GitHub Actions URL and ensure gh is installed and authorized if log access is expected.
• For URL, screenshot, video, or provider-backed CRO evidence, approve the required browser, network, or multimodal access separately.

Run the Skill

Create a bounded CRO plan without authorizing live changes:

/ak:plan cro "Plan improvements for the supplied signup-page evidence. Keep consent language unchanged, define one-variable experiments, and do not edit, publish, or launch the page"

/ak:plan cro "Plan improvements for the supplied signup-page evidence. Keep consent language unchanged, define one-variable experiments, and do not edit, publish, or launch the page"

$ak:plan cro "Plan improvements for the supplied signup-page evidence. Keep consent language unchanged, define one-variable experiments, and do not edit, publish, or launch the page"

Select the exact route

The canonical argument shape is [archive|ci|cro|fast|hard|parallel|two|validate] [task].

Understand plan creation stages

1. Resolve plan context. If an active or branch-suggested plan exists, the Skill asks whether to use or activate it instead of silently replacing it.
2. Clarify the task. It asks only for details needed to create a useful plan.
3. Load the selected route. The first argument selects its matching reference workflow; otherwise the Skill chooses fast or hard based on complexity.
4. Inspect evidence. Creation routes read project instructions and relevant documentation, source, tests, and plans. Research routes add bounded researchers; CRO can inspect supplied page or media evidence.
5. Write the plan. Creation routes produce plan.md, phase files, and route-specific reports under the configured plan directory.
6. Review before delivery. The Skill asks you to inspect the plan and does not begin implementation.

Plans use frontmatter including title, description, status, priority, effort, branch, tags, and created. The overview links to phase files; each phase records context, requirements, related files, implementation steps, todo items, success criteria, risks, security considerations, and next steps. On the hard route, a risk based on a breakable assumption also records the observable signal that it failed and whether to adjust or stop and replan.

Keep planning separate from external action

For CRO, treat the packaged framework as planning guidance. Validate claims, privacy requirements, accessibility, message match, tracking, and experiment design against current evidence and policy. Do not publish numerical uplift, conversion, revenue, or timing claims from generic heuristics.

For archive, confirmation is required before changing index visibility. Canonical plan files stay in the repository. Physical deletion is a separate, explicit user operation and is not part of this Skill's archive route.

Review the plan and evidence

A useful result should provide:

• A concise plan.md with objective, status, priority, effort, branch, tags, phase links, and progress.
• Phase files with requirements, related files, implementation steps, success criteria, risks, security considerations, and next steps.
• Research, scout, or report artifacts only when the selected route needs them.
• For parallel, a dependency graph and non-overlapping file ownership.
• For two, two distinct viable approaches, their load-bearing assumptions, first failure conditions, worst plausible cases, switching costs, and a recommendation that favors reversibility when critical evidence is missing.
• For validate, confirmed decisions and plan-revision items.
• Unresolved questions listed last.

Before handing the plan to ak:cook, verify that paths and contracts match the current project, success criteria are observable, external effects are called out as approvals, and no private data or unsupported performance claim appears.

Troubleshoot planning

Know the current limits

• Several routes rely on injected Plan Context, a planning Skill, routed SlashCommands, Agents, or tools. Projection of ak:plan does not guarantee identical availability of those dependencies across runtimes.
• The package exports no Marketing command catalog; references to /plan:* are internal workflow dependencies, not additional public Marketing commands.
• Research and CRO planning are limited by approved data, current sources, and available browser or provider access.
• A plan cannot guarantee conversion, revenue, performance, implementation quality, provider behavior, or delivery dates.

Continue with ak:cook only after approving a technical plan, or return to the Marketing Kit overview for domain workflows.