git:20260928.2014375 to git:20260929.9fe3692

10 added, 8 removed. Audit A to A.

---

name: fable-validate

description: Use when the user wants a GitHub issue validated by a Fable 5.1 subagent. Spins up a read-only subagent running on Fable 5.1 that executes the validate-issue procedure (claim tracing, architecture/consistency checks, complexity score), then relays the verdict back to the main agent, which presents it and takes any follow-on action (update issue, work on issue). Trigger on "/fable-validate", "fable validate <issue>", or "validate this with fable".

---

# fable-validate

Delegate issue validation to a **Fable 5.1** subagent, then act on its verdict in the main agent. The subagent only validates — it never edits files or the issue; the main agent handles all follow-on actions.

## Input

Same as `validate-issue`:

- Full URL: `https://github.com/<owner>/<repo>/issues/<N>`

- Short form: `#<N>` or bare `<N>` (current repo)

- `owner/repo#N`

- **Nothing** — the issue named, validated, planned, or filed in this session, per validate-issue's input rule; with none, stop and ask. Never pick an issue from a list.

## Steps

### 1. Resolve the validation procedure and the issue

Locate the `validate-issue` SKILL.md the subagent must follow — prefer the project-local copy over the global one, since a repo may customize the procedure:

1. `<repo>/.claude/skills/validate-issue/SKILL.md` (if it exists)

2. `~/.claude/skills/validate-issue/SKILL.md`

3. Any other install location — search by name, e.g. `ls ~/.claude/plugins/*/skills/validate-issue/SKILL.md` (plugin-marketplace installs live under a plugin directory, not `~/.claude/skills/`).

Record the absolute path. If none of these resolves, stop and tell the user.

- If the user referenced an issue, note the number/repo but do NOT fetch or pre-validate it yourself — the subagent owns steps 0–8 of the procedure, including fetching. If no issue was referenced, resolve it from this session per validate-issue's input rule before dispatch; with none, stop and ask. The subagent never picks an issue itself.

+ If the user referenced an issue, note the number and repository, but do NOT read or pre-validate the issue text yourself; the subagent owns steps 0 to 8 of the procedure, including the issue read. If no issue was referenced, resolve it from this session per validate-issue's input rule before dispatch; with none, stop and ask. The subagent never picks an issue itself. Then, before dispatch, on every path, in this order: when `REPO` (per `fable-dispatch` section 3) is the checkout's `origin`, run the `fable-dispatch` section 3 caller-run fetch; then run the `fable-dispatch` section 7 snapshot; then run validate-issue step 1's timeline query yourself (`gh api --paginate "repos/<owner>/<repo>/issues/<N>/timeline"` with that step's `--jq` filter). Embed its output in the prompt inside the section 7 untrusted-data block, with one line telling the subagent to take it as step 1's timeline result and never to run `gh api`; `fable-dispatch` section 3 keeps `gh api` off every allowlist. A failed timeline query is embedded as that failure, which step 1 reports under Concerns.

### 2. Dispatch the Fable 5.1 validation subagent

Do not validate the issue yourself first — the subagent owns the validation. **Load the `fable-dispatch` skill before dispatching**: it owns the dispatch path and the dispatch-hygiene rules in its section 7 (read-only prompt, snapshot/diff, retry once then report). Dispatch per its ladder; on the Agent-tool path, call the Agent tool with:

- - `subagent_type`: `Plan` (read-only: no Edit/Write, keeps validation side-effect-free)

- - `model`: `fable` (the whole point — the validation must come from Fable 5.1)

- - `run_in_background`: `false` — everything downstream depends on the verdict

+ - `subagent_type`: `Plan` (no Edit or Write; the section 7 prompt rule covers Bash and MCP tools)

+ - `model`: `fable` (the validation must come from Fable 5.1)

+ - `effort`: `high` unless the user asked for another tier, with the other Agent parameters per `fable-dispatch` section 2; everything downstream waits for the verdict

- `description`: `Validate issue #<N>`

- `prompt`: hand it everything needed to validate independently:

- The issue reference exactly as the user gave it, or the one resolved from this session, plus the working directory.

- Instruct it to **read the SKILL.md at the recorded path and execute its steps 0 through 8 exactly** — baseline resolution, the one-call issue read with its `updatedAt` + PR timeline check, claim extraction, depth-rule verification with `file:line` citations, 5a/5b/5c proposal checks, complexity score, scope disposition, and the step-8 verdict format. It must read every mandatory reference file those steps name.

- - It must STOP at step 8: no step 9 to 12 actions, no `gh issue create`, no `gh issue edit`, no comments posted, no file edits — state the read-only rule explicitly in the prompt per `fable-dispatch` section 7.

