# Fable Review

> Get an independent review from Claude Fable 5.1 through the Claude CLI, then verify its claims before acting. Use for a hard judgement call: a design or architecture decision, a taste question, a plan worth arguing with. Not for a cheap conformance check (`glm-review`), a codebase grade (`simplify`), or a routine diff.

- Skill: `howells/fable-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add howells/fable-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/howells/fable-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: howells (https://skillmd.com/u/howells)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/howells/fable-review

---


# Fable review

Fable is the expensive lane, for the calls that are genuinely hard: which of two architectures survives contact, whether a plan's premise holds, whether an interface reads the way its author thinks it does. Use it sparingly and on questions where a second opinion changes what you do next.

What comes back is a set of leads. Verify each one before acting on it.

`glm-review` is the other lane, and the two are chosen by the kind of question rather than by importance. A bounded conformance check - does this match the stated criteria, does this contract hold, is this copy right - goes to GLM and costs almost nothing. A judgement call with no checkable answer goes here.

## One route, three hosts

The Claude CLI is the route, and it works the same from Claude Code, Codex and OpenCode, because all three can run a shell command.

```bash
printf '%s' "$PROMPT" | claude -p \
  --model fable \
  --effort medium \
  --permission-mode plan \
  --tools "Read,Glob,Grep" \
  --strict-mcp-config --mcp-config '{"mcpServers":{}}' \
  --disallowedTools "Edit,Write,NotebookEdit"
```

**Pass the prompt on stdin.** `--disallowedTools` is variadic and will otherwise swallow a positional prompt as tool names, which fails with `Permission deny rule "…" matches no known tool` and never reaches the model.

Run it from the repository under review; the CLI reads files relative to the working directory. Add `--add-dir` for a path outside it.

Confirm the lane before the first invocation in a session:

```bash
printf 'Reply with exactly: lane-ok' | claude -p --model fable --effort medium --permission-mode plan --output-format json
```

The CLI may return a result object or an array of messages; in the latter case inspect the final message with `type: "result"`. Require a successful result (`is_error: false`) whose `result` text is `lane-ok`. Inspect returned model metadata when available: the `fable` alias currently reports `claude-fable-5-1`, not the literal string `fable`. Stop if it identifies a different model or version; the text alone proves responsiveness, not exact model identity. If the CLI omits model metadata, report identity as unverified rather than asserting the exact version.

Without `lane-ok`, stop and name the cause: `claude` missing from the path, credentials absent or expired, or the alias no longer resolving to Fable. Substituting Opus, Sonnet or a different provider's model is a failed run, because the point of the lane is which model answered.

**Do not substitute the Claude Code subagent.** In Claude Code a fable subagent is reachable through the Agent tool, and it inherits this session's context and instructions. That makes it useful for delegated work and useless as an independent read, since it has already been told what you think. The subprocess starts clean, which is the whole value.

Plan mode and denied edit tools reduce write access, but a successful refusal probe is not proof that every write route is blocked. Keep the written read-only boundary in the brief. When source reading is sufficient, restrict built-in tools with `--tools "Read,Glob,Grep"` (`--allowedTools` only preapproves tools; it does not remove other tools) and use `--strict-mcp-config --mcp-config '{"mcpServers":{}}'` to avoid initializing unrelated integrations; otherwise remember that shell access can still mutate state and use the host's execution controls.

`--effort medium` is the default for this skill. Use a different effort only when the user explicitly requests it.

## Build a bounded brief

Investigate first, so Fable spends its turn on the judgement rather than on rediscovering the repository. A brief carries:

- the question, stated as a decision someone has to make;
- the artifact: paths, excerpts, diff or base commit, current status;
- the options already on the table, and what each would cost;
- constraints, settled decisions, and explicit non-goals;
- validation already run, and what remains uncertain;
- the boundary, verbatim: `Read-only review. Do not edit files or run state-changing commands.`

Ask for a verdict, the reasoning that leads to it, where it disagrees with the proposed direction, and what it would need to change its mind.

A brief that names no decision gets an essay. "Review this architecture" fails that bar; "we chose X over Y for reason Z - what does that cost us in eighteen months" does not.

## Wait for it

Even a single-file judgement call can take several minutes at medium effort. A brief spanning several files and a real decision may take longer.

Enforce a ten-minute wall-clock limit on the subprocess, including its children. Use the host’s process timeout if it supports that duration and process-tree cleanup; otherwise launch through a runner such as Python `subprocess.Popen(start_new_session=True)`, capture stdout/stderr, call `communicate(timeout=600)`, and terminate the process group on `TimeoutExpired`. A short tool yield is fine if it returns a live session; it must not kill the review at that point. Do not assume GNU `timeout` is installed on macOS. A review still silent past that is a hang: kill it, say so, and stop. Output that arrives empty or cut off mid-argument is a failed run, reported as one rather than salvaged into a partial verdict.

Retry once on a transport or internal-server failure. Report an authentication, quota, or billing rejection and stop without retrying, because those repeat.

## Verify, then report

Check every material claim against the source, the diff, the tests, or the running product. A claim you could not confirm stays labelled unconfirmed. Fable argues well, and a well-argued wrong claim is the failure mode this step exists to catch.

Return:

- the question Fable was given;
- its verdict, and whether you agree;
- findings you verified, most serious first;
- claims that failed verification, and what you found instead;
- recommended changes, kept separate from changes already made;
- any lane failure.

Pasting the reply verbatim is not a report. Implement nothing unless implementation was already part of the request.

## Where this fits

- A bounded conformance or contract check, cheaply: `glm-review`.
- A whole-codebase grade with a comparable score: `simplify`.
- Correctness review of a diff: the host's own code review.
- Rebuilding what happened rather than judging it: `muster`.