---
name: fable5-reasoning
description: Use for non-trivial software engineering tasks requiring investigation, competing hypotheses, or rigorous verification, including ambiguous bugs, multi-file changes, code review, and architectural analysis. Apply Fable 5.1-inspired work discipline through evidence, scope control, falsification, and completion. Avoid trivial edits and straightforward questions.
---

# Fable 5.1-inspired reasoning

Use this workflow to reduce premature conclusions and incomplete engineering work. It does not reproduce model weights, hidden reasoning, or guaranteed Fable 5.1 performance. It does not change the selected model or reasoning-effort setting.

## Boundaries

- Follow applicable system, developer, user, and repository instructions. This skill grants no additional permissions.
- Preserve the requested scope. A review or explanation is not permission to edit; an implementation request includes appropriate verification.
- Continue authorized, reversible work without unnecessary approval requests. Ask when a material ambiguity or an unauthorized consequential action prevents safe progress.
- Keep private reasoning private. Report concise conclusions, evidence, assumptions, and unresolved issues.

## 1. Calibrate and define done

- S: a local, reversible task with little ambiguity. Inspect, act, and perform a focused check; skip the remaining ceremony.
- M: meaningful uncertainty, several files, or interacting behavior. Follow the workflow and attempt one relevant counter-check.
- L: broad impact or difficult investigation. Also maintain a short working plan and verify at milestones.

Identify the deliverable, observable acceptance criteria, constraints, and non-goals. Preserve existing user changes. Resolve routine details from project conventions; ask only when the answer materially changes the work.

## 2. Gather evidence before choosing a fix

Read applicable instructions, affected code, callers, existing tests, and relevant runtime evidence. Distinguish observed facts, inferences, and untested assumptions.

Search narrowly first and expand when findings justify it. Batch independent reads or searches when supported; keep dependent steps sequential. Verify unfamiliar or fast-changing technical claims against current primary sources.

## 3. Test competing explanations

For ambiguous problems, identify plausible alternatives and the assumption whose failure would most undermine the result. Choose the smallest reliable observation that distinguishes the alternatives.

Use: hypothesis -> minimal experiment -> observation -> updated conclusion.

Do not turn a familiar pattern into a diagnosis without evidence from this case. If a check fails, revise the hypothesis or approach rather than repeating the same action without new evidence.

## 4. Make the smallest complete change

When implementation is requested, carry it through to verification. Prefer targeted edits and existing project patterns. Do not add unrelated fixes, abstractions, configuration, or refactors.

Keep assessment-only tasks read-only. Complete independent work if another part is blocked. Stop at genuine permission or information boundaries, not merely because a next step has been identified.

## 5. Verify and try to disprove the result

Run repository-required checks and the narrowest relevant behavior check. For a bug fix, repeat the original reproduction. Broaden testing when impact, failures, or unresolved evidence justify it.

For M/L tasks, attempt a concrete counterexample: a boundary case, error path, or competing cause relevant to the change. Check whether the test could pass while the requested behavior remains wrong. If a counter-check cannot run, state the remaining uncertainty.

Do not add permanent tests merely to mirror implementation. Distinguish change-caused, pre-existing, and environmental failures using evidence; do not assume a failure is unrelated.

## 6. Review the diff and finish

Read the final diff for unintended behavior, scope expansion, and repository-rule violations. Match every acceptance criterion to evidence and confirm only intended files changed.

Report the result, relevant checks and outcomes, and any concrete blocker or unverified behavior. Do not claim completion while authorized, necessary work remains executable.

For long tasks, preserve constraints, decisions, evidence, completed work, rejected approaches, and unresolved steps across context changes. Avoid repeating completed investigation without a reason.

## Review tasks

Trace reachable behavior and construct a concrete failure scenario before reporting a defect. Separate confirmed defects, risks needing validation, and optional improvements. Do not invent findings to fill a review.