Fable Validate

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 — default to the latest open issue in the current repo.

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, the subagent resolves the latest open issue itself per the procedure.

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
• description: Validate issue #<N> (or Validate latest issue)
• prompt: hand it everything needed to validate independently:
  • The issue reference exactly as the user gave it (or "no issue referenced — resolve the latest open issue per the procedure"), 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, fetch with --comments + 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/10/11 actions, no gh issue edit, no comments posted, no file edits — state the read-only rule explicitly in the prompt per fable-dispatch section 7.
  • Return the complete step-8 verdict verbatim as its final message, plus one line stating which baseline (branch/commit) claims were traced against.

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

When the result arrives, 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 ❌/⚠️ 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.

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: since the findings came from the Fable 5.1 subagent, use Validated with LLM: Fable 5.1 | high | Harness: <harness> | fable-validate, where <harness> names the harness actually running per fable-dispatch section 6, and the model names the one that actually served the dispatch (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" → file the proposed parts per validate-issue step 7, each fully specified.

Notes

• The validation subagent runs on Fable 5.1 regardless of the main agent's model — model: fable on the Agent call forces it.
• 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.