Quick Ref / Command

Engineer Kit

/ak:ask

Architecture consultation before code

Answers technical and architectural questions by gathering context, consulting systems, technology, scalability, and risk perspectives, then synthesizing concise strategic guidance without implementing.

01

Read the question

02

Discover context

03

Scout if needed

04

Consult four lenses

Rule 01

Answer before changing code; this is consultation, not execution.

Rule 02

Context is project-specific, so do not assume every repo has the same docs or architecture files.

Rule 03

Deliver the requested scope fully; only --yagni allows cutting unnecessary scope.

Rule 04

Every recommendation should name trade-offs, risks, and the condition where it stops holding.

Execution Map

Core lanes from input to output, aligned with the command's real execution path.

01

Start

Input, scope, route

  1. 1 Read the question Identify the design decision, trade-off, or best-practice evaluation the user actually needs answered.
  2. 2 Discover context Read repository instruction surfaces, README, and relevant docs; verify documentation claims against source, tests, config, or runtime evidence where applicable.
02

Work

Agent / skill execution

  1. 3 Scout if needed If architecture context is insufficient, use ak:scout to gather codebase facts instead of advising from assumptions.
  2. 4 Consult four lenses Evaluate system boundaries, technology choices, scalability/reliability, and risks with mitigation and failure conditions.
03

Verify

Gate, review, validation

  1. 5 Synthesize guidance Combine the lenses into direct architecture analysis, recommendations, technology guidance, implementation strategy, and next actions.
  2. 6 Stay concise Be honest, blunt, and to the point; include alternatives and validation points, but do not drift into coding.

Syntax, arguments, subcommands

How to invoke the skill: syntax, positional arguments, shared options, then each subcommand with its own syntax and outcome.

Syntax

/ak:ask [technical-question] [--yagni]

Arguments

[technical-question] Required

Technical question

Architecture or technology question to answer, including the decision, constraints, alternatives, and evidence to ground the consultation.

/ak:ask "Should this service publish domain events directly, or write an outbox record first?"

Shared options

--yagni

Cut unneeded scope

Challenge and remove scope that is not needed for the stated outcome. Does not remove work required to answer the question.

/ak:ask "Do we need event sourcing for audit trails?" --yagni

Sample Prompt

Concrete invocations for each flag, subcommand, mode, or route available in the live workflow.

Architecture decision Recommended
/ak:ask "Should this service stay REST or move to gRPC for internal calls?"
Use when:
Use when you need a strategic answer before planning or coding.
Expected:
Gathers context, compares boundaries and trade-offs, and returns direct guidance.
YAGNI architecture challenge
/ak:ask "Do we need event sourcing for audit trails?" --yagni
Use when:
Use when you want unnecessary scope challenged and cut from the recommendation.
Expected:
Evaluates the full question, then cuts only what is not needed for the stated outcome.
Best-practice review
/ak:ask "What auth boundary should our admin dashboard use?"
Use when:
Use for implementation strategy, proof-of-concept criteria, and validation points without edits.
Expected:
Returns recommendations, alternatives, risks, and next actions rather than a code patch.

Handled Scope

  • System boundaries
  • Technology strategy
  • Scalability and reliability
  • Risk analysis
  • Decision trade-offs

Related skills

Next