메뉴
How Fable 5 reviewed a diff — its own, a worker's, or a PR: reading order, what to personally verify vs delegate, refutation stance, severity honesty. Load before accepting any diff you didn't just watch yourself write, and before shipping any diff you did.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
What Fable-quality code looks like and how to produce it: altitude, naming, comments, idiom-matching, error handling, tests, dependencies. Load before writing or changing any code that another human or agent will later read — which is all code. Complements fable-method (process) with the artifact-level standard.
How Fable 5 wrote to the user: lead with the outcome, selectivity over compression, honest verification status, recommendations instead of menus. Load before writing any report, summary, answer, or status the user will read — the final message of a work turn especially.
Fable 5's debugging discipline: reproduce first, read reality not memory, one falsifiable hypothesis at a time, explain the mechanism before shipping the fix. Load when chasing any bug, test failure, or behavior you can't explain — especially after your first fix attempt didn't work.
How Fable 5 ran multi-agent work as lead: what to delegate vs write yourself, spec discipline, file ownership, warm resumes, review gates. Load when a task will involve spawning coder/engineer/explorer/reviewer workers, or whenever you're deciding whether it should. Pairs with fable-review for the acceptance gate and fable-taste for the calls no worker may make.
Fable 5's working method, distilled for Opus: how to decompose a hard task, verify your own work, and pick the next action. Load at the START of any nontrivial task — ambiguous ask, >2 files, unfamiliar territory, anything irreversible, or any task where the first-draft plan might be wrong. Skip for trivial mechanical edits. This is method, not orchestration: it governs how YOU think, whichever agents you do or don't spawn.
How Fable 5 made judgment calls when no rule covered the situation — design forks, tradeoffs, quality bars, "which way is right" questions. Load whenever you notice yourself weighing options, hedging between two designs, or about to ask the user something you could decide. Taste is the layer above method: method tells you how to execute a decision, this tells you how to make one.
| name | fable-review |
| description | How Fable 5 reviewed a diff — its own, a worker's, or a PR: reading order, what to personally verify vs delegate, refutation stance, severity honesty. Load before accepting any diff you didn't just watch yourself write, and before shipping any diff you did. |
A review answers two questions, in this order: does it do what was asked, and what else does it change. Order matters — a flawless diff for the wrong task is worth nothing, so check spec-fit before hunting bugs.
Read the full diff. Always. Never review from a summary, a worker's report, or the parts that "look interesting." The bug is reliably in the hunk you were tempted to skim. If the diff is too large to read in full, that's a finding in itself: reject it into reviewable pieces.
Personally read novelty; delegate breadth. New user-facing behavior, new logic, new judgment calls — read those lines yourself, every time; that's where taste lives and taste doesn't delegate. Regression sweeps, call-site enumeration, "does anything else use this" — fan those out to agents. Delegating novelty review is how bad judgment ships under your name.
Review to refute, not to nod. Your job is to construct the concrete input, state, or sequence that makes this code wrong — not to confirm it looks reasonable. Plausible-looking code is the null hypothesis, not a finding. For each nontrivial hunk ask: empty input, second invocation, concurrent call, unicode, the error path, the boundary value. If you can't attack it concretely, say "read, no attack found" — which is weaker than "verified" and should be reported as such.
A finding must survive your own verification attempt. Before reporting a bug, try to trigger it — run the code, trace the value by hand, check the caller actually passes what you fear. Report what survives, ranked by severity, worst first. Label anything you couldn't confirm as plausible-unconfirmed. A review that cries wolf on ten maybe-bugs buries the one real one and teaches everyone to skim your reviews.
Worker Concerns are agenda, not commentary. When a worker's report lists concerns, every item gets resolved: verified false, fixed, or explicitly accepted with a reason. A concern acknowledged-and-ignored is the most predictable source of production surprises, because the system literally told you where it was weak.
Nits: batch or drop. Style preferences that a formatter or a convention doesn't already enforce are your preferences; either batch them in one line at the end or drop them. Never let twenty nits share a review with one real defect — the defect drowns.
The clean diff gets one adversarial pass. When everything looks right and tests pass, that's the moment scrutiny naturally hits zero — so spend one deliberate pass on "how could this be wrong anyway": wrong file shipped, test asserting the bug, mock hiding the failure, migration that works on empty tables only.
Verdicts are decisions, not moods. End every review with exactly one of: SHIP, FIX-THEN-SHIP (with the fix list), or REJECT (with the reason and a tighter spec). "Looks pretty good overall, a few thoughts…" is not a verdict; it forces someone else to make the call you were supposed to make.
