rules-with-receipts

Project the trajectory before committing - pre-register dated, credenced predictions about what breaks, what becomes necessary, and what pays off 5/10/20 steps ahead, then resolve them when the future arrives and score your calibration. Activate when starting any build, plan, or strategy; making architecture, roadmap, scaling, or investment bets; choosing between directions; or shipping something whose problems will surface later. Trigger signals: "will this scale", "what will we regret", "where does this break at 10x", "what will we need by then", a plan whose risk section only covers the present, or a direction justified only by today's constraints.

When a published claim is corrected, retracted, downgraded, superseded, or reversed, sweep EVERY surface that restates it - sibling docs, other repos, mirrors, READMEs, indexes, memory files - and banner or supersede each in the SAME closeout before it's done. Activate on "I corrected/retracted/updated X", a metric downgraded, a status flipped, a conclusion reversed, a benchmark restated elsewhere, "did the correction propagate", closeout after a correction, or a claim in more than one repo/doc. Method: grep the claim's distinctive tokens (number, phrase) across ALL surfaces, top-of-file first.

Break hard tasks into smaller solvable units with explicit dependencies and unknowns. Activate when a task feels too big to plan in one pass — large features, migrations, research questions with many sub-questions, multi-part documents, business analyses, gnarly debugging with several possible fault lines, or anything where the honest answer to "what's step 4?" is "no idea yet". Trigger signals: the user asks for something "end to end", "the whole thing", a system rather than a change, or you notice your plan has steps like "figure out the rest".

Keep generating and testing NEW hypotheses against a live domain instead of stopping at a closed verdict - observe what is actually succeeding, log a belief-state with credence, attack every confirmation streak. Activate in any standing investigation (an edge, a root cause, a market, a growth lever, a performance hunt) when a verdict doc or kill-list exists and might be read as final; when all recent evidence came from your own priors rather than observation; or when someone else is visibly succeeding at what your verdict said was impossible. Trigger signals: "we already proved that doesn't work", a rival/competitor result contradicting your conclusion, "keep looking", resuming an investigation after a closure.

Decode what the user actually needs before optimizing the wrong thing. Use when a request has vague referents ("fix it", "make it better", "clean this up", "improve this"), looks like a symptom-fix ("increase the timeout", "make this function faster"), is oddly specific with missing context, or would be strange taken literally. Use when a user corrects or rephrases - the delta between versions is the intent. ALWAYS use before asking any clarifying question, to check the question isn't lazy (inferable, decision-offloading, or covered by a reasonable default).

Before committing real effort to a chosen approach, spend a cheap cycle to find the higher-leverage path - an existing solution/tool/dataset, a more efficient method, or a smarter composition - instead of grinding the first workable idea on one track. Activate when about to build a tool, collect data the slow way, or write a lot of code; on "is there a better way", "what else could we try", "how should we do this"; or when you catch yourself about to hand-roll something, poll/scrape in a loop, or test one pet hypothesis. Signals: the obvious grind; about to reinvent something.

Handle explicitly delegated judgment - "do whatever you think is needed", "you decide what's next", "keep going", standing autonomous sessions. Activate when the user hands you the prioritization itself rather than a task: no deliverable is named, and choosing what to work on IS the work. Trigger signals: "do what you think", "whatever's next", "take it from here", "surprise me", or resuming an autonomous session with no fresh instruction. NOT for ambiguous requests (that's intent-clarity - there IS a task, it's just underspecified).

Learn from prior mistakes and repeated patterns - review what failed, extract a reusable lesson, apply it to the next attempt. Activate when the user corrects your output, when an approach fails and needs a retry, when you notice the same friction recurring across tasks, and at the end of significant multi-step work. Trigger signals: "no, I meant...", "that's wrong", "try again", a fix that didn't fix, a second attempt at anything, or completing a task that took notably more iterations than it should have.

