fable5-methodology

Force the combination step that a weaker model can't do in one pass — surface conflicts between constraints, and interactions between requirements and edge cases, using a pairwise sweep, a fresh-context cold read by a subagent that never saw your reasoning, and N-version divergence on the hard kernel. Trigger this after producing a plan, design, spec, or multi-constraint solution and BEFORE committing to it — especially when the task carries more than ~3 interacting constraints, a schema/interface decision, or high stakes. Do NOT trigger for a single-constraint or trivial task (17.3 tiers say skip it), for reviewing an already-written code diff (that's code-review), or for verifying tests ran (that's verification-and-review). This skill checks that the DESIGN is internally consistent before code exists.

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).

The ambient execution discipline — predict the outcome of every consequential command BEFORE running it and treat any surprise (better or worse) as a model error to investigate; choose the next action by information gain; estimate blast radius before touching anything shared. Trigger this continuously during hands-on work: before running a command/test/query whose outcome matters, when choosing among several possible next actions, and before editing anything with dependents. Do NOT confuse with verification-loop (which says WHEN to run checks — after each edit) or debugging-methodology (which owns hypothesis-testing once a failure is confirmed): this skill governs the epistemic stance around every execution — it is usually what DETECTS the failure those skills then handle.

Shape a problem before solving it — check the premise (XY problems, false dichotomies), find the canonical name for the problem shape, locate the hard kernel, and factor fuzzy asks into orthogonal decisions. Trigger this BEFORE solving whenever a request specifies a mechanism rather than an outcome ("add a retry here"), offers a this-or-that choice ("should we use A or B?"), poses a fuzzy design/diagnostic question, or feels like something that must have been solved a thousand times before. Do NOT trigger for turning an already-well-framed build request into an ordered plan (that is task-planning, which runs AFTER this) or for choosing between candidates you've already scoped (architecture-decisions). This skill decides whether you're solving the right problem in the right frame; its successors decide how.

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.

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.

Step-by-step procedure for diagnosing and fixing failures — reproduce, read, hypothesize, bisect, fix, regression-test. Trigger this whenever something does not work as expected — a bug report, a failing or flaky test, a crash, an error message, wrong output, "it worked yesterday", or unexpected behavior during your own implementation. Trigger BEFORE proposing any fix. Do NOT trigger for building new features (use task-planning) or for the moment you realize your overall approach is wrong rather than the code (use course-correction).

Add, upgrade, or migrate third-party dependencies safely — read the changelog for the exact version jump, isolate the change, run full verification, and keep rollback ready. Trigger this when the task involves bumping a package version, adding a new dependency, replacing one library with another, resolving a dependency vulnerability, or a lockfile update. Do NOT trigger for using an already-installed dependency in application code (that's normal implementation), or for deciding WHETHER a new dependency is warranted (use architecture-decisions' dependency sub-decision) — this skill is about executing the change without breakage.

Externalize reasoning to a scratchpad file for problems too large to hold in working memory — a persistent record of candidate approaches, eliminated branches and WHY they were eliminated, open questions, and current best hypothesis, updated as understanding evolves. Trigger this when a problem has more moving parts or branches than you can track in-context: multi-day investigations, complex design with many interacting subsystems, a debugging hunt across many hypotheses, or any reasoning you'll need to resume after a context break. Do NOT trigger for problems solvable in one sitting in-context (use structured-reasoning). The distinction: structured-reasoning thinks in the conversation; this skill thinks on disk because the conversation can't hold it.

Rules for commits, branches, diffs, and history when working in a git repository — checkpoint strategy, pre-commit diff review, message format, and the hard prohibitions on destructive operations. Trigger this whenever work happens in a git repo and involves staging, committing, branching, or any history-affecting command; before EVERY commit; and the moment you are tempted to run force-push, reset --hard, clean -fd, rebase, or amend. Do NOT trigger for the edit-test cycle itself (use verification-loop) or for reviewing code quality of a diff (use code-review) — this skill governs version-control mechanics and safety only.

Concrete coding conventions to apply WHILE writing or editing code — naming, function/file size, error handling, input validation, types, comments, tests, and secrets. Trigger this whenever you are about to write new code or modify existing code in any language, including tests and scripts. Do NOT trigger for choosing between designs (use architecture-decisions), for diagnosing failures (use debugging-methodology), or for the final pre-delivery check (use verification-and-review) — this skill governs the act of writing itself.

Build large multi-part deliverables — multi-file projects, migrations, long documents, N-of-the-same-thing work — in verified increments with dependency ordering, checkpoints, a running state note, and consistency sweeps. Trigger this when a task will produce 3+ files, spans more sub-deliverables than fit in one pass, involves repeating a pattern across many sites (endpoints, parsers, pages, records), or is explicitly requested to be done incrementally or resumably. Do NOT trigger for single-file changes (implementation-standards suffices) or for the initial breakdown of an ambiguous request (use task-planning first — this skill governs execution after the plan exists).

Compact honesty and safety guardrails that apply to ANY task involving file modification, command execution, or reporting results — the absolutes on claiming success, fabricating output, silencing tests, dropping requirements, destructive commands, scope, and secrets. Trigger this on effectively every working task: before running commands that change state, before every commit, and before every message that reports results or completion. This skill is the always-on floor; the full rationale for each rule lives in INTEGRITY.md. Do not trigger for pure question-answering with no execution and no result claims.