+ - It must STOP at step 8: no step 9 to 12 actions, no `gh issue create`, no `gh issue edit`, no comments posted, no file edits. State the full read-only rule of `fable-dispatch` section 7 in the prompt.

- Return the complete step-8 verdict verbatim as its final message, plus one line stating which baseline (branch/commit) claims were traced against, and one line `Issue updatedAt: <value>` with the `updatedAt` that validate-issue step 1 recorded.

+ On every path, when `REPO` is the checkout's `origin`, step 1 has already run the `fable-dispatch` section 3 caller-run fetch before the snapshot. Tell the subagent it is done: it executes steps 0 through 8 exactly except that fetch, which it skips, and it never runs `git fetch`. On the shim, the `--allowedTools` list is the `fable-validate` example in `fable-dispatch` section 3, and `--add-dir` names the directories that section gives for the recorded SKILL.md path; the prompt lists each allowed `gh` command verbatim, as that section states. When `REPO` is another repository, add the cross-repository clone entries and directory from that section.

The subagent's final message comes back as the tool result; it is not shown to the user.

- When the result arrives, record its `Issue updatedAt` as this session's validation read time, which `work-on-issue` step 0 and validate-issue step 11 use. Also **record the model and effort that actually ran**, per `fable-dispatch` section 6: the model is `Fable 5.1` on the Agent path unless the ladder substituted another, and on the shim path the model `.modelUsage` reports; the effort is the `--effort` tier the shim passed. The Agent-path dispatch passes no `effort`, so record `high`, the Fable default, and note that no effort was passed; never guess another tier. Step 5's footer and every chain footer use these recorded values. Save the verdict verbatim to a scratchpad file immediately, so it survives context summarization and later steps can quote it exactly.

+ When the result arrives, run the section 7 snapshot diff, then record the result's `Issue updatedAt` as this session's validation read time, which `work-on-issue` step 0 and validate-issue step 11 use. Also **record the model that served, the tier, and whether the tier was honored**, per `fable-dispatch` section 6: the model is `Fable 5.1` on the Agent path unless the ladder substituted another, and on the shim path the model section 5 finds dominant in `.modelUsage`; the tier is the one passed per section 2 (`--effort` on the shim). Never guess another tier. Step 5's footer and every chain footer use these recorded values. Save the verdict verbatim to a scratchpad file immediately, so it survives context summarization and later steps can quote it exactly.

### 3. Spot-check the verdict

Before presenting it, spot-check the verdict's load-bearing findings against the code: the `file:line` citations for any Refuted or Conditional claims resolve to real code saying what the verdict says, and the verdict doesn't contradict repo conventions (CLAUDE.md). Evidence outranks verdicts — a subagent citation that contradicts its own mark means the mark is wrong. Fix small inaccuracies yourself and note them (update the scratchpad copy); if the verdict is structurally wrong (e.g. traced a stale baseline, missed the central claim), do NOT silently re-dispatch — tell the user what's off and let them decide whether to re-run with Fable 5.1 or proceed.

### 4. Relay the verdict to the user

- Present the vetted verdict in the validate-issue step-8 format, noting it was produced by Fable 5.1 and which baseline it traced. Nothing is posted to GitHub at this stage — validation alone never writes to the issue.

+ Present the vetted verdict in the validate-issue step-8 format, noting the model that served, as step 2 recorded it (with the downgrade stated when another model served), and which baseline it traced. Nothing is posted to GitHub at this stage — validation alone never writes to the issue.

### 5. Follow-on actions (main agent)

Handle the user's reply per the validate-issue procedure — these are main-agent actions, never re-delegated:

- **"update issue"** → apply the suggested title/body edits per validate-issue step 11, including its claim-verification gate and final consistency pass. Footer: `Validated with LLM: <served model> | <accepted tier> | Harness: <harness> | fable-validate`, with the model and effort that step 2 recorded and the harness actually running per `fable-dispatch` section 6 (stack under any existing footer lines per step 11; a repo CLAUDE.md footer format overrides).

- **"work on issue"** → hand off to the `work-on-issue` skill per validate-issue step 9, surfacing any step-7 scope disposition first.

- **"split issue" / "decompose"** → apply validate-issue step 12 with the step 7 disposition from the relayed verdict.

## Notes

- - The validation subagent runs on Fable 5.1 regardless of the main agent's model — `model: fable` on the Agent call forces it.

+ - The dispatch requests Fable 5.1 with `model: fable`, whatever the main agent's model. A harness can map `fable` to another model with no error, so `fable-dispatch` sections 1 and 5 detect a substitution, and the footer names the model that served.

- One subagent, one verdict: don't fan out or re-run for a second opinion unless the user asks.

- If the user's reference turns out not to be fetchable (wrong number, no auth), the subagent will report that per the procedure — relay it; never validate against a paraphrase.