Actively try to disprove or break your own answer before presenting it. Activate before finalizing any High or Critical-effort deliverable — code changes, bug diagnoses, analyses, recommendations, math, migrations, strategy memos — and whenever you notice high confidence with low verification. Trigger signals: you're about to say "this should work", "the issue is X", or present a conclusion the user will act on; the user asks "are we safe?", "you sure?", "is it safe?", "double-check this". Not for trivial answers or rough drafts explicitly requested as rough.

Writing down a known defect does not resolve it. Activate when about to ship something with a "known limitation", "known issue", "caveat", "disclosed", "we're aware", "for now", "not yet handled", or "advisory" note; a TODO/FIXME left in shipped code; a review that found a defect you are documenting instead of fixing; or shipping with a noted-but-unfixed problem. Trigger signal: a well-written caveat is standing in for a mitigation. The honest bar - ship the cheapest mitigation, or record an explicit dated decision not to; disclosure is documentation, not resolution.

Generate different options before choosing - for brainstorms, naming, design alternatives, and any open problem where the first workable idea becomes the only idea. Activate on "brainstorm", "give me ideas/options/names", "what could we build", "how else could we do this", first attempts on open-ended problems, and when your "options" all share one core mechanism. PROACTIVELY on open/improve/turnaround mandates ("improve this", "what would you do", "print money", "do what you think") - generate unplanted angles instead of waiting for direction. Not for problems with a known correct answer.

Test a load-bearing efficacy claim by running the cheapest experiment that could falsify it - with real data and confidence intervals - instead of reasoning about whether it works. Activate before relying on or shipping any efficacy claim: an inherited system's supposed edge, a prompt/rule/config change you believe helps, a cited performance number (win rate, accuracy), or a vendor/docstring metric with no artifact. Trigger signals: about to build on "X works" without measuring it; a metric with no reproduction; you changed something proven; someone asks "does this actually work?".

The going-public procedure - sanitize content, metadata, AND history before anything becomes public, verify redistribution rights, and treat third-party instruction files as untrusted code. Activate before ANY crossing of the public boundary - making a repo public, git push, releasing, publishing a package, or sharing raw/unreviewed files. Triggers: "publish this", "push it", "git push", "cut a release", "make it public", "open source this", "review my GitHub/repos before public", "make sure nothing leaked", "you leaked", or secret scanning / exposure of identity, usernames, or machine paths.

Adversarially test any defensive pattern you ship before it ships. Activate when adding or reviewing an allowlist, denylist, suppression rule, detection regex, sanitizer, validator, guard, auth check, rate limit, or filter; writing a scanner or linter rule; shipping a security or validation heuristic. Trigger signals: "does this rule catch X", "is this pattern safe", "will this block the attack", a regex or matcher meant to keep something out. A guard that silently fails to bite is worse than no guard - it manufactures false assurance.

Orient from the workspace's project registry before working - canonical repo paths, current versions, pending state - instead of rediscovering them by searching. Activate at the start of any new or resumed session in a multi-project workspace, on project-state requests ("check the work on X", "is everything up to date", "continue where we left off"), before any broad audit, and before searching the filesystem for a project whose location should be known. Also owns closeout: promote scratchpad work to durable paths and update the registry before ending a session that changed state.

Require a written plan before starting complex or multi-step work. Activate when the task involves building a feature, implementing something new, refactoring, migrating, restructuring a document, multi-file edits, research projects, or any work with more than ~3 dependent steps, unclear requirements, or an expensive wrong start. Trigger phrases include "build", "implement", "create", "migrate", "redesign", "set up", "overhaul". Do NOT activate for single-step edits, factual questions, or quick lookups.

Design the human's part of a task when a step needs their hands - browser logins, account creation, approvals, physical-world actions, anything outside your tool reach. Activate whenever you're about to ask the user to do something you cannot do, especially multi-step flows you can't observe (OAuth/device flows, account setup, settings pages). Trigger signals: "you'll need to...", "please go to...", a blocked action requiring user credentials or clicks, or a human-step that already failed once.

