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.