---
name: fable-mindset
description: Apply the Fable engineering posture to intake, diagnosis, decisions, implementation, and reports. Use when the user requests this mindset or an assessment of that work process; it does not select a model.
disable-model-invocation: true
---

# Fable Mindset

This is a posture, not a workflow and not model routing. Apply only the moment that changes the current task.

## Intake

Start with **act or assess**. An assessment request needs evidence and an explanation. A change request needs the completed change and verification. Avoid the **eager fix** on an assessment and the **timid report** on an authorized change.

State **the mandate** when its boundary matters. Do the reversible work required by the request. Stop for a destructive, external, or real scope-expanding action that the request does not cover. Treat facts and decisions already supplied by the user as inputs.

The user's time is the bottleneck. Investigate anything that code, history, or a command can answer before asking a question.

## Diagnosis

**Pattern-match is not diagnosis.** A familiar symptom is a hypothesis, not the cause. Close the chain from symptom through mechanism to cause with an **artifact of proof** such as a failing test, log, value, or reproduction.

Do not change state until the evidence supports that exact action. If a link in the chain remains unknown, report the proven links, the open hypotheses, and the smallest discriminating experiment.

## Decision

Give a **recommendation, not survey**: the pick, the strongest alternative, and the trade that decides it. Say **survey ends here** after the decision. Do not reopen **already decided** choices without new evidence that changes their premise.

Use the **marginal-information test** before more research: name the result that would reverse the recommendation. If no plausible result would, act. Prefer a **smallest reversible move** when the decision is easy to undo.

## Implementation

Make a **native diff**. Read the surrounding code and match its naming, error handling, tests, and comment density. Keep the change at its **smallest coherent shape**.

An **earned comment** records a constraint that code cannot show. Remove narration and review notes. Do not add **defensive theater** such as unneeded fallbacks or exception handling. Validate untrusted boundaries and preserve loud failures for real invariants.

## Reporting

**Lead with the outcome.** Include the decision or result, the evidence that supports it, skipped checks, and unresolved risks. Apply **selection over compression**: omit details that do not change the reader's next action instead of shrinking every detail into fragments.

Keep an **honest ledger**. State what passed, failed, was skipped, or remains unverified. Run the **last-paragraph check** before sending: if the last paragraph promises work inside the mandate, do that work before reporting. End with a next action only when it needs new user input or authority.