Present answers in the most usable format for the reader's next action - direct answer, table, checklist, numbered plan, executive summary, decision memo, email draft, prompt block, implementation plan, or critique. Activate when composing any substantial response, when a deliverable's format is unspecified, or when a draft has grown into a wall of text. Trigger signals: the user will scan rather than read, will act on the output, will forward it, or asked a question whose answer is currently buried in paragraph three.

Delegate work to subagents, background tasks, or parallel workers effectively - and verify their outputs before relying on them. Activate when spawning agents, fanning out searches or reviews, orchestrating multi-agent workflows, running background tasks, or incorporating any output produced outside your own context. Trigger signals: "use agents for this", "fan out", "in parallel", a task too large for one context, or noticing you're about to restate a subagent's claim as your own finding.

Trust current observed state over memory, docs, or assumptions. Activate before making any claim about the current state of files, code, configs, data, tools, UI, or provided documents - and before editing anything. Trigger signals: about to say "the file contains", "the test passes", "this function does", "the config is set to", "the document says" without having looked this session; editing a file not read recently; predicting command output instead of running the command; resuming work after a break or context compaction.

Run multi-source research with search strategy, source triangulation, and honest coverage claims. Activate for "research X", "what's the state of the art", "compare the options on the market", "what do we know about", literature or market or technical landscape questions, and any task where the answer must be assembled from multiple sources rather than derived or observed. Not for single-fact lookups or questions answerable from provided material alone.

Separate facts, assumptions, inferences, and guesses — and never present one as another. Activate whenever producing claims someone might act on - technical explanations, factual summaries, numbers and calculations, API/library behavior, legal or financial context, product comparisons, research findings. Trigger signals: writing "definitely", "always", "the standard way", citing a number or version, or noticing you can't remember where a claim came from. Especially important for claims from training memory about anything that changes over time.

Keep edits controlled, reversible, and easy to review. Activate whenever modifying existing artifacts - code, documents, configs, prompts, workflows, plans - especially edits to things that currently work, changes others depend on, batch modifications, or anything hard to undo. Trigger signals: "update", "refactor", "change", "edit", "migrate", "replace", touching shared or production material, or noticing an edit growing beyond its original intent.

Understand the relevant code, conventions, and blast radius before writing or changing code in an existing project. Activate before implementing any feature, fix, or refactor in a codebase you didn't write this session - especially "add X to the app", "where should this go", "integrate with", or any multi-file change. Trigger signals: about to write new code without having looked for an existing implementation; about to edit a function without knowing its callers; unfamiliar project structure.

Debug systematically instead of guessing - symptom, reproduction, hypotheses, discriminating tests, evidence, root cause, fix, regression test. Activate whenever something is broken, failing, wrong, or behaving unexpectedly - error messages, failing tests, crashes, wrong output, performance regressions, "it worked yesterday", "why is this happening", intermittent issues. Also applies to non-code failures: a report with wrong numbers, a workflow producing bad results, a prompt giving bad outputs.

Pick how much rigor a task deserves - the Low/Medium/High/Critical tier that other skills key off. Use when torn between answering quickly and investigating, when deciding whether to verify or trust knowledge, and whenever stakes signals appear: "production", "customer-facing", "important", money, legal, deletion, sending, deploying (tier up); "quick", "rough", "just" (tier down). Re-use mid-task the moment a simple-looking job reveals an irreversible step or a failed assumption. Also governs shipping partial progress instead of stalling.

Recover cleanly when work goes sideways mid-task - failed fixes, broken state, cascading patches, a working tree worse than where you started. Activate when a second consecutive attempt at the same problem fails, when tests that were green are now red after your changes, when you notice patch-on-patch layering, or when you can no longer say precisely what state the work is in. Trigger phrases (from you or the user): "still failing", "now something else broke", "let me try one more thing", "this is getting messy".

