fable5-methodology

Implements a single scoped change that already has explicit acceptance criteria. Delegate to builder when a task is specified enough to hand off — a defined change with a list of what "done" looks like and the files/area in scope. Do NOT use for open-ended exploration, design decisions, or anything lacking acceptance criteria (builder will refuse). Returns a diff summary plus verification evidence.

Adversarially reviews a diff cold — without the reasoning that produced it — for correctness, safety, design, and scope, hunting specifically for fake progress, silently dropped requirements, weakened tests, and scope creep. Delegate to code-reviewer for any non-trivial diff before it is accepted or committed, including your own work. Requires the diff and the original requirements. Returns findings by severity with file:line. Distinct from qa-verifier (which runs tests): this reviews the code itself.

Independently verifies a completed change against its acceptance criteria by running the tests/build/lint itself and probing edge cases — never trusting the implementer's claims. Delegate to qa-verifier after any builder (or your own) implementation, before accepting it as done. Requires the change and its acceptance criteria. Returns strict PASS/FAIL per criterion with real command output as evidence. Do NOT use it to write or fix code — it only verifies.

Answers questions about an API, library version, CLI flag, config option, or current best practice by checking the installed environment first and then version-matched official docs — never from training memory alone. Delegate to research-scout before relying on any version-sensitive external fact, or when the user asks "what's the latest / correct way to do X". Requires the specific question and, ideally, the project it applies to. Returns the answer with source, version, and date, labelling anything unverified.

Choose between competing technical approaches and make design decisions with an explicit trade-off order. Trigger this when a task requires selecting among 2+ viable designs — "should we use X or Y", designing a schema, shaping a public API, choosing a storage/queue/cache mechanism, deciding whether to add a dependency, or deciding whether to introduce an abstraction. Do NOT trigger for initial request parsing (use task-planning), for line-level style questions (use implementation-standards), or when the codebase already has an established pattern for this exact problem — in that case, follow the existing pattern without deliberation.

Review a diff or pull request — including your own before delivery — in a fixed pass order (correctness, then safety/security, then design, then style) and report findings ranked by severity. Trigger this when asked to review a PR or diff, when checking over a change before committing or handing it off, and as the design-and-correctness half of your own pre-delivery review. Do NOT trigger for the mechanical did-it-run gate (use verification-and-review) or for a dedicated vulnerability sweep (use security-review, which this skill's safety pass defers to) — this skill is holistic human-style review of a change set.

Map an unfamiliar repository before changing anything in it — structure sweep, entry points, configs, test baseline, targeted tracing, and mental-model confirmation. Trigger this the FIRST time you work in a repo (or an unfamiliar subsystem of a known repo) in a session, before your first edit there — whenever the user says "fix/add/change X" in code you have not yet mapped. Do NOT trigger for repos or areas you already mapped this session, for single-file scripts with no surrounding project, or for parsing the request itself (use task-planning) — this skill is about understanding the code, not the ask.

Protect the context window as a scarce resource — read at the right altitude, delegate bulk reconnaissance to subagents so only conclusions enter the main thread, externalize durable facts to disk, and respond to your own degradation signals. Trigger this when about to read a large file or many files, when a search/log-dig would flood the conversation with content you won't reference again, when deciding whether to delegate to a subagent, and whenever you notice re-running searches or re-deriving established facts. Do NOT confuse with session-state-management (which owns the WORKING_NOTES.md file and resume protocol — this skill decides what enters context at all) or incremental-delivery (which chunks the deliverable — this skill budgets the reading around it).

Recognize mid-task that the current APPROACH is wrong and execute a disciplined stop-revert-replan instead of accumulating patches. Trigger this when any alarm fires during ongoing work: your last two changes each fixed the previous change's symptom; the design keeps growing special cases; you're fighting or monkey-patching the framework; a "small fix" now spreads across many files; you can't explain why a line exists beyond "it made the error go away"; three attempts have failed on the same error; or you catch yourself thinking "I've come too far to restart". Do NOT trigger for a single reproducible bug with a working approach (use debugging-methodology) — this skill is for when the plan itself is the bug.

7 hooks across 5 events