Quick Ref / Command

Marketing Kit

Beta only

/ak:debug

Systematic debugging

Systematic debugging and investigation: prove root cause, trace backward, validate layers, inspect logs/CI/databases/performance, and verify before claiming success.

01

Triage symptom

02

Load method

03

Gather evidence

04

Trace backward

Rule 01

Root cause before fix.

Rule 02

Fix the source, not the symptom.

Rule 03

Validate defense-in-depth after the cause is known.

Rule 04

Fresh verification evidence is required before completion claims.

Rule 05

When stuck, activate problem-solving rather than guessing.

Execution Map

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

01

Start

Input, scope, route

  1. 1 Triage symptom Classify the issue as code bug, test failure, build failure, server incident, CI/CD failure, database issue, performance regression, or frontend visual problem.
  2. 2 Load method Select the relevant reference: systematic debugging, root-cause tracing, defense-in-depth, verification, system investigation, log/CI, performance, reporting, tracking, or frontend verification.
02

Work

Agent / skill execution

  1. 3 Gather evidence Collect reproduction steps, logs, stack traces, failing commands, database signals, latency metrics, or screenshots before changing code.
  2. 4 Trace backward Follow the call stack or data path to the original invalid input, state mutation, race, environment mismatch, or polluter.
03

Verify

Gate, review, validation

  1. 5 Test hypotheses Use targeted probes to confirm the root cause and eliminate plausible rivals before implementation.
  2. 6 Fix at source Patch the root condition, not the visible symptom; add entry, business-logic, environment, or instrumentation validation as needed.
04

Close

Report, handoff, artifact

  1. 7 Verify fresh Run the exact command, reproduction, browser check, CI log query, database diagnostic, or performance measurement proving the issue is gone.
  2. 8 Report evidence Summarize root cause, fix, validation layers, verification output, remaining risk, and any investigation gaps.

Syntax, arguments, subcommands

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

Syntax

/ak:debug [error or issue description] [--ultra]

Arguments

[error or issue description] Required

Failure to investigate

Exact symptom, reproduction command, expected and actual behavior, timing, environment, logs, stack trace, and authority boundary. The skill uses this evidence to prove root cause before changing code.

/ak:debug "pnpm test fails in session-cache.test.ts with expected 1 write, received 2"

Output / publish flags

Only flags that change the artifact or publish it. Not the full option set.

--ultra

Best-of-5 diagnosis

Build one evidence packet, run five read-only candidate diagnoses, then verify the winning root cause before any fix.

Example

/ak:debug intermittent payment failure --ultra

Don't skip the required step

Each item contrasts a tempting shortcut with the required approach.

Tempting shortcut

Quick fix now, investigate later.

Do this instead

That creates new bugs and hides the real failure path.

Tempting shortcut

It is probably X.

Do this instead

Hypotheses need evidence and rival elimination.

Tempting shortcut

Tests pass, done.

Do this instead

Read the output and verify it covers the original symptom.

Sample Prompt

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

Failing test Recommended
/ak:debug this test fails only when the full suite runs
Use when:
Use when root cause must be proven before fixing a test failure, especially with shared state, ordering, or hidden dependencies.
Expected:
Runs systematic debugging first, traces the polluter or original trigger when needed, eliminates rival hypotheses, then fixes at source and verifies with fresh evidence.
CI failure
/ak:debug GitHub Actions deploy job fails after migration step
Use when:
Use when a CI/CD or deployment failure needs log evidence, correlation across pipeline steps, and a proven root cause before changes.
Expected:
Collects the failing command, GitHub Actions logs, and relevant environment clues, identifies the root cause, proposes the source fix, and reports verification evidence.
Performance regression
/ak:debug checkout API latency doubled after last release
Use when:
Use when performance degradation or slow database/API behavior needs bottleneck evidence instead of guesswork.
Expected:
Applies the system investigation and performance diagnostics references, gathers latency or query evidence, traces the bottleneck, and defines fresh measurements for verification.
Best-of-5 diagnosis
/ak:debug production checkout latency doubled --ultra
Use when:
Use when a high-stakes issue needs five independent read-only candidate diagnoses and a verifier before any fix.
Expected:
Builds one immutable evidence packet, dispatches five read-only diagnoses, has a verifier select or reject the winner, then requires fresh evidence before any fix.

Handled Scope

  • Systematic debugging
  • Root-cause tracing
  • Defense-in-depth validation
  • CI/CD log analysis
  • Database diagnostics
  • Performance profiling
  • Frontend verification

Related skills

Next