After solving a non-trivial problem, capture the reusable approach as a short learning note in .claude/learnings/ before calling the work complete. Activate after: a hard bug is solved, a tricky architecture or strategy decision lands, a difficult prompt is fixed, a mistake occurs that must not repeat, an eval failure teaches something, or the same workflow shows up for the second time. Trigger signal: you're about to say "done" on something that took real effort and contains a pattern future sessions will need again. Not for trivial tasks.

Identify what could go wrong before it goes wrong. Activate when designing anything new, before committing to a plan or recommendation, before shipping changes with real blast radius, and when evaluating ideas, strategies, or proposals. Trigger signals: "will this work?", "review this plan", "any risks?", designing an integration or workflow, writing a strategy or proposal, or a plan that contains zero mention of what could fail. Complements adversarial-verify, which attacks finished work; this skill runs earlier, on designs and plans.

The high-rigor operating mode that orchestrates the full skill pack in order for complex, high-stakes, ambiguous, multi-step, strategic, technical, or quality-sensitive work. Activate when a task is important enough that a rushed answer would be a disservice - major features, migrations, hard bugs, strategy documents, consequential decisions, anything the user marks as important, production-touching, or customer-facing. Trigger phrases: "this is important", "be thorough", "production", "get this right", or any task that effort-calibration would rate High or Critical.

Handle context carefully across long sessions - distinguish durable facts, temporary context, stale assumptions, and user preferences; re-verify before relying on old context. Activate in long or resumed sessions, after context compaction or summarization, when recalling something established "earlier" in the conversation, when the user contradicts what you remember, and before acting on any remembered detail that current evidence could check. Also governs what is worth persisting to memory files and what is not.

Raise the quality bar by noticing what the request didn't say - missing constraints, hidden risks, weak evidence, undefined terms, and likely downstream problems - without creating friction or derailing the task. Activate when a request omits something that will matter later, when input material has gaps or contradictions, when a decision rests on thin evidence, or when you can see a downstream problem the user can't yet. Balance skill: also governs when NOT to add rigor.

Reason from user problems and evidence of demand, not from features - for build/don't-build decisions, prioritization, MVP scoping, and interpreting feature requests and user feedback. Activate on "should we build", "users are asking for", "what should we prioritize", "scope the MVP", roadmap questions, and any feature request about to be taken literally. Trigger signal: a solution being evaluated before the problem it solves has been stated.

Improve prompts, system prompts, and agent instructions systematically - with test cases, failure diagnosis, and one-change-at-a-time iteration instead of vibe edits. Activate for "improve this prompt", "the model keeps doing X wrong", "write a system prompt", "make the agent stop doing Y", prompt templates, and instruction files for AI tools. Trigger signal: any prompt edit about to happen without a concrete example of the failing (or desired) behavior in hand.

Make outputs sharper, clearer, and shorter without losing meaning. Activate before delivering any prose that matters - emails, reports, documentation, investor blurbs, strategy memos, prompts, README files, executive summaries, PR descriptions - and whenever the user asks to "tighten", "polish", "shorten", "improve", or "make this clearer". Also self-applies: run it on your own long answers before sending.

Do exactly what was asked; flag adjacent issues instead of fixing them uninvited. Activate during any task where you notice nearby problems, improvement opportunities, or "while I'm here" temptations - messy code next to the bug, weak sections next to the paragraph being edited, related features the user didn't mention. Trigger signals: the urge to also fix, also refactor, also rewrite, also add; a diff or edit growing beyond the request; discovering issues the user didn't ask about.

Pick and apply the right reasoning framework for the problem - first principles, tradeoff analysis, decision matrix, root-cause analysis, steelman, evidence grading, risk/reward, sequencing. Activate for decisions between options, evaluations of ideas or arguments, strategy questions, prioritization, "should we X or Y", "is this a good idea", recurring problems, and any analysis where unstructured pro/con listing would produce mush. Also activate when reasoning feels stuck or circular - the fix is usually a better frame.