Quick Ref / Command

Marketing 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.

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