Shape a marketing outcome with ak:brainstorm

Use ak:brainstorm before multi-step marketing delivery when the desired outcome, boundaries, or approach is not yet settled. The Skill converts an incomplete request into a bounded contract, inspects relevant evidence, and compares up to three viable directions when a real choice exists. It does not execute the selected direction.

Choose ak:brainstorm before delivery

Use ak:brainstorm when

• A campaign, content program, funnel change, or launch has a goal but not a concrete deliverable and acceptance evidence.
• Several approaches could satisfy the objective and their trade-offs matter.
• You need to separate the intended outcome from assumptions about current audience, channel, product, or project behavior.
• A diagnosed problem has multiple cause-aligned solutions.
• A decision needs a durable HTML brief for review before planning.

Choose another workflow when

• You need a direct technical answer without a design loop. Use ak:ask.
• The direction is accepted and you need a durable implementation or CRO plan. Use ak:plan.
• A concrete bug has not been diagnosed. Use ak:debugging or ak:fix; do not brainstorm fixes from symptoms.
• The task is already clear and only needs domain execution. Use the relevant Marketing Skill, keeping publishing, spend, outreach, and account changes as separate approvals.

Prepare the opening contract

Bring the best available evidence and be ready to confirm four fields:

If an accepted brief or plan already contains these fields, point the Skill to it. The workflow should reuse settled decisions and ask only about a material gap.

Run the Skill

/ak:brainstorm "Define a launch outcome for the new team workspace. Use the supplied interview notes, exclude paid media and outbound outreach, and compare at most three directions"

/ak:brainstorm "Define a launch outcome for the new team workspace. Use the supplied interview notes, exclude paid media and outbound outreach, and compare at most three directions"

$ak:brainstorm "Define a launch outcome for the new team workspace. Use the supplied interview notes, exclude paid media and outbound outreach, and compare at most three directions"

Choose optional behavior deliberately

When --html is selected, the brief includes the four contract fields, approach trade-offs, recommendation, unresolved risks, and an implementation workflow diagram. For UI/UX topics it also calls for annotated mockups. The file uses inline assets so it can be opened locally without a build or network dependency.

Understand the workflow stages

1. Capture or reuse the contract. The Skill identifies the outcome, constraints, non-goals, and acceptance criteria.
2. Inspect relevant evidence. It reads the smallest useful project, content, test, or live-state surface before claiming an approach is feasible.
3. Route bugs through diagnosis. It captures the expected repaired behavior, then scouts and proves the root cause before discussing solutions.
4. Compare meaningful options. When a real design choice exists, it presents up to three viable approaches and their trade-offs.
5. Recommend a sufficient direction. It applies KISS and DRY, preserves the full requested scope, adds nothing unrequested, and records remaining uncertainty. With --yagni, it also challenges unnecessary scope.
6. Hand off without executing. It passes the contract, chosen direction, evidence, and unresolved risks to a planning or delivery workflow.

A clear request does not require a ceremonial interview. A missing answer should be requested only when it would materially change the result, safety boundary, or public contract and cannot be discovered from evidence.

Keep decisions and mutations separate

If the workflow inspects analytics, customer research, or live platforms, limit it to approved data and current access. Do not send credentials, secrets, personal data, or confidential audience records to an external service without separate authorization and an acceptable data-handling path.

Review the output and evidence

A useful handoff should include:

• The accepted outcome, constraints, non-goals, and acceptance criteria.
• The current evidence inspected and any gaps or uncertainty.
• Up to three viable approaches when the choice is material.
• A recommended direction with explicit trade-offs.
• Risks, unresolved decisions, and the next owning workflow.
• A local brainstorm.html only when --html was requested.

The result is ready for planning when the contract is concrete and the chosen direction is supported by the available evidence. It is not proof that the campaign, content, or product change will produce a business result.

Troubleshoot the brainstorm

Know the current limits

• Brainstorming improves decision structure; it cannot guarantee demand, conversion, revenue, campaign performance, or platform support.
• Evidence quality is limited by the inputs, project access, tools, and current provider state available in the session.
• --html can represent a proposed experience, but it is not a deployed page, tested campaign, or approved creative asset.
• Stable and beta contain identical ak:brainstorm source content and invocation identity.

Continue with ak:plan for a durable plan or return to the Marketing Kit overview to choose a domain workflow.