Get technical guidance with ak:ask

Use ak:ask when a marketing project raises a technical or architectural question and you need a direct recommendation before changing anything. The Skill gathers the smallest relevant project context, checks documentation against current source or configuration, and returns options, trade-offs, and next actions. It does not implement the recommendation.

Choose ak:ask for consultation

Use ak:ask when

• You need to choose an architecture, integration pattern, or technology for a marketing site, analytics pipeline, content system, or automation.
• You want to compare approaches against current project constraints.
• You need a risk, reliability, or scalability assessment before planning.
• You want an analysis-only answer and do not authorize workspace changes.

Choose another workflow when

• The marketing objective or acceptance evidence is still unclear. Use ak:brainstorm to define the outcome and compare directions.
• You need a durable implementation plan. Use ak:plan.
• You have a reproducible defect and want a correction. Use ak:fix.
• You need systematic investigation before deciding whether to change anything. Use ak:debugging and state that the run must stop after diagnosis.

ak:ask is a technical consultation Skill in the resolved Marketing package. It is not a campaign-research, positioning, copywriting, or performance-analysis workflow merely because it is installed with Marketing Kit.

Prepare the question and evidence

Before invoking the Skill:

• Complete Onboarding and confirm Marketing Kit is installed for the runtime and scope you are using.
• Open the relevant project if the answer depends on its architecture.
• State the decision, current constraints, and the evidence already available.
• Identify sensitive files, live accounts, private data, or external systems that must remain out of scope.
• Say whether current external documentation is required. Network access and signed-in provider access depend on the tools available in the session.

See Runtime adapters for delivery and component-level differences.

Run the Skill

Ask one decision-oriented question and include the evidence boundary:

/ak:ask "For this landing-page project, should conversion events be sent from the browser, the server, or both? Inspect the current event pipeline, compare data quality and privacy trade-offs, and do not edit files"

/ak:ask "For this landing-page project, should conversion events be sent from the browser, the server, or both? Inspect the current event pipeline, compare data quality and privacy trade-offs, and do not edit files"

$ak:ask "For this landing-page project, should conversion events be sent from the browser, the server, or both? Inspect the current event pipeline, compare data quality and privacy trade-offs, and do not edit files"

By default, the Skill keeps the full scope you requested, adds nothing unrequested, and applies KISS and DRY. Add --yagni when you also want it to challenge and cut scope that is not needed for the stated outcome. Put the desired answer shape and authority boundary in the question itself.

Understand the consultation stages

1. Discover context. The Skill reads repository instructions, the root README, and the routed project documentation relevant to the question.
2. Check current evidence. It compares documentation with current source, tests, configuration, or runtime evidence when those surfaces matter.
3. Assess the architecture. It examines system boundaries, technology choices, scalability and reliability considerations, and risks.
4. Synthesize a recommendation. It applies KISS and DRY, preserves the full requested scope, explains alternatives and trade-offs, and proposes validation points. With --yagni, it also challenges unnecessary scope.
5. Stop before delivery. The output can feed a brainstorm or plan, but the Skill does not start implementation.

The four named advisor perspectives in the Skill describe how the analysis is organized. They do not guarantee four independently callable Agents or a particular model.

Keep the run read-only

Repository inspection can still expose sensitive information if the question is too broad. Name the relevant paths and exclude secrets, customer records, credentials, and unrelated private files. When a current external source is needed, approve the network or provider access separately and review the cited evidence rather than treating general knowledge as current fact.

Review the output and evidence

A useful result should contain:

• An architecture analysis grounded in the inspected project evidence.
• A recommended approach with rationale and viable alternatives.
• Technology guidance with material benefits, costs, and constraints.
• A phased validation or implementation strategy, not unapproved edits.
• Risks, assumptions, evidence gaps, and next actions.
• Unresolved questions listed last when any remain.

Treat a recommendation as guidance, not proof. Verify provider behavior, privacy requirements, data contracts, and operational constraints against their current authoritative sources before acting.

Troubleshoot the consultation

Know the current limits

• The Skill answers technical and architectural questions; it is not a general Marketing strategy oracle.
• Its answer is limited by the project files, tools, provider access, and current evidence available in the session.
• It cannot guarantee performance, conversion, revenue, provider support, or compliance outcomes.
• Stable and beta contain identical ak:ask source content and invocation identity. Runtime projection can still differ by adapter.

Continue with the Marketing Kit overview, define an unclear outcome with ak:brainstorm, or create a reviewed plan with ak:plan.