Debug code you didn't write and can't fully trust — unfamiliar, poorly documented, or untested subsystems — using history archaeology, boundary instrumentation, minimal harnesses, and history bisection, while resisting the urge to rewrite. Trigger this when a failure lives in code that is foreign to you AND lacks reliable documentation or tests: inherited services, vendored code, an unowned module, "nobody knows how this works". For failures in code you understand and can navigate normally, use debugging-methodology instead — this skill adds the archaeology layer for when reading the code alone doesn't tell you what it's supposed to do.

Make code measurably faster or leaner without breaking it — define a target, measure a baseline, profile to find the ACTUAL bottleneck, apply optimizations in a fixed order of leverage, and re-verify correctness after each change. Trigger this when the user reports slowness, high latency, memory growth, or cost, sets a performance budget, or asks to "optimize" or "speed up" something. Do NOT trigger for functional bugs that happen to involve timing (use debugging-methodology) or for restructuring at equal performance (use safe-refactoring) — this skill exists to move a number.

Verify version-sensitive and time-changing facts against real sources before relying on them, instead of answering from training memory that has a cutoff date. Trigger this before using any library/framework API, method signature, config option, or CLI flag you have not confirmed this session; before quoting a version, price, quota, rate limit, or model ID; when asked "what's the latest / newest way to do X"; when the project pins a specific version; and whenever a fact could have changed since your training cutoff. Do NOT trigger for stable knowledge (language syntax, algorithms, math, frozen standards) or for uncertainty about internal codebase APIs (use codebase-exploration/uncertainty-management — though the environment-first source here overlaps and is compatible).

Execute behavior-preserving code restructuring — establish a test safety net first, apply the smallest mechanical transformations in sequence, verify after each, and refuse refactors that lack the coverage to be done safely. Trigger this when the user asks to "refactor", "clean up", "simplify", "restructure", "extract", or "rename" existing working code, or when you initiate a structural improvement yourself. Do NOT trigger for changes meant to alter behavior (that's a feature/fix — use task-planning), or for diagnosing why code is broken (use debugging-methodology) — a refactor by definition starts from green.

Run a structured vulnerability pass over code — injection, auth/authz gaps, secrets exposure, unsafe deserialization, unvalidated boundary input, SSRF, and stack-specific classes — reporting findings by severity with concrete fixes. Trigger this after writing or modifying code that handles user input, authentication/authorization, database queries, file paths, external requests, deserialization, or secrets; before committing security-sensitive changes; and whenever the user asks for a security review or mentions handling untrusted data. Do NOT trigger for pure-internal logic with no trust boundary, or as a substitute for general code-review — this pass hunts vulnerabilities specifically.

Stay coherent across a long agentic session by keeping the task's state on disk — a WORKING_NOTES.md with the task, plan, decisions, and status — updated at every milestone and re-read after any context loss. Trigger this at the start of any task likely to exceed ~30 minutes or ~10 distinct steps; immediately after noticing context compaction or a session resume; and whenever you catch yourself re-searching for something you already found or contradicting an earlier decision. Do NOT trigger for short single-sitting tasks, and do not confuse with incremental-delivery (which orders and checkpoints the DELIVERABLE) — this skill keeps the SESSION coherent regardless of what is being built.

A step-by-step reasoning protocol for problems that exceed one intuitive step — generate and compare candidates, track assumptions, reason backward or from a minimal case when stuck, sanity-check intermediates, and run a mandatory devil's-advocate pass before finalizing. Trigger this the moment a problem is novel, high-stakes, involves multiple interacting constraints, requires arithmetic/counting/state-tracking, or you're unsure what the next step is. Do NOT trigger for problems too large to hold in working memory (use extended-problem-solving, which externalizes to disk) or for routine one-step answers. This skill is for thinking a hard thing through in-context; its sibling is for thinking a huge thing through on paper.

Parse a request and produce an ordered execution plan before any code is written. Trigger this at the START of any new task — when the user asks to build, implement, add, create, migrate, or refactor something; when a request spans multiple files or steps; when a request contains vague scope words ("the configs", "handle errors etc."), ordering instructions, or prohibitions; or whenever you notice you don't know what you'd do second. Do NOT trigger for mid-task failures (use debugging-methodology), for choosing between two designs you've already scoped (use architecture-decisions), or for single-line edits you can hold entirely in your head.

Classify what you actually know vs. what you're reconstructing from memory, verify before acting on unverified specifics, and communicate uncertainty without hedging everything. Trigger this whenever you are about to write a call to a library API, CLI flag, config key, or endpoint you have not confirmed in this session; when answering questions about version-specific or fast-moving library behavior; when quoting numbers, versions, or citations; or when you notice the thought "it's usually something like this". Do NOT trigger for ambiguity about what the USER wants (use task-planning's ask-vs-proceed rule) — this skill covers factual/technical uncertainty only.

The mandatory pre-delivery pass — requirements sweep, execution proof, self-review of the diff as a stranger's, and a fixed edge-case probe. Trigger this every time you are about to say "done", "fixed", "implemented", or "passing"; before committing, opening a PR, or handing work back to the user; and after the LAST edit of any change (a passing run before the final tweak proves nothing). Do NOT trigger while still diagnosing a failure (use debugging-methodology) or while still writing (use implementation-standards) — this skill is the exit gate.

The tight edit-verify cycle DURING implementation — after every meaningful change, run the fastest sufficient check before making the next change; never accumulate a batch of unverified edits. Trigger this continuously while writing or modifying code: after each function implemented, each bug-fix edit, each config change, each refactoring step. Do NOT confuse with verification-and-review, which is the one-time exit gate before claiming "done" — this skill is the per-edit rhythm that makes that final gate boring. Do not trigger for pure prose/documentation edits with nothing executable to check.