Quick Ref / Command

Engineer Kit

/ak:fable-thinking

Evidence-grounded reasoning

Evidence-grounded reasoning protocol for hard diagnosis, review, decisions, constrained writing, and calibrated outcome-first delivery.

01

Run the Floor

02

Set Depth

03

Constraint Loop

04

Frame

Rule 01

Familiarity is retrieval, not verification.

Rule 02

A fluent explanation is not evidence.

Rule 03

User goals are absolute; user diagnoses are testimony to verify.

Rule 04

Surface-form constraints are solved by mechanical checks, not by rereading.

Rule 05

Confidence rises only when evidence improves.

Execution Map

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

01

Start

Input, scope, route

  1. 1 Run the Floor State the real end-state goal, simulate the answer through to verification, and account for every request detail.
  2. 2 Set Depth Use proportionality: Direct for trivial reversible tasks, Standard for normal work, Full for high-stakes or contested outcomes.
02

Work

Agent / skill execution

  1. 3 Constraint Loop For exact counts, banned letters, acrostics, strict formats, or other surface constraints, expand, draft, mechanically verify, repair, and re-verify.
  2. 4 Frame Restate the ask, separate literal request from underlying goal, mark scope boundaries, and pick load-bearing facts.
03

Verify

Gate, review, validation

  1. 5 Ground Sort claims as observed, derived, prior, or assumed; verify load-bearing facts with tools or primary sources.
  2. 6 Reason Hold multiple hypotheses, choose discriminating tests, demand mechanisms, simulate concrete values, and scan negative space.
04

Close

Report, handoff, artifact

  1. 7 Attack Try to kill the conclusion, run cheap kill-tests, audit confidence, and name the weakest link.
  2. 8 Deliver Calibrated Lead with outcome, match grammar to evidence level, report partials plainly, and close with unresolved risks if any.

Syntax, arguments, subcommands

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

Syntax

/ak:fable-thinking [task or question to reason through]

Arguments

[task or question to reason through] Required

Reasoning target

Natural-language question, diagnosis, review, decision, or constrained-writing task. Include evidence, scope, authority boundary, success criteria, and any mechanical output rule; this guides reasoning and does not authorize edits or external action.

/ak:fable-thinking "Assess whether the proposed retry change addresses Friday's checkout failures. Use the diff and incident logs, hold at least two hypotheses, and lead with GO, CAUTION, or STOP plus the weakest link."

Modes / Routes

Direct

Low risk

Research:
Floor + Claim Discipline
Review:
Check leftovers
Validate:
Answer directly
Standard

Normal work

Research:
All five moves internally
Review:
Attack pass
Validate:
Evidence-grounded deliverable
Full

High stakes

Research:
Written five moves
Review:
Mandatory Attack
Validate:
Weakest link stated

Don't skip the required step

Each item contrasts a tempting shortcut with the required approach.

Tempting shortcut

This looks like a standard case.

Do this instead

Template hijack is most likely when the surface looks familiar. Run the Floor first.

Tempting shortcut

The wording satisfies the constraint.

Do this instead

Surface constraints require enumeration or tooling. Re-reading is the failure mode.

Tempting shortcut

I have one strong hypothesis.

Do this instead

One hypothesis is pattern matching. Add a competing mechanism and pick a discriminating test.

Sample Prompt

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

Root cause diagnosis Recommended
/ak:fable-thinking diagnose why this flaky test passes locally but fails in CI
Use when:
Use when a familiar-looking failure needs mechanism, not a template fix.
Expected:
Runs the Floor, verifies load-bearing facts, compares multiple hypotheses, chooses discriminating checks, attacks the conclusion, and reports calibrated findings.
Strict surface constraint
/ak:fable-thinking write a product tagline with exactly seven words and no letter e
Use when:
Use when exact counts, banned letters, acrostics, or strict formats are the hard part.
Expected:
Expands the constraint into a mechanical test, drafts privately, verifies the exact output by tool or unit counting, repairs violations, and delivers only the verified text.
High-stakes decision
/ak:fable-thinking decide whether to rewrite or patch this subsystem before launch
Use when:
Use when architecture, irreversibility, novelty, or contested tradeoffs require Full depth.
Expected:
Applies proportional depth, writes the five moves when stakes demand it, types claims by evidence level, runs an Attack pass, and names the weakest link before the outcome.
Review a claim-heavy answer
/ak:fable-thinking review this incident analysis for unsupported claims and missing kill-tests
Use when:
Use when a review or analysis may be fluent but needs evidence ranking and adversarial self-checks.
Expected:
Separates observed, derived, prior, and assumed claims; checks whether cheap contrary evidence was sought; flags scope drift, partial evidence, and any overconfident wording.

Handled Scope

  • Multi-hypothesis debugging and root-cause analysis
  • Architecture, strategy, and contested technical decisions
  • Evidence-backed code review and security-style reasoning
  • Strict-format and constrained-writing verification
  • Calibrated delivery with claim discipline

Related skills

Next