Apply evidence-led reasoning with ak:fable-thinking

Use ak:fable-thinking when the quality of the conclusion matters more than the speed of the first plausible answer. The Skill applies a reusable reasoning protocol: check the real goal, verify evidence, hold competing hypotheses, simulate concrete cases, challenge the conclusion, and calibrate the final claim to what was actually observed.

Choose ak:fable-thinking for reasoning quality

Use ak:fable-thinking when

• You are diagnosing a failure, reviewing a risky change, or making an architecture, strategy, security, data, or money decision.
• The user's proposed cause may be wrong and needs independent evidence.
• A simple-looking question contains details that may invalidate the familiar answer.
• The output has a mechanically checkable constraint such as an exact count, forbidden character, acrostic, or strict format.
• You want an evidence-backed assessment without automatically implementing a fix.

Choose another workflow when

• You need broad ideation before evaluating a direction. Use ak:brainstorm.
• You need a structured exploration of a hard problem. Use Problem solving.
• You already have a concrete bug and want diagnosis plus an authorized repair. Use ak:debug or ak:fix.
• You need implementation, testing, or review as the main outcome. Use the relevant delivery Skill and ask it to retain evidence-led reasoning.

Prepare the question and evidence

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the active runtime and scope.
• State the decision or deliverable, intended outcome, stakes, time horizon, authority boundary, and what would count as success.
• Provide direct evidence such as files, logs, measurements, failing output, requirements, or primary documentation, plus permission for any additional read-only checks.
• Separate your observation from your diagnosis. “The request times out” is evidence; “the cache is broken” is a hypothesis until verified.
• For hard output constraints, provide the exact governed text, counting unit, allowed exceptions, and format.

See Runtime adapters for delivery and component boundaries.

Run the Skill

Pass the question or task in natural language. The Skill chooses depth from the stakes, irreversibility, and novelty after running its minimum check.

/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, do not edit files, and lead with a GO, CAUTION, or STOP recommendation plus the weakest link."

/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, do not edit files, and lead with a GO, CAUTION, or STOP recommendation plus the weakest link."

$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, do not edit files, and lead with a GO, CAUTION, or STOP recommendation plus the weakest link."

For constrained writing, include the mechanical rule directly: for example, “Return exactly 80 words; count whitespace-delimited words on the final text; the title is excluded.” The Skill treats such a request as verification work, not a casual wording task.

Understand the execution depth

The protocol does not require exposing private chain-of-thought. A normal result shows the conclusion, decisive evidence, mechanism, alternatives considered, verification performed, confidence boundary, and unresolved questions.

Observe the reasoning workflow

1. The run checks the floor. It names the option-free end state, follows the proposed answer through to that outcome, and accounts for every detail in the request.
2. The run selects proportional depth. Stakes, reversibility, novelty, and any hard output constraint determine how much of the protocol is surfaced.
3. The run frames the deliverable. It separates the literal request from the underlying goal, draws the scope line, and identifies load-bearing facts.
4. The run grounds claims. It distinguishes observed, derived, prior, and assumed information, then verifies the facts that could collapse the answer.
5. The run compares mechanisms. It holds at least two hypotheses for a diagnosis, chooses discriminating checks, traces concrete cases, and records what a proposed change preserves, breaks, or risks.
6. The run attacks its conclusion. It states the strongest objection, runs cheap kill-tests, audits why confidence changed, and names the weakest link.
7. The run delivers the outcome first. The verdict leads; evidence and mechanism follow; uncertainty and unresolved questions remain visible.

Keep reasoning inside the task's authority

• Prefer read-only and reversible checks that stay within the supplied scope.
• Ask before using sensitive data, external services, production systems, paid APIs, destructive probes, or consequential simulations.
• Do not present a hypothesis as an observed fact or use polished prose to hide missing evidence.
• Do not claim certainty from a small sample, a single screenshot, an LLM judge, or the protocol itself.
• Preserve private reasoning boundaries. Give the user an evidence summary they can audit rather than demanding or exposing hidden token-by-token thought.
• In medical, legal, financial, security, or safety-critical decisions, use current authoritative evidence and qualified human review where required.

Verify the result and evidence

A complete result should provide:

• An outcome-first answer, verdict, assessment, artifact, or decision matching the requested deliverable.
• The load-bearing facts and their evidence class: observed, derived, prior, or assumed.
• Competing hypotheses or alternatives considered and the observation that separated them.
• The mechanism behind the conclusion, with any gap marked explicitly.
• Kill-tests or mechanical checks run, their exact results, and skipped checks.
• The weakest link, confidence boundary, remaining risk, and what evidence would change the conclusion.

For a constrained output, the exact delivered text must pass the defined check after the last edit. Any post-check wording change invalidates that evidence and requires another full verification.

Troubleshoot or continue

Continue with Planning when a decision needs an implementation roadmap, or use Code review for a production-risk review.

Know the current limits

• The Skill is an instruction protocol with reference examples; it bundles no solver, evaluator, benchmark, executable, or test suite.
• It cannot add missing model capability, evidence, tool access, domain expertise, or authority. It reduces known process failures but does not guarantee truth.
• Tool-based checks are only as good as their inputs, environment, sample, and interpretation.
• Stable and beta contain identical ak:fable-thinking content for this release pair.