Get an architectural answer with ak:ask

Use ak:ask when you need a direct technical or architectural answer before changing code. The Skill discovers the relevant project context, evaluates the question from design, technology, scalability, and risk perspectives, and ends with practical next steps rather than implementation.

Choose ak:ask for a focused consultation

Use ak:ask when

• You need an architecture or technology recommendation.
• You want to compare patterns, frameworks, or solution boundaries.
• You need trade-offs, risks, and validation steps before making a decision.
• You want an evidence-backed answer without an interview or workspace changes.

Choose another workflow when

• You need the problem reframed through a one-question interview. Use ak:advise.
• You need to explore several delivery directions. Use ak:brainstorm.
• You need to locate files, symbols, tests, or relationships first. Use ak:scout.
• You want a plan or implementation. Continue with ak:plan or ak:cook only after accepting the direction.

Prepare the project and runtime

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the runtime and scope you are using.
• Open the project whose current architecture or constraints should inform the answer.
• State the decision, known constraints, and alternatives already considered.
• Include the evidence or acceptance condition that would make the answer useful.

Run the Skill

/ak:ask "Should this service publish domain events directly, or write an outbox record first? Compare reliability, operational cost, and migration risk against the current repository patterns."

/ak:ask "Should this service publish domain events directly, or write an outbox record first? Compare reliability, operational cost, and migration risk against the current repository patterns."

$ak:ask "Should this service publish domain events directly, or write an outbox record first? Compare reliability, operational cost, and migration risk against the current repository patterns."

The Skill accepts one technical question. By default, it addresses the full requested scope and adds nothing unrequested. Add --yagni to challenge and cut scope that is not needed for the stated outcome. The Skill has no default file output.

Describe the question clearly

Useful input names:

• Decision: State what must be chosen or understood.
• Context: Identify the affected system, users, interfaces, and current design.
• Constraints: Include compatibility, reliability, scale, security, time, or maintenance limits.
• Alternatives: Name the serious options already under consideration.
• Evidence: Point to current source, tests, configuration, documentation, or measurements that should ground the answer.
• Success test: Explain what the recommendation must help you decide next.

Understand what happens during a run

1. The Skill discovers project authority. It reads repository instructions, the root README, and the relevant documentation route.
2. The Skill verifies current claims. It checks source, tests, configuration, and runtime evidence when the question depends on them.
3. The Skill fills evidence gaps. If architecture context is insufficient, it can route a bounded search through ak:scout.
4. The Skill evaluates four perspectives. It considers system boundaries, technology choices, scalability and reliability, and risks and trade-offs.
5. The Skill synthesizes a recommendation. It favors the smallest solution that satisfies the evidence and constraints.
6. The Skill identifies next actions. It proposes proofs of concept, measurements, or decision gates instead of starting implementation.

Keep the answer advisory

The source-defined workflow does not require a provider, credential, paid service, or external publication. Project inspection remains limited to the files and tools available in the active session. Keep unrelated private or sensitive material outside the requested evidence scope.

Verify the result

A useful answer should contain:

• An architecture analysis grounded in the current context.
• A recommended direction with explicit rationale.
• Meaningful alternatives and their trade-offs.
• Technology guidance with relevant benefits and costs.
• A phased validation or implementation strategy.
• Concrete next actions and remaining evidence gaps.

Treat the result as decision support. Verify material security, performance, and production claims with the owning specialist workflow or test before acting.

Troubleshoot or continue

Continue with ak:plan only after the recommendation and validation gates are accepted. Use ak:cook when the implementation contract and authority are already clear.

Know the current limits

• The answer is limited to the evidence available in the current session.
• The four perspectives organize one consultation; they do not independently prove the recommendation.
• The Skill does not replace diagnosis for a concrete failure or specialist review for a release decision.
• Cursor slash invocation is user-verified evidence, not proof of full runtime parity.
• Stable and beta package the same ak:ask workflow.