{ "count": 26, "prompts": [ { "slug": "explore-not-decide-gate", "title": "Explore, don’t decide: widen the field before the model converges", "url": "https://funnyenough.dev/prompts/explore-not-decide-gate/", "one_liner": "A role-boundary prompt you paste at the moment before you ask AI to recommend - it separates supported facts from inferences, returns three materially different framings (each with its key assumption and failure mode), runs a divergence check against fake variety, and refuses to pick a path, so the first plausible answer can't quietly anchor the decision.", "raw": "MODE: EXPLORE, NOT DECIDE\n\nQuestion: {{question}}\nMy current framing: {{current_framing}}\nKnown constraints: {{known_constraints}}\nWhat I may be assuming: {{assumptions}}\n\nReturn:\n\n1. Facts you can support from what you can actually see this turn - the provided\n context, files read this run, or tool / browse output in this conversation. Link\n each. If you have no accessed sources this turn, say so plainly and do not invent\n citations.\n\n2. Inferences, clearly labelled as inferences (not facts).\n\n3. Three materially different framings of the problem - not three phrasings of one.\n For each, state its key assumption and its likely failure mode.\n\n4. Divergence check: name the assumption all three framings share. If they share the\n decisive one, throw one out and replace it with a framing that challenges it.\n\n5. Important unknowns, and the evidence that would resolve each.\n\n6. Choices that depend on purpose, taste, or values. Mark these as mine to make,\n not yours to decide.\n\nDo not recommend, rank, score, or name a \"leading\", \"strongest\", or \"default\"\nframing - no \"I would choose\", \"most teams\", or \"best option\". End with the single\nquestion whose answer would most change the available option space.", "sha256": "71a49ff7fa41d5282bbb064aff36b7e4e235b58fcaf9d7ce850dffdb6fda6de8", "kind": "Divergence gate", "breaks_when": "It is a role boundary, not a truth machine. The model can still return three framings that share one hidden assumption (the divergence check helps but the model grades its own homogeneity), label a guess as an \"inference\", or - if it cannot actually browse - fabricate citations despite the instruction, so you still have to inspect what it claims to have read. \"No recommendation\" is also not the same as no influence: it can steer you through ordering, adjectives, and how much detail it gives each framing. And it has a cost - on a genuinely simple or already-scoped task, forcing divergence is ceremony that adds latency and reads as busywork; it only governs the exploration turn, so nothing stops you anchoring at convergence unless you switch modes deliberately.", "tested_with": "model-agnostic", "born_in_post": "/first-plausible-answer-design-decision/", "variables": [ "question", "current_framing", "known_constraints", "assumptions" ], "last_verified": "2026-06-29", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "vague-request-to-spec-assumption-tags", "claim-ladder-verify-before-encode", "sign-off-evidence-gate" ], "relates_to": [ "two-critic-judge-dedupe", "multi-lens-qa-fanout-triage", "module-by-module-product-ux-review" ] }, { "slug": "sign-off-evidence-gate", "title": "Sign-off gate: prove the claim or label it NOT RUN", "url": "https://funnyenough.dev/prompts/sign-off-evidence-gate/", "one_liner": "Before an agent says \"tests pass\", \"done\", or \"safe to deploy\", forces it to grade the claim by how it was actually obtained and lead with a one-line proof tied to visible evidence (command + exit + output) - or downgrade to NOT RUN - so it can't claim a check it never made.", "raw": "You are about to make a SIGN-OFF claim: {{sign_off_claim}}\n\nA sign-off claim is any assurance of completion, correctness, safety, readiness,\nfreshness, or pass/fail status - \"done\", \"fixed\", \"tests pass\", \"build is green\",\n\"safe to merge / deploy / delete\", \"looks good\", \"ready\", \"verified\", \"CI is green\",\n\"latest / current\" - regardless of the exact words, and especially in a final reply,\na PR or commit message, or a handoff note. (While you are exploring, reading, or\ndrafting, none of this applies - move fast.)\n\nBefore you say it, grade HOW you actually know it, lowest to highest:\n E0 guess - training memory, habit, \"usually works this way\"\n E1 told - user, README, docs, a comment, a subagent's summary\n E2 read - you read the current local source / diff / config this run\n E3 ran - you executed the command / test / build this run and saw the output\n E4 external - you freshly checked authoritative external state this run: CI, prod,\n a registry, a remote PR, a live API (stale logs / screenshots are E1)\n\nRules:\n- A tier attaches to the exact CLAIM, not the session. Running one command does not\n upgrade every nearby statement. Each distinct sign-off claim needs its own proof or\n its own NOT RUN; one passing test does not make \"safe to deploy\" true.\n- \"code works / tests pass / build healthy\" needs E3. \"CI / prod / latest\" needs E4.\n- Proof is not your own say-so. A Verification line must point at evidence visible in\n THIS conversation - a command's output, a tool-call transcript, a CI / job URL - not\n a remembered or hypothetical run. If that evidence is not present, write NOT RUN.\n- In any message that makes a sign-off claim, the FIRST line must be one of:\n Verification: | | \n NOT RUN - recommendation only\n BLOCKED: | need: | risk: \n No sign-off wording may appear above that line.\n- Never invent a value to fill a gap (SHA, count, version, status, result). If a live\n run contradicts an earlier claim, say so in one line and let the run win.\n\nCompliant first lines look like:\n Verification: npm test -- auth | exit 0 | 42 passed, 0 failed\n NOT RUN - recommendation only\n BLOCKED: \"safe to deploy\" | need: staging smoke run | risk: ships the lock bug", "sha256": "3fae3fb2cbe6d20e533a16ff58aca30d1707159d92a4bf0d483f8c689ca7cecf", "kind": "Sign-off gate", "breaks_when": "The proof is still text the model emits, so it is honor-system, not cryptographic - a determined or turn-budget-pressured agent can paste a stale log, fabricate an exit code, rephrase around the trigger words (\"green locally\"), or call finished work \"exploration\" to dodge the gate. A real run is also higher-grade evidence, not truth: it can pass against mocks, against only the visible tests while a hidden case fails, or in the wrong repo, branch, or tenant and still read as proof. The per-claim rule helps but does not stop a single passing run being stretched over a riskier nearby claim it never tested. For real assurance the proof has to come from the harness attaching the tool's actual output - a receipt - not from the model's own sentence; this gate raises the cost of the lazy lie, it does not stop the determined one.", "tested_with": "model-agnostic", "born_in_post": "/agent-said-the-tests-passed/", "variables": [ "sign_off_claim" ], "last_verified": "2026-06-29", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "claim-ladder-verify-before-encode", "no-fix-without-failing-repro", "adversarial-fix-verification" ], "relates_to": [ "abstain-gate-suppress-stale-inputs", "byte-exact-copy-paste-audit", "fail-open-fail-closed-audit" ] }, { "slug": "governance-audit-and-level-up", "title": "Audit your governance, then level it up (enforced, not theatre)", "url": "https://funnyenough.dev/prompts/governance-audit-and-level-up/", "one_liner": "A read-only audit of a project's rules, configs, gates, and agent contracts that runs the gates rather than reading them, grades each as enforced-or-aspirational, fail-closed-or-open, and load-bearing-or-theatre, hunts the high-leverage governance most projects lack, and returns a ranked, reuse-first plan to make it hold.", "raw": "You are auditing a project's GOVERNANCE - the rules, configs, gates, and contracts meant to keep work safe, consistent, and honest - then proposing a ranked plan to level it up. The goal is not more rules; it is governance that holds. The core move: do not grade governance by reading config, grade it by RUNNING the gates (under the SAFE-COMMAND RULE) - enforced-vs-aspirational is decided by execution, not by what a file claims. Stay read-only (propose, never rewrite governance files or flip gates) until the plan is approved.\n\nProject and what \"governance\" covers here:\n{{project_context}}\n\nThe standard to hold it to (what \"good\" means here):\n{{quality_bar}}\nIf this bar is empty or too vague to fail anything against, STOP and ask for a concrete standard; do not infer one from the repo. An audit against an implicit bar is non-falsifiable and rubber-stamps whatever exists.\n\nAudit depth (default standard); keep all three tiers, per-gate timeout scaling with depth (quick 120s, standard/deep 600s, never smaller for a deeper tier):\n- quick = root configs plus at least one documented local gate actually run. Root skim only: do NOT run the Phase 2 gap checklist or emit a ranked plan; end with the label complete-enough-for-root / package-level-unknown.\n- standard = every safely runnable gate run once; root and obvious sub-trees inventoried (workspace members, CI-matrix packages, any app/package with its own manifest such as package.json, pyproject.toml, Cargo.toml, go.mod).\n- deep = per-package enumeration across every such sub-tree in a monorepo, gates run per package.\n{{audit_depth}}\n\nSAFE-COMMAND RULE (wherever this contract says \"run\" a gate). Run gates ONLY in a disposable clone/worktree/temp copy (or with the write step disabled) - never mutate the live source tree or other non-disposable state (databases, caches, generated files, emulator state). A write-disabled run counts as ENFORCED evidence ONLY if it still exercises the real check logic (a fixer run in check-only mode still flags violations); if disabling the write neuters the check, that run is config-derived/UNKNOWN, not proof. To exercise a path, point a gate at an existing file in that domain, or create/modify a throwaway file in the disposable copy only. OFF LIMITS: anything that deploys, releases, force-pushes, mutates a shared/production resource, writes to the network, or needs secrets you lack - classify from config and mark live state config-derived/UNKNOWN. If unsure whether a command is safe, treat it as unsafe. Bound each run: a gate that exceeds the timeout, is too broad (fans out across a monorepo), or is unsafe is marked not-run with that reason. Not-run is an honest result; a guessed pass is not.\n\nAUDIT BASIS (declare before Phase 0, so the audit cannot drift into \"I looked around and ran some stuff\"): repo root and commit/ref; depth; the disposable-copy path used, or why none was available (which forces config-derived for every machine gate); how exact output was captured (full stdout/stderr, not truncated); working-tree state (clean/dirty, which branch); the per-gate timeout; and whether platform settings (branch protection, required checks, org config) are visible or only inferred from committed config.\n\nPHASE 0 - INVENTORY (read-only). Report your search strategy first (repo root, commands run, config locations checked, surfaces you could not reach); \"unknown\" is allowed, do not guess. Then cite every governance surface with file:line or a command: written rules/contracts (AGENTS.md, CLAUDE.md, CONTRIBUTING, operating docs, ADRs, runbooks); enforced gates (CI checks, pre-commit/pre-push hooks, required reviews, branch protection, lint/type/test config, a one-command local gate); automation/agent contracts (how sub-agents/jobs are dispatched, what they may touch, kill switches, permission scopes, who reports to whom); state/handoff (handoff/session-state docs, decision journals, shared parallel-work state); secrets/permissions (what is gitignored, token scopes, who may run destructive commands). Mark anything not directly read as [INFERENCE]; if a gate lives where you cannot read it (CI web UI, org setting), say so rather than guess.\nClose Phase 0 with a CRITICAL-SURFACE MAP: name what governance here protects (trunk/release branches, production data, secrets, generated/published artifacts, automation permissions, end-user output) and RANK each asset by how irreversible its loss is, not by audit convenience. The \"top three assets\" referenced later are the three highest-ranked; on dispute default conservative (production data, secrets, trunk/release integrity outrank convenience). Every later finding maps to an asset; an item protecting nothing real is not-needed, not absent.\n\nLEGEND (used by every phase):\n- NEGATIVE-CONTROL roles, non-overlapping: Lens 1 proves the gate RUNS; Lens 3 proves it FAILS for the intended reason (a known-bad input); Phase 2 NEGATIVE CONTROL checks that proof is DURABLE (a reusable fixture is committed, not improvised once).\n- RETAINED RECEIPT (the only evidence that grades a gate PROVEN without a fresh negative control): a timestamped CI run, hook log, PR check, or committed fixture/probe naming the SAME gate entrypoint, the SAME failure mode, and a commit/run id. An old red log for an unrelated gate is not a receipt (PLAUSIBLY at best).\n- CONFIGURED vs ACTIVE platform enforcement: committed CODEOWNERS or workflow YAML proves CONFIGURED, not that the platform blocks merges. ACTIVE requires readable platform settings, protected-branch evidence, or a retained failed-merge/required-check receipt; without one, mark platform enforcement [INFERENCE].\n\nPHASE 1 - AUDIT each surface against five lenses plus a freshness tag. One row per distinct gate or rule cluster (not per file or sentence), but split rows whenever the protected asset, trigger, owner, mechanism, or freshness differs, so a weak sub-rule cannot hide inside a broad \"CI\" row. Give a verdict and evidence per item:\n1. ENFORCED vs ASPIRATIONAL - does a real mechanism run, or is it only written and hoped for? Usually the biggest finding. Classify as machine (a check that can fail the build), platform (CODEOWNERS, required reviews, branch protection, release approval), PROCESS-DEPENDENT (a documented human step nothing blocks if skipped), or aspirational (none). PROCESS-DEPENDENT caps below machine/platform unless a platform/workflow actually blocks without it - else an auditor \"passes\" by labelling a checklist human-required. Platform enforcement must cite block-without-merge evidence (CONFIGURED-vs-ACTIVE); a rubber-stamped CODEOWNERS review with no active branch protection is partial. For a machine gate, do not classify from config: RUN its entrypoint against real production code/config on a path it claims to cover, and cite exit code plus output. Whether the run catches a bad change is Lens 3.\n2. FAIL-CLOSED vs FAIL-OPEN - when input is missing, stale, or broken, does it default to blocking (safe) or proceeding (unsafe)? Name the worst action it permits on failure and flag any default-allow fallback. SEVERITY IS INTENTIONALITY-AWARE: a fail-open or honor-system accepted by a cited, dated decision is far lower severity (aspirational-by-design) than the same hole by accident. (The catastrophic-command deny-list lives under LEAST-PRIVILEGE; do not re-audit it here.)\n3. LOAD-BEARING vs UNEXERCISED - would a realistic bad change actually be stopped, or is this noise everyone waves through? The one place the contract reasons about whether a gate fails for the RIGHT REASON: a gate is load-bearing only if a NEGATIVE CONTROL (a known-bad input) makes it fail correctly. VACUOUS-PASS sub-check: can the gate report success WITHOUT exercising the real target - passing on a --help, a skipped test, a dry run, or an unrelated path; skipping when a file is absent without confirming why; testing re-implemented rules instead of production code; verifying against truncated/compressed output instead of exact bytes? A gate that cannot fail is not load-bearing. Grade: LOAD-BEARING-PROVEN = a negative control was executed or a retained receipt exists; PLAUSIBLY-LOAD-BEARING = you name the minimal known-bad input but did not run it (naming is never proof); ENFORCED-but-not-LOAD-BEARING = neither. At standard/deep depth every top-three-asset gate must reach LOAD-BEARING-PROVEN (run the negative control in the disposable copy, or cite a receipt); lower assets may stop at plausible. Missing telemetry on whether it ever fired = UNKNOWN, routed to ANTI-THEATRE INSTRUMENTATION. A gate routed around by chronic --no-verify or skip-on-flake is not load-bearing however it grades; name that bypass.\n4. COVERAGE / TRIGGER MATRIX - which branches, paths, file types, commands, roles, and events does it cover, and what is out of scope? Are the skips intentional and visible, or silent holes? A gate can be enforced and load-bearing yet miss the path, branch, runtime, or actor that matters.\n5. SINGLE-SOURCE vs DRIFTING - is each rule materialized once (one canonical source), or copied across configs/docs that can silently disagree? Is there an explicit authority order for conflicts, and are historical docs marked historical?\nThen tag each item CURRENT or ROTTED, with evidence: CURRENT needs a last-change/last-run date, an owner, or a recent firing; ROTTED needs cited staleness (a stale date, a broken config reference, a never-firing run); with neither, freshness is UNKNOWN, not CURRENT. For a rotted gate, name the MISSING owner, the consequence of leaving it, and the decision needed (do not invent an owner or deadline). When lenses disagree, report the worst-case classification and name the tension (\"enforced but vacuous,\" \"load-bearing but drifting\").\n\nPHASE 2 - GAPS. Hunt the high-leverage governance that is MISSING. DECISION-RECORD PRECONDITION (mandatory, BEFORE you report ANY item absent/partial/not-needed): search docs AND git history for that control (git log -S / --grep / log on the file, an ADR/issue/PR grep, a deferral doc) and CITE either the deliberate decision or \"no decision found\". A documented, dated \"we do not do X because Y\" - or a control removed-with-a-reason - is a CHOICE, not a gap (route by-design, lower severity); an unsourced doc line or an assumption of intent is NOT, and stays a gap. A gap reported without this cited check is INVALID, drop it. Then classify EACH item as present / partial / absent / not-needed-for-this-project / N/A, map each to an asset, and for absent/partial name the failure it prevents; for not-needed, name the failure you accept. [agent/parallel/automation] items are required only when the project runs agents, parallel work, recurring handoffs, or repeated automation failures (normal CI alone does not need agent chain-of-command machinery); mark one N/A only after an actual search comes up empty (CI workflows, cron jobs, hook scripts, bot accounts, dispatch docs - a repo-root glance is not a search). Mark a control present ONLY if the artifact exists and is cited; \"I would break X\" prose, or a Phase-3-only fix, is partial/absent, never present.\n- KILL SWITCH [automation]: one no-secret, low-friction way for the owning humans (e.g. a sentinel file any maintainer/cron can create) to hard-halt all automation at once. Prevents a misfiring job nobody can stop.\n- PRE-FLIGHT GATE: a check before work so wrong state shows on the first action; a binary hard-stop is present, require three states (HARD-STOP / WARN-and-continue / proceed) only where warn-and-continue is a genuine need. ENFORCEMENT TOIL: a load-bearing gate so slow everyone skips it (slow p95 + bypass evidence) = partial. LOCAL/CI PARITY: a local gate must predict its CI check (same pinned versions, package scope, rule set) or it is green-locally-red-in-CI theatre (silent divergence = partial).\n- BLAST RADIUS / STOP / RECOVERY: across ALL automation, the worst irreversible damage one run can do before something halts it, plus RUNAWAY (retry storms, fan-out, recursive triggers, runaway API/CI spend) and the cap that stops it (max retries, concurrency limit, budget alarm, timeout) or its absence; and recovery is not prevention - for production/published/generated/shared data, a tested undo/restore path with a named owner and max recovery window (local-only or trivially reproducible is not-needed).\n- FAILURE-MODE LEDGER [automation]: the recurring ways the system breaks, each with detection / prevention / recovery plus a last-hit date and routing by surface, so a known failure is recognized not re-debugged.\n- NEGATIVE CONTROL: a committed, reusable negative-control fixture set (sentinel fixture, known-bad config, dry-run failure probe, periodic spot check) for the top-three-asset gates, re-provable to fail for the intended reason on demand. Lens 3 does the one-time proof; this asks whether it is retained. Without one, \"the gate passed\" is unproven.\n- FAILURE VISIBILITY + OWNERSHIP: who SEES a load-bearing gate failure (shared/delegated work needs a named owner/channel within one work session; a silent local-only failure there is absent escalation, not missing enforcement on a solo project) and who OWNS it (an ownerless gate everyone sees and nobody fixes is a gap).\n- PROVENANCE (gates / releases / supply chain): gate actions/hooks/tools pinned and reviewable (third-party or security-sensitive by commit digest, first-party version-pinned with an accepted-risk note) with outcomes retained per commit/run; published/deployed outputs trace to a commit, build run, digest/version, and promotion approval, generated artifacts carry a regeneration command + owner (N/A if it never publishes/deploys/generates shared artifacts); lockfiles committed and enforced in CI with an update policy and vulnerability response (known-CVE gate or accept-risk note) - pinning stops drift but is not security.\n- ANTI-THEATRE INSTRUMENTATION [agent/automation]: light telemetry on each gate/reviewer (fires? waved through? ever blocks?), with a periodic pass that DEMOTES rules waved through most of the time, RETIRES rules that never fire and are covered elsewhere, and SPOT-CHECKS any gate that only ever passes.\n- REPORT-UP chain-of-command [agent]: delegated agents/jobs return findings to the dispatcher who verifies, never sideways to the end user un-triaged; if children inherit the parent's tools/permissions, constrain that in the dispatch prompt, else cite the actual permission model.\n- CALIBRATED REVIEWER [agent]: advises pass / warn / block, ABSTAINS to the conservative outcome on uncertainty, gives proof-of-engagement (a short considered-but-not-flagged list), and cites a specific rule for every finding. N/A only after the automation search comes up empty.\n- HANDOFF, STATE + PARALLEL ISOLATION [agent/parallel]: a fresh session/owner could reproduce current state from the handoff alone, the live-state doc cannot silently go stale (ideally a gate blocks closing out work until current), and concurrent agents/jobs cannot stomp shared state (branch, worktree, lockfile, or handoff discipline).\n- LEAST-PRIVILEGE + SECRETS + BOUNDARY: secrets gitignored and never echoed, scoped/rotatable tokens, an allowlist of what automation may run, no standing grant for irreversible actions, a deny-list for catastrophic commands (rm -rf of home/root, force-push to trunk, hard reset, production delete - flag a missing deny-list here, not Lens 2), an active scan blocking a credential pasted into a tracked file/log/fixture, and a prod/staging boundary (a job cannot reach prod by default; CI from forked/untrusted PRs cannot read secrets - name any low-trust trigger touching a high-trust resource).\n- SANCTIONED EXCEPTION PATH: a way to deviate from a rule on purpose (surface it, weigh the trade-off, get a yes, log it) so people neither rigidly block nor silently violate; exceptions carry a TTL and expire back to the rule.\n- BYPASS / TAMPER CONTROL: who can edit, disable, or weaken the governance itself, and what stops a quiet self-approved weakening - protected governance files, CODEOWNERS/required review on CI/hooks/security configs, logging when a gate is skipped or overridden, no self-approval for a rule that lowers the bar.\n- GOVERNANCE-OF-GOVERNANCE: a scheduled, owned pass auditing the governance for bloat, staleness, drift, \"which documented rule has zero enforcement?\", and a change ratchet (a net-new gate retires/demotes another) so the rule set cannot only grow. ANTI-THEATRE feeds it - when both point at the same rule, raise one retire/demote proposal in Phase 3, not two.\n\nPHASE 3 - LEVEL-UP PLAN. Rank highest leverage first by consequence (the asset at risk, how irreversible its loss), not by ease. For each change give: the failure it prevents, the smallest first step, how to make it ENFORCED not aspirational (wire it to a real gate, hook, or CI), whether it is reversible, the evidence it rests on, and a FRICTION TAG - SILENT (deny-list, hook, cron, CI: no prompts) or NAGS (re-adds an ask/confirm tier, shrinks an allow-list, removes a bypass). Rules:\n- A fix MUST NOT silently reverse a deliberate trade-off: never reintroduce NAGS friction the owner removed on purpose. Prefer SILENT - a real safety win (closing a deny-list hole, a kill-switch hook) ships with ZERO new prompts.\n- Reuse before you import: extend a mechanism the project already has rather than add a new tool or doc.\n- Enforced-and-few beats aspirational-and-many: do not propose rules nobody will enforce; that is negative value.\n- Anything borrowed from outside the repo (another project, a best practice) is marked borrowed, with one line on why it fits HERE.\n\nHARD RULES:\n- Read-only until approved: you propose, you do not rewrite governance files or flip gates.\n- CLAIM LADDER: never encode or assert a load-bearing fact (a config, threshold, enforcement verdict, guardrail) on memory or doc authority. Drop to a live run and cite file:line or command output against exact bytes; every safely runnable gate must actually be run.\n- Respect intentional choices: honor the DECISION-RECORD PRECONDITION (Phase 2) - a deliberate, cited choice is never a gap.\n- Every verdict cites evidence. \"Looks fine\" is not a finding; \"no telemetry, so we cannot tell if it ever fires\" is.\n- Abstain where a call needs context you do not have, and say exactly what you would need to decide it.\n- Enforced-but-wrong is not yours to fix: if a gate is enforced and load-bearing but conflicts with the quality_bar, flag it enforced-but-wrong and route it to the gate owner; do not silently fix the bar in the audit output.\n- Do not invent governance a project does not need: downgrade a gap to not-needed or N/A only under the Phase 2 evidence bar with a named accepted failure, never as a blanket \"small project\" pass.\n\nUNKNOWN CAP: UNKNOWN, not-run, and config-derived are honest results, but they are not an audit. Compute the ratio over machine-runnable gates only (those with a documented entrypoint you could have run), so doc-only rules cannot dilute the denominator. Count toward the numerator a runnable gate you failed to exercise: one collapsed into a broad row, or skipped. Do NOT count surfaces unreachable by nature (org branch protection, CI web UI, hosted secrets); report those separately as KNOWN-EXTERNAL, so a clean audit of a normal repo is not called incomplete for surfaces no local run can reach. If more than 30% land in UNKNOWN / not-run / config-derived combined, label the audit incomplete-not-an-audit, say what you could not reach and why, and do NOT emit the final verdict. Track platform items separately: if more than 50% of platform-enforcement items are config-derived or UNKNOWN, report platform governance unverified on its own line even when the machine-gate ratio passes.\n\nEnd with: the inventory table (surface | enforced? | fail-closed? | load-bearing? | coverage | drift | freshness | evidence), where drift carries Lens 5 (single-source vs drifting) and freshness carries Lens 6 (current vs rotted) so all six lenses reach the deliverable; at standard/deep depth also the gap list (present / partial / absent / not-needed / N/A, with the failure each prevents) and the ranked level-up plan; and - unless the UNKNOWN CAP suppressed it - one honest line: is this governance currently load-bearing, or theatre? At quick depth, stop after the inventory table and the complete-enough-for-root / package-level-unknown label.", "sha256": "a2230c76239348b981f3767c0b806936226a75f730e91df36feab40612b2716f", "kind": "Optimisation", "breaks_when": "It only judges governance it can read or run. External CI settings, org branch protection, hosted secrets, and private dashboards stay UNKNOWN rather than proven, and a locally green gate can diverge from CI. A gate green for the wrong reason can be miscalled load-bearing, and a single run without a retained receipt can mis-grade a flaky gate. An empty quality bar makes the audit non-falsifiable, so it rubber-stamps whatever exists. It cannot prove a level-up works until the change is made, nor tell an enforced-but-wrong rule from an enforced-and-right one without the owner's domain judgment.", "tested_with": "model-agnostic", "born_in_post": "/guardrails-over-trust-autonomous-agents/", "variables": [ "project_context", "quality_bar", "audit_depth" ], "last_verified": "2026-06-22", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "respect-deferred-state-audit-guard", "fail-open-fail-closed-audit", "claim-ladder-verify-before-encode" ], "relates_to": [ "multi-lens-qa-fanout-triage", "plan-then-apply-destructive-gate" ] }, { "slug": "collaborative-dispatch-brief", "title": "Brief a sub-agent like a colleague, not a warrant", "url": "https://funnyenough.dev/prompts/collaborative-dispatch-brief/", "one_liner": "A fixed skeleton for the prompt you hand DOWN to a sub-agent - goal and trust instead of a recipe and a wall of prohibitions, with a strict-mode gate up front, a bounded license to adapt, and a recover-before-you-escalate failure rule.", "raw": "You are briefing a sub-agent to do a piece of work on its own. Write the brief the way you would brief a trusted colleague you will not be able to reach mid-task - give it the outcome and the why, the few hard limits that genuinely matter, and the room to figure out the rest. Do NOT write it like a warrant: a rigid command-by-command recipe wrapped in a wall of prohibitions makes a capable agent halt at the first surprise the recipe did not foresee.\n\nSTEP 0 - CLASSIFY THE TASK FIRST. Before you write a single section, decide: does this work involve deletes, migrations, deploys, moving money or credentials, security-sensitive data, irreversible state, or steps that must run in an exact order? If yes - or if you are unsure - this is a STRICT-MODE task and the rules below change. In STRICT MODE you do NOT include the ADAPT FREELY section at all, and you REPLACE the FAILURE MODE section with: \"STOP on any deviation, unexpected output, missing prerequisite, or uncertainty, and report before doing anything else.\" Open the brief with one line: \"STRICT MODE - do NOT adapt; follow these steps exactly\" plus one line stating WHY this task is strict. Here the recipe-and-prohibitions posture is the correct one and improvisation is the hazard. A brief that contains both a strict-mode banner AND an adapt-freely license is malformed - never ship both.\n\nIf the task is genuinely routine and reversible, fill in this skeleton, in this order, and hand the result down as the dispatch:\n\nGOAL\nOne sentence naming the desired END STATE, not the steps to get there. \"The test suite passes on the project's pinned runtime in CI\" - not \"run the version-switch, then the install, then the test command\". Describe done, not the path.\n\nCONTEXT\nTwo or three sentences: why this matters, what it unblocks, what depends on it landing. The agent makes better judgment calls when it knows the stakes, not just the instruction.\n\nSCOPE\nName the expected work area and the acceptable blast radius - the files, the module, the surface the agent is meant to touch. The agent may adapt its METHODS inside that area, but may NOT expand the task, change unrelated public behavior, add new dependencies, or make any irreversible change unless this brief explicitly authorizes it. Adaptation lives inside SCOPE; it is not a license to widen it.\n\nCONSTRAINTS (load-bearing ONLY)\nList only invariants whose violation BREAKS the project - a public contract, a data-safety rule, an irreversible boundary. Each must be a real \"if this is wrong, real damage\" line. Before you write each one, ask: is this a true invariant, or just my hunch about how the agent should work? Delete every \"do NOT touch file X\" / \"do NOT change approach Y\" that is mere preference or suspicion - those are the lines that make an agent freeze. Prefer one to three load-bearing constraints; if you reach for more, that is a signal you are smuggling preferences in as laws, so cut the preferences. But if more than three are GENUINELY required - privacy, legal, security, finance and publishing work can carry several real invariants - keep them all, or group them under named invariant categories. Never delete a real invariant just to hit a number; the cap targets defensive residue, not real laws.\n\nADAPT FREELY\nState plainly that the agent is authorized to find its own path TO THE GOAL, WITHIN SCOPE: try a different dependency flag, work around an environment quirk, substitute an equivalent command, pick a cleaner implementation than the one you imagined. Anything inside SCOPE and not named in CONSTRAINTS is fair game. But any step that is irreversible - a delete, a deploy, a migration, a spend, a credential move - is out of bounds unless GOAL or a CONSTRAINT named it explicitly; if the agent finds it needs one and was not authorized, it STOPS and asks. You are licensing judgment, not insubordination, and not destruction.\n\nFAILURE MODE\nOn a transient or unexpected error: investigate the actual cause, then retry ONCE - one end-to-end recovery attempt with a different approach, not one retry per sub-command. Escalate back to me ONLY if recovery genuinely fails, with what you tried, why it did not work, and the current state of the system. Do NOT halt on the first error and do NOT report a recoverable hiccup as a blocker - a colleague would try the obvious fix before knocking on my door. BUT do NOT retry at all if the failed attempt may have left a partial side effect, changed external state, touched production data, exposed a secret, or signals a violated constraint - in those cases treat it as a blocker, stop, and report immediately. Retry is for clean failures only.\n\nDONE\nA concrete success checklist the agent can verify against itself before declaring victory - independent checks that would FAIL if the goal were not actually met, stated as commands, artifacts, or signals a third party could re-run (a passing check, output that proves the END STATE, a file that now exists with the right contents). Do not let the checklist be satisfiable by weakening or deleting the check itself. Vague \"looks done\" is not done.\n\nREPORT\nOne summary at the end: what it did, the evidence it is done, what it adapted and why, and anything it could NOT resolve. Report findings UP to me in this summary - do not open side channels or surface work elsewhere.\n\nTHEN, BEFORE YOU SEND IT, self-check the brief you just wrote:\n- If the task is irreversible, security-sensitive, order-dependent, or you were unsure, did you switch to STRICT MODE before granting any adaptation - and is the adapt-freely license absent?\n- Is every CONSTRAINT actually load-bearing, or did defensive residue sneak back in? Cut what is not. Are the agent's adaptation rights bounded by SCOPE and CONSTRAINTS, not open-ended?\n- Does DONE contain evidence that would independently PROVE the GOAL, or only a log of activity? If it only proves activity, rewrite it into checks a third party could re-run.\n- Read it cold: does it sound like briefing a trusted colleague, or like issuing a warrant to a suspect? If it reads as a warrant, rewrite it until it reads as a briefing.", "sha256": "fb14276543926cf599d41f10566180e5d01a1e8d9ce76af36b7caec47630f564", "kind": "Agent dispatch", "breaks_when": "The trust posture is calibrated for low-stakes, reversible work. Mis-classify an irreversible, security-sensitive, or order-dependent task as routine and \"adapt freely\" turns a guardrail into a loaded gun - the agent improvises exactly where it must not. The strict-mode gate up front is the guard against that, but it only protects you if you actually run the classification honestly; a lazy \"this looks routine\" defeats it. It also optimizes for completion, so when correctness or safety must dominate over getting-it-done, the wrong objective is baked in. The constraints cap is a forcing function to cut defensive residue, not a guarantee you listed the right invariants - under-count what is load-bearing and a real limit goes missing. And even with a SCOPE line, an agent told to adapt can still \"solve\" the task by expanding into adjacent systems; the scope boundary narrows that blast radius but does not eliminate the judgment call about what counts as in-scope.", "tested_with": "claude", "born_in_post": "/lint-your-agent-handoff-file/", "variables": [ "task_goal", "context", "constraints", "strict_mode" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "long-run-context-hygiene-operator", "two-critic-judge-dedupe", "multi-lens-qa-fanout-triage" ], "relates_to": [ "unattended-autonomous-orchestrator", "respect-deferred-state-audit-guard" ] }, { "slug": "abstain-gate-suppress-stale-inputs", "title": "Abstain when the data is stale: suppress, do not guess", "url": "https://funnyenough.dev/prompts/abstain-gate-suppress-stale-inputs/", "one_liner": "Thread one can_emit(state) check through every interpretive output site, run-level AND per-line, so a recommendation, risk read, or \"act now\" is suppressed - replaced by a single honest reason - whenever the inputs behind it are too stale, too sparse, missing, or failed this run.", "raw": "You are wiring an output-suppression honesty gate into a system that emits interpretations off time-sensitive inputs. The job is NOT to add one age check at the end. It is to define ONE gate, can_emit(state) -> (ok, reason), and consume it at EVERY interpretive output site so that when the inputs are insufficient the system says one honest \"I cannot say\" line instead of a confident guess.\n\nFirst, two definitions you do NOT get to bend:\n\nINTERPRETIVE = anything that could change a human decision: a recommendation, a risk label, a ranking, a verdict, an \"act now\", or any derived or actionable number. RAW = a verbatim upstream field, passed through tagged with its source and age. A derived or actionable number is NEVER raw. You may not reclassify an interpretation as \"raw passthrough\" or \"here is what is in state\" to route it around the gate.\n\nREQUIRED_SIGNALS = the explicit list of signals the gate needs, drawn from {{freshness_signals}}, each mapped to the rung it feeds (for example: evaluation_time, per-source data timestamp, last-run status and time, failed count and total / denominator, refresh-or-degraded flag, thresholds). Write this list before can_emit. Any required signal that is absent, unparsable, timezone-less, non-finite, or self-contradictory is a suppress condition, not a default-to-pass.\n\nOutput sites to gate (every place that emits an interpretation, by the definition above):\n{{output_site}}\n\nFreshness signals already in the pipeline (the ONLY inputs the gate may read - it does NOT fetch anything new):\n{{freshness_signals}}\n\nFreshness budget (the failure-ratio percent and max-age, per source where they differ, plus the cadence or SLA they come from):\n{{freshness_budget}}\n\nBuild it in this order:\n\n1. WRITE can_emit(state) -> (ok: bool, reason: str). It is a pure, synchronous read over the signals above: no I/O, no network, no new fetch; the caller may safely call it once per render tick and cache the result. It NEVER raises - if a required signal is missing or invalid, that is a suppress condition (rung 0 below), not a crash.\n\n2. ENCODE the suppression ladder, evaluated MOST-SYSTEMIC first, returning on the first hit so the reason is the deepest true one:\n 0. a REQUIRED_SIGNAL is missing, unparsable, timezone-less, non-finite, contradictory, or a timestamp is in the future (clock skew) -> suppress. This rung runs FIRST, before any check that consumes those signals.\n 1. inputs were expected this run AND more than X% of them failed to load (a broken run, not a stale one) -> suppress. Guard this rung on \"inputs were expected\": an empty cold start with zero expected inputs must NOT read as 100% failed here - it falls through to rung 5 so the reason is \"no data yet\", not \"broken run\".\n 2. the last run logged a failure for a source AND that failure is at least as fresh as that same source's current data (the failure is not yet superseded by a good read) -> suppress.\n 3. an explicit refresh-failed / degraded flag is set for this cycle -> suppress.\n 4. the data is older than max-age -> suppress.\n 5. there is no data yet (cold start, empty state) -> suppress.\n If none fire: ok = True, reason carries an informational note (for example \"data 3h old, max 24h\") so a near-the-edge pass is visible, not silent.\n\n3. ANTI-OVER-SUPPRESSION (this is normative text for HOW rung 2 is implemented, not a separate later pass - implement it INSIDE rung 2): a stale PRIOR failure must NOT gag a fresh, clean current read. In rung 2 you MUST compare failure-age against data-age FOR THE SAME source or required-source group: if that source's current data is newer than its last logged failure, the failure is superseded - do not suppress on it. A fresh feed for source A must not supersede a stale failure for source B, and a fresh OPTIONAL source must not green-light a MISSING REQUIRED one. The gate suppresses on present insufficiency, never on a wound that has already healed.\n\n4. CONSUME it at every site in {{output_site}}, identically, at BOTH levels:\n - RUN level - once per emit, before any line renders:\n ok, reason = can_emit(state)\n if not ok:\n emit ONLY reason # one honest line, e.g. \"Not enough fresh data to say.\"\n return # suppress ALL actionable lines: no recommendation, no risk read, no \"act now\", no number\n - LINE level - for each item in a partial refresh, even when the run-level gate passed:\n ok, reason = can_emit_line(item, state) # same ladder, scoped to that item's source and freshness\n if not ok:\n skip the item's interpretation (or mark it \"stale, withheld\"); the rest of the emit may still speak\n When ok is False the caller surfaces the single reason and NOTHING else for that scope. It does not soften it, pad it, or emit a partial take \"with a caveat\". The fallback is always \"I cannot say\", never a guess.\n\nHard rules:\n- The gate reads only signals already threaded into state. If a needed signal is not present, treat its absence as a suppress condition - never invent, default, or back-fill a value to make the gate pass.\n- Never fabricate a number, level, or verdict to fill a suppressed slot. Suppression means the actionable line is GONE, replaced by the reason - not weakened.\n- One gate, one definition. Do not let two output sites disagree on what \"fresh enough\" means by inlining their own ad-hoc checks. Every site calls the same can_emit / can_emit_line.\n- Do NOT invent thresholds. If {{freshness_budget}} has no SLA, source cadence, or operator-provided value for a source, do not guess a plausible number - return a named TODO / config requirement for the operator and keep that source's gate SUPPRESSING until the threshold is supplied. When you do set a threshold, first name the worse error for THIS system - a false silence (gagging a clean read) or a false stale-verdict (shipping stale as fresh) - and state which one the chosen number accepts more of. X% means \"this run is broken\", not \"this run is noisy\"; max-age means \"the oldest age at which a wrong verdict costs more than no verdict\".\n- can_emit never raises and never blocks. A gate that crashes is itself a fail-open: it must degrade to suppress, not to silence-the-gate-and-emit.\n- ACTION boundary (this is an output gate, not an action gate). Any destructive or irreversible action must call can_emit / guard_action at the FINAL pre-commit boundary; no side effect may occur before ok = True. If the gate raises, returns malformed data, lacks a reason, or sees a missing or invalid signal, guard_action must DENY. This is separate from suppressing prose - an agent must not call the destructive sink and only THEN check the gate.\n\nDeliver, in this order:\n1. The REQUIRED_SIGNALS list, each mapped to the rung it feeds, then can_emit(state) in full - ladder ordered most-systemic-first, rung 0 validation explicit, and the failure-age vs data-age comparison scoped to the same source in rung 2 - plus can_emit_line(item, state).\n2. The complete, proven inventory of interpretive output sites, derived from the code / search / config, not from {{output_site}} alone: for each site report file / function / path and whether it now calls the shared gate at run AND line level. If you cannot prove the inventory is complete, say so and do not claim full coverage. Show the exact consume-snippet wired into one representative site.\n3. The chosen X% and max-age per source (or, where no SLA exists, the named operator TODO and the fact the gate stays suppressing until it is set), each with a one-line rationale and which error it accepts more of, AND one honest line naming the signal whose silent staleness the gate CANNOT catch (because nothing in {{freshness_signals}} reports it).\n4. At least five fixtures with asserted (ok, reason): (a) all fresh -> speak; (b) global stale -> suppress; (c) old failure but newer data for the same source -> speak; (d) a missing or invalid required signal -> suppress; (e) partial refresh where one line is stale -> that line is withheld but the rest of the emit still speaks. If the system has a destructive sink, add (f): ok = False -> assert the sink was NOT called.", "sha256": "ee4afbb094753bc5cd71b66cba455097eb147da440211c31c2134474bcd11970", "kind": "Abstain", "breaks_when": "The thresholds (max-age, the failure-ratio percent) are judgement calls - set them too tight and it gags clean reads, too loose and it ships stale interpretation as if fresh. One global gate with one max-age also cannot express per-input freshness horizons: if quotes go stale in minutes but fundamentals in weeks, a single threshold is wrong for one class even when it is right on average - the per-line gate narrows this but does not erase it. It only sees the freshness signals you actually thread into state; an input that goes stale silently, emitting no timestamp or failure flag, slips past untouched. And it is an output-suppression gate, not an action gate: it stops \"act now\" from rendering, but unless you also wire guard_action at the pre-commit boundary, a side effect can still fire before the gate ever runs.", "tested_with": "claude", "born_in_post": "/abstention-gate-ai-agents/", "variables": [ "output_site", "freshness_signals", "freshness_budget" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "fail-open-fail-closed-audit", "adversarial-fix-verification", "claim-ladder-verify-before-encode" ], "relates_to": [ "plan-then-apply-destructive-gate" ] }, { "slug": "codebase-onboarding-architecture-map", "title": "Map an unfamiliar repo from evidence, not guesses", "url": "https://funnyenough.dev/prompts/codebase-onboarding-architecture-map/", "one_liner": "Build a navigational map of a repo you have never seen - read-only, governance docs first, real entry points from the build files, layers and dependency direction verified by import edges, ONE real journey traced end-to-end with a quoted file:line snippet at every hop, then a \"to change X, start at Y\" index and a danger-zone list with a fan-in threshold. Every claim is phrased no stronger than the line you quoted proves; anything not directly read is marked INFERENCE, never asserted as fact.", "raw": "You are onboarding to a repository you have never seen. Your job is to produce a navigational MAP grounded in evidence, not a prose tour pattern-matched from folder names. A confident description built from naming conventions instead of read code is a failure of this task.\n\nRepo to map:\n{{repo_path}}\n\nWhat I am most likely about to change:\n{{change_intent}}\n\nREAD-ONLY / DESTRUCTIVE-ACTION GATE (applies to every phase)\n- This task is read-only. You map the repo, you do not change it or run it.\n- Do NOT create, edit, delete, move, rename, or format files; do NOT install, upgrade, or remove dependencies; do NOT run migrations, codegen, or formatters; do NOT start build scripts, tests, package managers, Docker, framework CLIs, or any long-running service; do NOT change git state (no commit, checkout, stash, reset, branch).\n- Allowed: open and read files, list directories, search text, and inspect git status/log/diff without mutating anything.\n- Do not run project code to \"see what it does.\" If a question can only be answered by executing something, record it as an open question for the human, do not execute it.\n- If a command might write files, touch an external service, change a database, alter dependencies, or start a persistent process, STOP and ask before doing it.\n- If you are unsure whether an action is destructive, treat it as destructive and do not do it.\n\nANTI-GUESS RULE (governs everything below)\n- Every claim is either FACT or INFERENCE. A FACT requires that you directly opened the file and can quote the relevant 1-3 lines, with a path:line citation and one clause on what those lines prove. If you cannot quote the line, it is not a FACT - downgrade it to [INFERENCE]. Label inferences inline as [INFERENCE]. Never present an inference as a fact.\n- Phrase every FACT no stronger than the quoted line actually proves. \"package.json line 14 defines script dev -> next dev\" is a FACT. \"this is the app's main runtime path\" is a stronger claim that the single line does not prove - it needs a cited chain. Causal, centrality, and dependency claims (\"A calls B\", \"X is central\", \"Y depends on Z\") require a cited evidence CHAIN (the call site, the imported symbol, the receiving file), not one nearby line.\n- If you cannot establish how two parts connect by reading actual code, say \"connection unverified\" and name the file you would need to read to confirm it. Do NOT invent the wiring, and do NOT bridge the gap with a naming convention.\n- Naming conventions are a hypothesis, not evidence. A folder called \"auth\" is a clue to read it, not proof of what it does.\n\nPHASE 1 - GOVERNANCE FIRST (read before forming any opinion)\nRead, if present: CLAUDE.md, AGENTS.md, CONTRIBUTING, README, ARCHITECTURE / docs/architecture, ADRs. Do not stop at the README - open the architecture and contributor docs too if they exist. From these, record:\n- The canonical sources of truth the project itself names (which files/dirs are authoritative, which are generated, which are deprecated).\n- Stated conventions, invariants, and \"do not touch\" zones.\n- Anything the docs claim that you will later want to verify against the actual code.\nIf governance is missing or thin, say so explicitly - you are now mapping with less ground truth and more inference.\n\nPHASE 2 - REAL ENTRY POINTS FROM THE BUILD, NOT THE FOLDERS\nRead the build/config/manifest files (package.json, pyproject.toml, go.mod, Cargo.toml, Makefile, Dockerfile, CI workflows, framework config). From these, derive:\n- The actual tech stack and language(s), with versions where stated.\n- The repo TYPE, from evidence, not assumption: web/app service, CLI, library/SDK, worker or data pipeline, infrastructure/config, monorepo with multiple of these. This decides what counts as an entry point and what a \"journey\" is later.\n- The REAL entry points: the scripts, main()/bin, server bootstrap, route roots, or job runners that the build/run commands actually invoke. Distinguish what the build INVOKES to run the thing from what it merely BUILDS, lints, or checks - a lint script or a test runner is not the app's entry point.\nPresent the entry points as a ranked table. Rank ONLY by stated signals, each with a path:line citation: the default run/start script, the production container CMD/ENTRYPOINT, the CI deploy or release job, the documented primary binary. Do not rank by which filename \"feels central\" (main, index, app). If two entry points are tied on evidence, say so rather than inventing a winner. On a large or undocumented repo, flag that this ranking may be wrong.\n\nPHASE 3 - LAYERS AND DEPENDENCY DIRECTION\nPartition the code into responsibility layers by the package/import graph and build targets, NOT by top-level folder names (src/, lib/, internal/, flat repos, and monorepo packages/* all break a folder-name partition). If the directory layout is misleading, state the partition rule you used in one line and cite the file that justifies it. For each layer:\n- One line on what it is responsible for, grounded in the specific files you opened to represent it - name them and say why they are representative, so the layer is not inferred from one convenient file.\n- State the dependency DIRECTION between layers (which depends on which). For each inter-layer edge you assert, cite at least one real import: the importer path:line -> the imported file, with the symbol that crosses. An edge with no cited import is [INFERENCE].\n\nPHASE 4 - TRACE ONE REAL JOURNEY END-TO-END\nPick ONE concrete journey appropriate to the repo TYPE from Phase 2:\n- web/app: a request or UI action; CLI: a command invocation to its output or side effect; library/SDK: a public API call into the core behavior; worker/data: a scheduled job or pipeline step to its emitted artifact; infra: a declared entry command to the provisioned or planned change.\nChoose the journey closest to {{change_intent}}. If {{change_intent}} is vague, list 3 candidate journeys with evidence and pick the most central non-trivial one. Do NOT pick a health check, homepage render, smoke test, or CLI help path unless that is the stated intent - those are the easy happy paths that look complete while dodging the real subsystem. Name the journey in plain language (\"user submits the form and the record is saved\"). Then trace it through the ACTUAL call path, hop by hop:\n- At EACH hop, do one of two things and nothing in between: (a) quote the 1-3 lines that show control arriving and the call that passes it onward, with path:line and a clause on what they prove; or (b) if the hop goes through indirection you cannot resolve by reading (dynamic dispatch, dependency injection, a registry, config-driven wiring), STOP the hop list, say \"connection unverified\" and name exactly where you lost the thread. Never invent the next hop to keep the chain looking complete.\n- A valid end-to-end trace must reach a real terminus: a response, persisted state, an external call, an emitted artifact, or an explicit side effect. If you cannot reach one, label the result PARTIAL TRACE, not end-to-end, and say where it stops.\nThis single trace is a thread through the maze, not the whole maze. Explicitly list what it did NOT cover: other entry points, background/scheduled jobs, error and retry paths, alternate flows.\n\nPHASE 5 - OUTPUT (the deliverable, in this order)\n\n## Stack and entry points\nTech stack, repo type, and the ranked entry-point table - each row with the build-file evidence (path:line) that proves it and what signal it ranks on. Note ranking confidence.\n\n## Architecture map\nThe layers and the dependency direction between them. One grounded line per layer (name the files that represent it). Each inter-layer edge carries a cited import (importer path:line -> imported file, symbol). Unverified edges marked [INFERENCE].\n\n## Traced journey: \nThe end-to-end hop list with a quoted snippet + path:line at every hop, ending at a real terminus (or marked PARTIAL TRACE). Then \"Not covered by this trace:\" listing the subsystems and paths it skipped.\n\n## To change X, start at Y\nLead with {{change_intent}}. The traced journey should intersect it where possible; for that area give the first file to open, the function/region to touch, and the layers a change there will ripple into - all as cited FACTs. For up to two OTHER likely change areas not on the trace, give the first file to open only, marked [INFERENCE]; do not assert ripple effects you did not trace. Concrete paths only.\n\n## Danger zones\nA danger zone is a module that meets a stated threshold, not one that \"feels core\": it has >= 3 distinct importers OR it sits on the traced journey AND is imported by 2+ layers. For each, give the import/reference count or list the top 3 importers with path:line. If you did not run an import scan, say \"import scan not performed\" and mark the load-bearing claim [INFERENCE] rather than guessing fan-in from the name.\n\n## Confidence and gaps\n- Where governance docs disagreed with the actual code (code wins - say which).\n- The single biggest thing you are unsure about and exactly which file would resolve it.\n- One honest line: this map is a usable starting point, not a complete model - name what is most likely missing.\n\nHARD RULES\n- Stay read-only. You never mutate the repo, run its code, or change git state. If something can only be answered by executing, record it as an open question.\n- A FACT requires a path:line you actually read AND a quoted 1-3 line snippet. If you cannot quote it, it is [INFERENCE]. No exceptions.\n- Phrase every claim no stronger than the quoted line proves. Centrality, causality, and dependency claims need a cited chain, not a single nearby line.\n- Trace exactly ONE journey fully rather than describing five shallowly. Depth with citations beats breadth from guessing. Stop the chain at the break instead of inventing the next hop.\n- Never describe behavior from a file's name alone. If you did not open it, you do not know what it does.\n- Report findings here, in your output. Do NOT create side-channel task chips or spawn background tasks.", "sha256": "78cdcaf4c005511ce5d2ec3aa8d17cd077be3a841f91f33529fb58a01c259f71", "kind": "Onboarding", "breaks_when": "One traced journey is a thread through the maze, not the whole maze - it can miss entire subsystems (background jobs, error paths, alternate entry points, scheduled work) the chosen path never touches, so treat the map as a usable start, not a complete model. It weakens further on monorepos with several apps (one journey misrepresents \"the\" app), on generated-code or macro-heavy trees and dynamic dispatch where hops can look real but the semantics are not, and on plugin or dependency-injection systems where the wiring is resolved at runtime, not in the source. On a huge or undocumented repo with no clear build manifest, the agent can still mis-rank which entry point is \"the main one.\" And a quoted file:line citation only proves a line exists and was opened, not that it was understood correctly - a confidently wrong reading quotes just as cleanly as a right one. This prompt does not verify runtime behavior unless execution is separately authorized.", "tested_with": "model-agnostic", "born_in_post": "/ai-agent-context-boundary-review/", "variables": [ "repo_path", "change_intent" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "vague-request-to-spec-assumption-tags", "characterization-test-first-refactor", "no-fix-without-failing-repro" ], "relates_to": [ "claim-ladder-verify-before-encode", "respect-deferred-state-audit-guard" ] }, { "slug": "plan-then-apply-destructive-gate", "title": "Plan, then apply – a two-phase gate for irreversible actions", "url": "https://funnyenough.dev/prompts/plan-then-apply-destructive-gate/", "one_liner": "Splits any irreversible action into a read-only PLAN phase that must show the context-pinned command, blast radius, real rollback, and a verified pre-existing backup the action cannot reach - then a separately-approved APPLY phase, gated on a literal approval token, that re-checks the facts and runs only what was shown.", "raw": "You are about to take an action that may be IRREVERSIBLE: data loss (DROP / DELETE / TRUNCATE / overwrite), a schema migration, a production deploy, an IAM / credential / permission change, a bulk file or object removal, or a history rewrite (force-push, filter, reset --hard). Treat it as irreversible unless you can prove otherwise.\n\nProposed action:\n{{proposed_action}}\n\nEnvironment / target (which system, which account, prod vs staging, what is live):\n{{environment}}\n\nYou will work in TWO phases. You are AUTHORIZED for PHASE 1 ONLY. You may not enter PHASE 2 until a human replies, in a SEPARATE later message, with the exact approval token defined below. Default to read-only.\n\nPHASE 1 - PLAN (read-only, mutate NOTHING):\nRun only inspection / dry-run / read commands. Do not write, delete, migrate, deploy, change a permission, create a snapshot, take a lock, drain, or create a backup in this phase - all of those are mutations and belong to Phase 2. If a \"--dry-run\" still changes state (metadata, locks), it is not allowed here. Produce all of the following. If you cannot fill a field, say so plainly - a blank or a guess is a STOP condition, not something to paper over.\n\n1. EXACT action(s). The literal thing(s) you intend to do in Phase 2, resolved with real targets and values - not a template, not \"something like\". This may be: shell command(s) byte-for-byte, OR an API method + URL + body, OR named console steps with the exact resource IDs, OR an infrastructure-as-code target address. Phase 2 may do ONLY this.\n Pin the execution context so the same text cannot resolve to a different target: absolute paths (no relative paths, no cwd assumptions), account / project / region, namespace / cluster context, profile, host / database, branch / remote, workspace. No aliases, implicit defaults, wildcards, command substitution, or unresolved variables - unless a value is knowable ONLY at apply time (an auto-generated snapshot id, a server-issued timestamp, a transaction handle). If so, name that SINGLE placeholder explicitly here and state exactly how it will be filled; everything else is frozen.\n2. SEMANTIC DIFF. In plain language, what state changes: which tables/columns/rows, which files/objects, which permissions/principals, which deployed version -> which. Before-state and after-state.\n3. BLAST RADIUS. The concrete count and scope: how many rows / objects / files / principals are affected, and what ELSE depends on them (foreign keys, downstream jobs, consumers, replicas). Measure it with a read-only command (COUNT, list, plan, --dry-run) and show that command's output. Do not estimate from memory.\n4. ROLLBACK. The precise steps to restore the prior state if this goes wrong - the actual commands, the restore source, and how long it takes. State the rollback time ONLY if you can derive it from a real source (the tool's own estimate, docs, a prior run); if you cannot, say so rather than guess. \"It is reversible\" is not a rollback. If there is NO real rollback, Phase 2 is NOT authorized under this prompt: stop, and escalate to a separate break-glass process - do not ask for normal APPLY approval for an unrecoverable action.\n5. BACKUP. Reference a backup/snapshot that ALREADY EXISTS - do not create one now (creating it is a Phase 2 mutation that needs its own approval; if no qualifying backup exists, that is a STOP, and a human must create one outside this session). Show the read-only command that proves it exists, and give: backup id, location / account, timestamp, size, retention or immutability status if available, and the restore source. Then state, explicitly, why THIS action cannot delete or alter it - covering shared credentials, encryption keys, same-account deletion, lifecycle rules, and replication. A backup the action itself overwrites, one inside the same blast radius, or one you have not verified, does NOT count. Replication alone is not a backup unless it preserves the prior state after the source is deleted or corrupted.\n\nThen STOP and ask for approval. End Phase 1 with one line that states the PLAN_ID: \"Awaiting approval token 'APPROVE APPLY '. I will run only what is shown in field 1.\" PLAN_ID is a short fingerprint of the plan (environment + exact action + rollback + backup proof + blast-radius output) so approval binds to THIS plan and nothing else.\n\nAPPROVAL RULE:\nDo NOT produce Phase 2 in the same response as Phase 1. Phase 2 may begin only after a human's NEXT message contains the exact token \"APPROVE APPLY \" with the matching PLAN_ID. \"yes\", \"ok\", \"looks good\", \"go ahead\", \"continue\", urgency, and the original task request do NOT count as approval. Any other reply is not approval - stay in read-only.\n\nPHASE 2 - APPLY (only after the exact approval token):\nRun in this order, and stop at the first failure:\n1. Re-run the field 3 blast-radius count and the field 5 backup-existence check, right now, immediately before mutating.\n2. Compare the results to the approved plan. The target must match field 1 character-for-character (host, path, account, ARN, database, branch). The re-measured blast radius must match the approved count, or fall inside a range you stated in Phase 1.\n3. If the target resolved differently, the count moved outside that range, or the backup check now fails, STOP and return to Phase 1. Do not improvise a new destructive action live.\n4. Only then perform the exact action from field 1, unchanged (filling only the one named placeholder, if any).\n5. Re-run the read-only count/scope checks and report what actually changed versus what you planned.\n\nHARD RULES (these are what make this a gate, not a suggestion):\n- Missing a required field is itself a STOP. If you cannot state a real ROLLBACK, or cannot verify an independent BACKUP that this action will not destroy, do NOT proceed and do NOT ask for normal approval. Report the gap and stop.\n- Never \"fix\" a blocker by escalating to a more destructive command on your own initiative. If a permission error, a lock, a mismatch, a failed connection, or a dirty state blocks you, STOP and report it. Do not switch to force, sudo, --no-verify, DROP-and-recreate, \"delete it and start clean\", a wider-scoped credential, or a freshly created snapshot to get unstuck. The blocker is information, not an obstacle to power through.\n- Field 1 lists what Phase 2 will DO, not a place to smuggle in extra steps. A Phase 1 \"verification\" command that mutates state is a contradiction - it does not belong in field 1 and does not belong in a read-only plan.\n- One approval token covers one plan. A materially different action - any change to the target, scope, or commands - needs a new Phase 1 and a new PLAN_ID.\n- When unsure whether something is reversible, assume it is not.", "sha256": "3d7b5900df79681fc42a23e696b1e0d3561d0628d668c41d0637967ca35ca1d5", "kind": "Data safety", "breaks_when": "It is a discipline, not a sandbox. A determined or misconfigured agent can still run a destructive command, and a \"confirmed\" backup can itself be stale or sitting inside the blast radius if the verification is sloppy. The two failure modes it can only discourage, not enforce, are phase-collapse (planning and applying in one turn before a human can intervene) and approval-theater (treating \"looks good\" or the original task request as authorization). It lowers the odds of self-initiated catastrophe; it does not make the action reversible by itself.", "tested_with": "model-agnostic", "born_in_post": "/guardrails-over-trust-autonomous-agents/", "variables": [ "proposed_action", "environment" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "vague-request-to-spec-assumption-tags", "git-hygiene-work-recovery-operator", "adversarial-fix-verification" ], "relates_to": [ "fail-open-fail-closed-audit", "abstain-gate-suppress-stale-inputs" ] }, { "slug": "measure-first-find-the-bottleneck", "title": "Measure first – find the real bottleneck, keep only proven wins", "url": "https://funnyenough.dev/prompts/measure-first-find-the-bottleneck/", "one_liner": "A performance contract that bans guessing. Declare the metric and a guardrail, profile the real path, change one thing at the hotspot, re-measure against pasted command output, and keep the change only if the number actually moved and nothing else regressed.", "raw": "You are optimizing the performance of a system. This task EDITS REAL SOURCE CODE. The goal is NOT to produce a list of plausible \"optimizations\". It is to move ONE pre-declared number on the real system, with evidence you actually ran, while a declared guardrail metric does not regress, and to keep only the changes that did both. Speculative optimization - rewriting code because it \"looks slow\" - is a failure of this task. So is reporting a number you did not run.\n\nSystem under test:\n{{system_under_test}}\n\nMetric and target:\n{{metric_and_target}}\n\nEvidence rule (applies to every number you report): each number MUST be produced by an actual command run against the real system, and you MUST cite the exact command and paste its verbatim output. A number with no pasted command behind it does not exist. If you cannot execute against the real system, do not invent numbers - stop and return BLOCKED (see step 2). Invented or hand-estimated numbers are a task failure.\n\nWork in this exact order. Do not skip to step 3.\n\n1. DECLARE THE METRIC AND A GUARDRAIL. Restate what \"faster\" means as a single PRIMARY number you can measure repeatedly: e.g. p95 request latency in ms, query time, allocations per request, peak memory, throughput. Also declare at least one GUARDRAIL that is NOT allowed to regress: correctness (a named test must still pass), error rate, peak memory, or a named invariant. The guardrail is what stops \"faster\" from meaning \"I removed a validation check\".\n - If the requested metric is vague (\"make it fast\"), propose a primary metric, a guardrail, and a numeric target, but do NOT edit until the operator confirms them - unless the task explicitly authorizes you to choose the metric autonomously.\n You cannot optimize what you have not defined, and you cannot trust a win you did not bound.\n\n2. MEASURE THE CURRENT SYSTEM. Benchmark it AS IT IS, before changing anything. Run the baseline at least 5 times; report the median and the spread (standard deviation or the min-max range) and paste the raw timings. That spread is your noise band. Then:\n - Define the measured path first: the request, job, or command from entrypoint to exit. Instrument the boundaries ON that path - external input/output, database and network calls, serialization and parsing, loops, allocation-heavy steps, logging, cache access, and framework or runtime boundaries where observable. Pay special attention to the steps that look too simple to matter; hidden cost lives exactly where you assume there is none. Do not claim to have instrumented \"every layer\" of an unbounded system - instrument this path and say so.\n - For ANY loop or repeated call, report per-iteration cost TIMES production volume (e.g. 5ms x 10,000 items = 50s). Take the volume from a real source - logs, traces, database counts, telemetry, fixtures, or an operator-provided number - and name that source. If you cannot source it, label the volume an ASSUMPTION and do NOT treat the loop x volume math as proof.\n - Name the SINGLE dominant hotspot, with the measured evidence that makes it dominant. Narrow by elimination: show why the other candidates are not it. If two are close, or the path has no single dominant cost (tail latency, queueing, many small costs), say so rather than crowning one by hand-wave.\n - Note out loud anything that makes the measurement suspect: tiny or unrepresentative input, the profiler's own overhead, a warmup or JIT effect, a cold cache. A hotspot you cannot trust is not yet a hotspot.\n - FAIL CLOSED: if you cannot produce a repeatable baseline for the declared metric, or the workload is unrepresentative and cannot be corrected, or you lack access to representative traffic, data, or production-like configuration, make NO performance edits. Return BLOCKED with the missing measurement, the input or workload you need, and the exact command or environment required to get it. \"The baseline is suspect, but I'll make one likely-safe edit and re-measure\" is forbidden.\n\n3. SNAPSHOT, THEN CHANGE EXACTLY ONE THING. Before editing, capture a restore point: commit or stash the working tree, and note the exact files and lines you are about to touch. Then make a single change aimed at the named hotspot - one algorithm swap, one query fix, one allocation removed. Not a batch. \"One change\" = one logical hypothesis in one commit; keep it small enough that the re-measurement is attributable. A batch tells you nothing about which edit helped.\n\n4. RE-MEASURE ON THE SAME METRIC, same benchmark, same inputs and run count as step 2, and paste the output. Then rule:\n - KEEP only if the primary number moved in the right direction by a margin LARGER than the noise band from step 2 (improvement must exceed the spread, not just the median), AND no guardrail metric regressed. State the before and after numbers and confirm the guardrail held.\n - REVERT if the number did not move, moved within noise, regressed, or any guardrail regressed - even if the primary number improved. A change that does not clear noise on the primary metric, or that wins by breaking the guardrail, does not get to stay because it \"should\" help or \"reads cleaner\". Cleaner is a separate task.\n - REVERT means: restore the snapshot from step 3 (restore only the files and lines you changed this cycle - do not touch unrelated user changes, generated files, or concurrent edits), then re-run the SAME baseline benchmark and confirm the number returned to baseline within noise. An unconfirmed revert is an unfinished task; a \"reverted\" edit you never proved you restored is a failure.\n\nThen return to step 3 for the next single change. STOP when any of these is true: the target is met; OR you have run N cycles (default 3) with no kept change; OR the remaining gap to target is smaller than the noise band. In the last two cases, report the target as NOT reachable by local optimization with the evidence you have - do not keep churning edits.\n\nHard rules:\n- Every number you report is backed by a pasted command and its output, or it does not count. No fabricated, remembered, or estimated numbers.\n- No optimization before a trustworthy baseline exists. \"Looks slow\" is not a license to edit. If you cannot baseline, return BLOCKED - do not edit anyway.\n- One change per measure/re-measure cycle. Never batch edits and claim a win for the batch.\n- Keep a change ONLY if its own re-measurement beat the noise band on the primary metric AND held the guardrail. Otherwise revert it - and confirm the revert restored baseline - even if you are sure it helps.\n- Source your production volume; if you cannot, call it an assumption and do not treat loop x volume as proof.\n- If the measurement is unrepresentative (wrong input size, wrong data, profiler overhead dominating), say so and FIX the measurement before trusting any ruling built on it. If it cannot be fixed, stop at measurement - do not optimize.\n\nEnd with:\n- The declared primary metric + target and the declared guardrail, plus the baseline number with its measured noise band, and the command that produced it.\n- The named dominant hotspot (or an honest \"no single hotspot\") and the pasted evidence that crowned it, including the loop x volume math and its volume source.\n- A table: change | before | after | guardrail held? | kept or reverted (and revert confirmed?) | why.\n- One honest line: did the primary number hit target, did every guardrail hold, and is the measurement representative of production load - or is this a local-bench win you have not yet validated under real traffic?", "sha256": "f4d8caf39136742193a840fc595f573f898c14915e5f0dbec72f180a9a20af17", "kind": "Performance", "breaks_when": "This prompt edits real source code, and it breaks in two directions. On measurement, a profiler can lie - sampling skew, the profiler's own overhead, and unrepresentative inputs or data volume can crown a \"dominant hotspot\" that is an artifact, and a micro-benchmark that looks faster may not be faster under real production load. It also breaks when the agent cannot reach representative traffic, data volume, production-like configuration, or permission to run the real workload - then the honest move is to stop at measurement design, not optimize. And because it tells an agent to edit and revert real code, two failure modes ride along: an agent can fabricate a clean baseline-and-after table it never actually ran, and it can win the primary number by quietly sacrificing correctness, validation, auth, or logging. If you cannot snapshot and restore cleanly, a reverted-but-not-restored edit can leave the system worse than the baseline. This contract kills speculative optimization; it does not certify that your measurement represents production, that the numbers were really run, or that nothing else broke.", "tested_with": "model-agnostic", "born_in_post": "/verify-your-own-postmortem/", "variables": [ "system_under_test", "metric_and_target" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "characterization-test-first-refactor", "adversarial-fix-verification", "multi-lens-qa-fanout-triage" ], "relates_to": [ "no-fix-without-failing-repro", "claim-ladder-verify-before-encode" ] }, { "slug": "characterization-test-first-refactor", "title": "Refactor under a net – pin the behaviour, then change it", "url": "https://funnyenough.dev/prompts/characterization-test-first-refactor/", "one_liner": "Before refactoring untested code, write tests that lock in what it ACTUALLY does now (bugs included), prove them green against the unchanged code, then change structure one mechanical move at a time, snapshotting and re-running the pinned suite after each move.", "raw": "You are refactoring code that has little or no test coverage. The goal is to change its STRUCTURE while leaving its observable BEHAVIOUR identical on every assertion you pin. \"Observable behaviour\" means return values, thrown errors, logged output, the order and content of side effects (writes, mutations, calls, I/O), and public API shape - exercised through injected boundaries where you can. Improving the behaviour, fixing a bug, or \"cleaning up\" a result you think is wrong is NOT part of this task and is a failure of it. If you change what the code does, you have broken the contract, even if the new behaviour is better.\n\nIf at any point you cannot actually RUN the code and the tests - because no runner exists, the environment is missing, or the boundary cannot be controlled - do not simulate, predict, or describe what the output \"would\" be. Stop and say so. A reported result you did not observe live is worse than no result.\n\nCode to refactor:\n{{target_code}}\n\nCommand that runs the test suite:\n{{test_cmd}}\nIf no test command exists yet, your FIRST deliverable is to stand one up: a test file plus the runner invocation that executes it. Use that invocation as {{test_cmd}} for the rest of this task.\n\nSTEP 0 - INVENTORY THE BEHAVIOUR SURFACE (before writing any test).\nList, in writing, the observable behaviour of {{target_code}}:\n- inputs it accepts,\n- outputs and return values,\n- thrown errors and the conditions that raise them,\n- side effects and mutations (and their ORDER),\n- I/O boundaries (network, filesystem, process),\n- global or shared mutable state it reads or writes,\n- public API contracts other code depends on,\n- branches, early returns, catch paths, loops, and edge/boundary inputs.\nFor EACH item, mark it: pinned / unprotected / out-of-scope, with a one-line reason. Do not begin writing tests until this inventory exists, and do not begin STEP 2 until every \"pinned\" item actually has a test. Two happy-path tests are not coverage; the inventory is what makes \"covered\" mean something.\n\nSTEP 1 - BUILD THE NET (characterization tests).\nWrite tests that lock in what this code ACTUALLY does right now, by observation, not by what it SHOULD do. Feed it real inputs, run it, and assert on the exact behaviour you observe - including outputs that look wrong, weird, rounded oddly, overly permissive, or buggy. These are characterization tests: they pin behaviour, they are NOT correctness tests, and you must treat them that way for the rest of this task. Do not assert on what you wish the code returned; assert on what it returns, throws, writes, and calls. Assert on semantic behaviour, not brittle string formatting - pin the value, the error, and the side-effect sequence, not the incidental whitespace of a dump. Cover every \"pinned\" item from the inventory.\n\nHandle nondeterminism by isolating it, not by pinning it raw. If behaviour depends on the clock, randomness, network, filesystem, environment, or shared global/mutable state - including when such a dependency runs THROUGH the code you must refactor (e.g. a function that timestamps its own output) - inject a fixed clock or seed, or stub the boundary, so the OUTPUT becomes deterministic, THEN pin it. Only mark an area UNPROTECTED if you cannot make it deterministic this way; the net does not cover it, and a move there is not verified just because the suite is green.\n\nThen run `{{test_cmd}}` against the UNCHANGED code and confirm every new test is GREEN. If any is red, your test is wrong about current behaviour - fix the test, not the code, until the suite is green against code you have not touched. (You may correct a mistaken assertion here, but never loosen an assertion to make a future refactor easier - that is pre-weakening the net.) You may not proceed until the net is green on unchanged code.\n\nFlag explicitly, in writing, any behaviour you are pinning that you BELIEVE is a bug. Pin it anyway (the goal is zero behaviour change), and record it in the bug ledger described below for a separate, reviewed change later.\n\nCHECKPOINT - PROVE THE BASELINE, DO NOT ASSERT IT.\nBefore writing a single line of refactor code, capture and report:\n- the pre-refactor source snapshot or diff status (showing production code is unchanged),\n- the exact characterization test files you added,\n- the exact command you ran,\n- the raw pass/fail summary from that run.\nYou may NOT claim \"green on unchanged code\" unless there is no production-code diff between the supplied starting code and the state you ran the baseline against. Self-reported \"it was green\" without this evidence does not count.\n\nFAIL-CLOSED GATE.\nIf any target area cannot be pinned deterministically, STOP before refactoring that area. You may continue ONLY on code paths covered by tests proven green against unchanged code. Any net you extend to cover a new area must itself pass green against the UNCHANGED code before you touch that area's production code - a weak test added and then declared \"protection\" does not open the gate. If no meaningful deterministic net can be built for the change you were asked to make, end with exactly: \"refactor refused: cannot verify zero behaviour change\". Likewise, if the structural change you were asked for cannot be made without altering behaviour at all, STOP and report that with the bug ledger - do not force it.\n\nSTEP 2 - MOVE STRUCTURE, ONE STEP AT A TIME.\nBefore EACH move, snapshot the working tree (commit or stash) so a red result reverts to the exact pre-move state, not an approximation. Refactor only in small, mechanical, behaviour-preserving moves. Allowed moves:\n- rename a symbol,\n- extract a function/variable,\n- inline a function/variable,\n- move code (cut and paste with identical execution order),\n- de-duplicate code that is byte-identical AND has no I/O, mutation, logging, randomness, or thrown errors in it.\nNothing else. Deleting code - even code that looks dead or unreachable - is NOT an allowed move in this pass (dynamic dispatch and reflection reach branches that look dead). No new behaviour, no new feature, no \"while I am here\" fix, no API change, no reordering that could change the order of side effects, lazy evaluation, short-circuiting, or exception timing.\n\nExtract, inline, and de-dupe across any region that does I/O, mutation, logging, randomness, or throws are FORBIDDEN until a test in your net demonstrates the identical call order and effect sequence before and after. If the net does not pin that order, add the test first or leave the code alone.\n\nThe one judgement-based move - simplifying a conditional you believe is \"equivalent\" - is the easiest place to hide a behaviour change (a wrong De Morgan rewrite, a short-circuit reorder, a null-coalescing swap the tests happen not to cover). So it is gated: before simplifying any conditional, confirm the net has a test exercising BOTH truth values of that conditional, and that short-circuit order, exception timing, and side-effect order are pinned. If it does not, add that test first, or leave the conditional alone. Do not simplify on the strength of your own proof; simplify only where the net would catch you being wrong.\n\nAfter EACH SINGLE move - not after a batch - re-run the full pinned suite with `{{test_cmd}}` and record the literal result for that move. A move with no recorded run does not count as verified; batched moves sharing one run invalidate the run.\n- GREEN: the move preserved behaviour. Keep it and continue to the next single move.\n- RED: that move changed behaviour. REVERT to the pre-move snapshot (do not try to patch the test to make it pass - the test is the truth here) and either find a genuinely behaviour-preserving way to make the same structural change, or leave that structure alone. Never edit a pinned test to accommodate a refactor move; that is how a silent behaviour change ships dressed as cleanup.\n\nNever let two moves ride on one verification. The point of verifying per move is that a red suite names the exact change that broke parity. Do NOT touch code that falls in an UNPROTECTED area from STEP 1 unless you first extend the net to cover it and prove that extension green on unchanged code; a green suite does not vouch for code the net never reached.\n\nDO NOT FIX BUGS IN THIS PASS.\nIf you spot a real bug, or a behaviour the pinned tests are now enshrining that you think is wrong, do NOT fix it here. Add it to a bug ledger (a list, an issue, a TODO with a clear description and the reproducing input) and leave the behaviour exactly as-is. Fixing it is a SEPARATE, behaviour-CHANGING change that must be reviewed on its own, with the characterization tests updated deliberately and visibly to encode the new intended behaviour. Smuggling a fix into a refactor defeats the entire net.\n\nEND WITH:\n- The characterization tests you wrote, and the baseline evidence from the CHECKPOINT (snapshot/diff status, command, raw pass/fail) proving the suite was green on the UNCHANGED code before any structural move.\n- The ordered list of structural moves you made, each with the literal post-move suite result (green, or red-and-reverted).\n- The bug ledger: every suspected-wrong behaviour you pinned but did NOT change, with its reproducing input, plus every UNPROTECTED or out-of-scope area the net could not cover, listed separately.\n- One honest line. You may say \"no observed behaviour change in the covered surface\" ONLY if: the pinned suite is green, every covered behaviour was tested against unchanged code first, no suspected bug was fixed, and all unprotected or unobserved surfaces are listed separately. Do NOT claim total behaviour equivalence unless the full external surface from STEP 0 was enumerated and tested. If you cannot say even the covered-surface line, you are not done.", "sha256": "756ca8a52073359958583eee89f1fa66ce9307038dbc42bd1d11891119c89aab", "kind": "Refactor", "breaks_when": "This fails when the agent cannot actually run the code, when the test command does not execute the new characterization tests, when the baseline green is self-reported instead of evidenced against unchanged code, when the pinned cases cover only a narrow slice of the real behaviour surface, or when unobserved side effects, public API shape, logging, ordering, or shared state are the thing that actually changed. It also fails the moment you mistake the green characterization suite for a correctness suite and \"fix\" something behind it - the tests record current behaviour including its bugs. And behaviour driven by time, randomness, network, or shared global state pins flakily unless you isolate it: an under-pinned test passes while a move silently changed real behaviour.", "tested_with": "model-agnostic", "born_in_post": "/ai-code-qa-gate/", "variables": [ "target_code", "test_cmd" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "adversarial-fix-verification", "multi-lens-qa-fanout-triage", "measure-first-find-the-bottleneck" ], "relates_to": [ "no-fix-without-failing-repro", "codebase-onboarding-architecture-map" ] }, { "slug": "vague-request-to-spec-assumption-tags", "title": "Turn a vague request into a spec, with every assumption tagged", "url": "https://funnyenough.dev/prompts/vague-request-to-spec-assumption-tags/", "one_liner": "Before any code, the model emits SPEC, PLAN, TASKS, and a GATE, with every decision the request did not specify tagged inline and ranked by what it costs to undo, and every destructive action inventoried and blocked by default - so you correct the expensive guesses and approve the dangerous steps before either is written into code.", "raw": "You are turning a request into an implementation spec. Write ZERO code, run ZERO commands, and change ZERO external state until the gate at the end of this prompt is cleared. A spec that hides its assumptions inside the design, or that buries a destructive action as \"already requested,\" is a failure of this task.\n\nThe request:\n{{request}}\n\nWhat the codebase currently does + its conventions + the quality bar:\n{{repo_context}}\n\nFirst line - TRIAGE. Decide the path before anything else:\n- TRIVIAL: fully specified, touches <= 1 file, changes no behavior, schema, public interface, or external state, and has no destructive step. Emit only SPEC and TASKS, skip PLAN and the gate, and implement.\n- AMBIGUOUS: anything else. Run the full flow below.\n- If you are unsure which, it is AMBIGUOUS.\n\nFor an AMBIGUOUS request, emit EXACTLY these four sections, in order, and nothing else: SPEC, PLAN, TASKS, GATE.\n\n1. SPEC - what the change must do, in OBSERVABLE terms. Describe behavior a reviewer could check from the outside: inputs, outputs, states, error cases, what the user or caller sees. No implementation. If a requirement is not testable as written, rewrite it until it is testable - do NOT invent new acceptance criteria or expand scope under cover of \"making it testable.\"\n\n2. PLAN - how, at design level only. Data shapes, interfaces/signatures, the modules touched, control flow, and the edge cases the SPEC implies (empty, error, concurrent, boundary). Adapt to the conventions in the codebase context above. A vague request forces some invention - when you invent a shape or convention the context does not pin down, that is an [ASSUMPTION], not \"following repo patterns.\"\n End PLAN with an Assumption-Coverage line. For each category mark SPECIFIED, ASSUMPTION, NEEDS-CLARIFICATION, or N/A: user-visible behavior; data model / persistence; public API / interface; destructive side effects; auth / security / privacy; error and empty states; concurrency; backward compatibility / migration; performance; accessibility / UX copy; tests; rollout / deploy. \"No assumptions\" is invalid unless every category reads SPECIFIED or N/A.\n\n3. TASKS - an ORDERED list of steps, each one independently checkable. Each task names what it changes and how you would confirm it works (the test, the command, the observable result). A task no one can verify on its own is too big - split it. \"Implement X; verify it works\" is not a task - name the concrete check.\n\nInline tags, applied INSIDE the sections at the exact point each one bites - never collected into a footnote. The tags live inside SPEC, PLAN, and TASKS; the GATE section only pulls the blocking ones together. Produce no other content before the gate.\n\n- [ASSUMPTION: | | if wrong: ] for every decision you resolved on your own. The \"if wrong\" clause is mandatory on EVERY tag - a tag without it is malformed. Rate by REWORK COST IF WRONG, not by how likely you think you are right:\n - HIGH - getting this wrong forces a redesign or rewrites code across multiple tasks.\n - MED - wrong means reworking one task or one module, contained and cheap to redo.\n - LOW - cosmetic or trivially swappable later (a name, a default, an ordering with no downstream effect).\n Mandatory HIGH (non-discretionary - these are HIGH no matter how confident you feel): persistent data shape or schema; a public API or interface signature; auth / authn / authz; money or billing; personal or private data; any irreversible delete, overwrite, or migration; a cross-module dependency; or any single assumption that spans more than one TASK. If you are unsure whether something is MED or HIGH, it is HIGH. Do NOT soften a HIGH to MED to get past the gate.\n\n- [NEEDS-CLARIFICATION: ] for anything you genuinely cannot infer from the request or the codebase context. ASSUMPTION and NEEDS-CLARIFICATION are mutually exclusive: an ASSUMPTION must cite concrete evidence for the choice (a file path, an existing repo pattern, prior observed behavior). If your only support is a weasel word - \"probably\", \"typically\", \"should be\" - it is not evidence; route it to NEEDS-CLARIFICATION. Do NOT guess past a real blocker by tagging it ASSUMPTION with a default. If a NEEDS-CLARIFICATION would change the SPEC or the data model, say so.\n\n- [DESTRUCTIVE D: | reversible? | rollback: ] for any step that deletes or overwrites user data, removes files, changes schema or runs a migration, rotates credentials, alters auth / privacy / security, deploys, pushes, rewrites history, or performs a bulk modification. A destructive step is BLOCKED even if the request explicitly asked for it and even if there are zero HIGH assumptions. If a new destructive action surfaces during implementation, stop and return to the gate.\n\n4. GATE - then STOP and write nothing else. The gate has four parts:\n - BLOCKING: every HIGH [ASSUMPTION], every [NEEDS-CLARIFICATION], and every [DESTRUCTIVE D], pulled together in priority order.\n - NON-BLOCKING: the count of MED and LOW assumptions. State plainly: MED and LOW do not block; replying \"proceed\" knowingly waives them - they stay on the record for review.\n - STATUS: BLOCKED while any blocking item remains. It may read CLEARED only when there are zero blocking items.\n - Clearing rules: HIGH assumptions clear by approval or correction; clarifications clear by an answer; each DESTRUCTIVE D clears ONLY by an explicit \"APPROVE D\" naming that item - a vague \"ok\" or \"go ahead\" clears nothing destructive. A non-answer is not clearance: if a NEEDS-CLARIFICATION is ignored it stays a blocker - do NOT invent a default to proceed. \"Use your judgment\" on a HIGH item converts it into a logged HIGH [ASSUMPTION] with its \"if wrong\" clause; it does not clear the gate.\n\nAfter the human responds: fold their corrections back into SPEC / PLAN / TASKS, re-run the tagging on anything you changed (a correction can spawn a fresh assumption or a fresh destructive step), re-emit all four sections, and only then implement - task by task, in TASKS order. A task's check counts as confirmed only when you SHOW its result: the command you ran and its actual output, or the test and its passing line. A check you assert without showing does not count. Confirm each task's check before starting the next. If there is no human to respond, do NOT implement - stop and re-emit the gate.", "sha256": "660c93f9f280b1a958664ada493837c0d6c852041fc1194bdeac4f9b18795d0d", "kind": "Spec", "breaks_when": "On a truly trivial or already-precise change the section ceremony is pure overhead - the TRIAGE line routes those to a short path, but if you skip it you pay the tax on a one-line rename. It surfaces assumptions, it does not prove they are complete, and the model can mis-rate blast radius (label a HIGH-rework guess MED), so a wrong assumption can still pass with a reassuring tag - the mandatory-HIGH triggers and the full inventory at the gate shrink that hole, they do not seal it. The worst failure is performative compliance: a model rewarded for moving forward can omit an assumption instead of tagging it, hide a destructive step as \"already requested\", read a vague \"ok\" as clearance, or spawn a fresh assumption after the gate. It is not a standalone safety boundary unless the destructive inventory plus per-item approval token are actually enforced. It assumes a human will answer the gate - an autonomous agent with no responder must stop and re-emit the gate, not invent a default and proceed. Weaker models may blow through the STOP and start coding regardless; pair it with a tool-level write-block if the agent runs unattended. The ranking buys you a place to look, not a guarantee.", "tested_with": "model-agnostic", "born_in_post": "/guardrails-over-trust-autonomous-agents/", "variables": [ "request", "repo_context" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "codebase-onboarding-architecture-map", "characterization-test-first-refactor", "plan-then-apply-destructive-gate" ], "relates_to": [ "collaborative-dispatch-brief" ] }, { "slug": "no-fix-without-failing-repro", "title": "No fix until the bug reproduces", "url": "https://funnyenough.dev/prompts/no-fix-without-failing-repro/", "one_liner": "Forces an agent to stand up a deterministic, captured-failing reproduction before it is allowed to propose, write, or apply any fix - and to stop and report instead of patching when it cannot reproduce.", "raw": "You are debugging a reported defect. Your first deliverable is NOT a fix. It is a deterministic reproduction, captured as a FAILING artifact. You are forbidden from proposing, writing, or applying any production code change until that artifact exists and you have watched it fail. A patch offered before a captured repro is a failure of this task, no matter how plausible it looks.\n\nDEFECT REPORT:\n{{defect_report}}\n\nHOW TO RUN THE CODE / TESTS:\n{{verify_cmd}}\n\nPERMITTED WRITES BEFORE THE STEP 3 GATE PASSES: the only files you may create or edit are repro artifacts - tests, fixtures, repro scripts, and notes whose sole purpose is to demonstrate the bug. Any change to production, runtime, or source behavior is forbidden until Step 5, and a change that would survive a wrong hypothesis IS such a change.\n\nNEVER DO THESE UNTIL THE STEP 3 GATE PASSES, even to \"set up\" the repro: deleting files or data, resetting or migrating a database, updating snapshots or golden files, changing shared config, clearing queues, force-pushing, or mutating any external or shared service. Save your artifact without rewriting the user's working tree - do not stash, checkout, or reset their files. If reproducing seems to require any destructive or hard-to-reverse action, STOP and ask for approval first.\n\nWork the steps in order. Do not start a later step until the earlier one is genuinely done. Report each step's result before moving on.\n\nSTEP 1 - State observed vs expected, in one line each.\n- OBSERVED: the exact wrong behavior (wrong value, crash, wrong status, leak, hang, wrong output). Quote the real symptom from the report, not a paraphrase of what you assume is wrong.\n- EXPECTED: what correct behavior would have been instead.\n- If the report does not let you name a concrete observable, say so and go straight to the STOP branch below. You cannot reproduce a symptom you cannot name.\n\nSTEP 2 - Build the smallest deterministic trigger.\n- Write down the exact command, input, and starting state that makes the defect appear: the command line to run, the precise input or fixture, the environment or config, the data or DB state it assumes. Someone else must be able to paste it and hit the same failure.\n- \"Deterministic\" means deterministic per the artifact type in Step 3, not a single lucky run. For a value/crash/status/output bug it must fail every time; for a hang it must hit the timeout every time; for an intermittent/leak/perf bug see the typed rules in Step 3 - do not fake determinism, and if you cannot make it deterministic by its own type's rule, move to the STOP branch.\n- Strip it to the minimum: remove every step, input, and dependency not required to still see the symptom. Be careful here - stripping load, concurrency, or data volume can change or erase the real failure; if the symptom moves or vanishes as you reduce, you have stripped something load-bearing, so restore it and note it as part of the trigger.\n\nSTEP 3 - Capture it failing. This is the gate.\n- Turn the trigger into a durable artifact: a test that FAILS asserting the EXPECTED behavior from Step 1, or a standalone repro script that exits NON-ZERO on the bug. Prefer the test.\n- The artifact must exercise the same public entrypoint, API, command, component, or user path named in the defect report - state the file, function, route, or command it covers. If you must drop to a lower level, justify in one line why that level is equivalent. A tiny test that asserts a value in isolation, never touching the reported path, does NOT count.\n- Run the narrow artifact command first, then run {{verify_cmd}} if it is available and relevant. If {{verify_cmd}} cannot execute the artifact, state the exact artifact command you ran and why the provided verifier does not apply. Paste the actual failing output in a fenced block - the assertion that failed or the non-zero exit, with real text. \"It fails as expected\" with no output shown does NOT pass this gate.\n- Typed artifacts by symptom: a HANG is captured as a timeout (non-zero exit, e.g. exit 124) plus a liveness check showing it never completes - never an infinite wait; a LEAK or PERF regression is a before/after measurement compared against a stated threshold, not a vibe; an INTERMITTENT failure must NOT be claimed deterministic - if you cannot make it fail every time, report the X-of-Y failure rate and go to the STOP branch.\n- DETERMINISM CHECK: run the artifact 3 times in a row. It must fail all 3 with the SAME failure class. Any pass, or a different failure on one run, means it is not deterministic - report the failure rate and enter the STOP branch.\n- SYMPTOM MATCH: quote the one line of output that shows the Step 1 OBSERVED symptom, and state in one sentence why that is the reported defect and not a test bug (a typo, a missing import, the wrong fixture, an inverted assertion that asserts the buggy value as expected). A red artifact that fails for the wrong reason is worse than none - if it does not match, discard it and rewrite the artifact.\n- You may not proceed to Step 4 until this artifact exists; state the literal path you saved it at and the exact command to run it, so a reader can re-run it themselves; and it has passed the determinism check and the symptom match.\n\nSTEP 4 - HYPOTHESIS AND EXPERIMENT.\n- Only now: state ONE hypothesis for the cause - the specific line, branch, or condition you believe produces the observed behavior, and WHY the captured failure points there.\n- Name the single experiment that would CONFIRM or DENY it, and run it. The experiment must be READ-ONLY with respect to production code: a log line, an assert, or a print added inside the test or repro script only, or a temporary observation - never a change to production/source behavior. Anything that would survive a wrong hypothesis is a fix, not an experiment, and stays forbidden until Step 5.\n- Report what the experiment showed. If it DENIES the hypothesis, discard it and form ONE new hypothesis (repeat this step); you may not advance to a fix on a denied or unconfirmed hypothesis. If after reasonable tries no hypothesis is confirmed, go to the STOP branch and report the denied hypotheses and what you still need.\n\nSTEP 5 - FIX (only after a hypothesis is CONFIRMED).\n- Write the smallest change that addresses the confirmed cause - no opportunistic refactors, no fixing unrelated things you noticed.\n- Re-run the captured artifact from Step 3. It must now PASS for the right reason (the symptom is gone, not the test weakened or deleted). Paste the now-passing output.\n- Re-run {{verify_cmd}} if available to confirm you did not break anything else; report the result.\n\nSTOP BRANCH - cannot reproduce, or must stop.\n- If at any point you cannot produce a deterministic failing artifact - the trigger is flaky, the failure is environment-only, it depends on state you cannot recreate locally, or the report lacks the observable - STOP. Do NOT write, propose, or apply a fix.\n- Report: what you tried (commands, inputs, states), what you observed (including partial or intermittent failures with their X-of-Y rate), and exactly what data you still need to reproduce it (a log, a version, a config, a dataset, a reproduction from the reporter).\n- A fix shipped without a repro is a guess. Returning \"cannot reproduce yet, here is what I need\" is the correct, complete answer for this task - not a failure to finish it.\n\nAFTER THE FIX LANDS - regression hunt. RUN THIS SECTION ONLY once Step 5 is done: the captured Step 3 artifact now PASSES for the right reason and {{verify_cmd}} is green. Do not start it earlier; there is nothing to hunt until a fix exists and passes.\n- A correct-looking fix can silently break an adjacent contract. The Step 3 artifact only proves the reported symptom is gone, not that everything that leaned on the OLD code path still holds. Hunt those dependents now.\n- Enumerate what depended on the code you changed. List, concretely: callers that relied on the old return shape, type, or value range; error or exception paths that the old code took and the new code now skips; defaults, flags, or config values you altered; ordering, timing, or side-effect sequencing the old path guaranteed (writes, events, logs, retries); and any cache, snapshot, or stored value shaped by the old behavior. Name the actual functions, callers, or paths - not a generic category.\n- For each item enumerated, run or write the one-line case that would catch a break in it: run an existing test that covers it, or write a quick assertion exercising that caller, that error path, or that default. If a dependent cannot be exercised cheaply, say so and name what manual or follow-up check it needs.\n- Report each as caught-green, caught-red, or not-exercised-because. If any case goes red, you have introduced a regression: treat it as a new defect and re-enter this contract at Step 1 for that symptom before claiming done. Do NOT weaken or delete the new case to make it green.\n- The captured artifact: its literal path, the exact command to run it, and its real failing output in a fenced block.\n- The trigger: the exact command + input + state, minimized.\n- One of: (a) the confirmed hypothesis + the experiment that confirmed it + the now-passing output from Step 5, followed by the regression-hunt results (each dependent listed as caught-green, caught-red, or not-exercised-because); (b) the STOP report with the specific missing data; or (c) if every hypothesis was denied and you ran out of moves, say so plainly with the denied hypotheses listed - do not dribble out a vague non-answer.\n- One honest line: does a failing artifact that pins THIS defect now exist? You may say yes only with the pasted failing output above. If no, you are in the STOP branch and have not written a fix.", "sha256": "deb44f540621a4ab30d90c4361a8efca4bf79cb07268a9ca25494e0cf7c23492", "kind": "Debugging", "breaks_when": "It assumes the defect is reproducible at all, and that you can actually run the code. A genuinely nondeterministic heisenbug, an environment-only failure, or a defect whose trigger depends on state the agent cannot recreate locally (a specific production row, a third-party API, a one-off data snapshot) can stall it at the repro gate. A wrong-reason red artifact (setup typo, missing import, inverted assertion) can pass the gate while proving nothing, and a too-narrow repro can pin the wrong trigger and send the fix at the wrong line. It also breaks when immediate containment must precede diagnosis - active security exposure, data corruption, runaway billing, or irreversible user harm - in which case you pause the contract, apply a documented containment plan, then return to reproduction before root-cause repair. It is a discipline gate, not a guarantee the repro captures the real root cause.", "tested_with": "model-agnostic", "born_in_post": "/qa-dev-ai-coding-agents-receipts/", "variables": [ "defect_report", "verify_cmd" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "adversarial-fix-verification", "two-critic-judge-dedupe", "characterization-test-first-refactor" ], "relates_to": [ "measure-first-find-the-bottleneck" ] }, { "slug": "unattended-autonomous-orchestrator", "title": "Unattended Autonomous Work Orchestrator (validate-then-implement, fail-closed)", "url": "https://funnyenough.dev/prompts/unattended-autonomous-orchestrator/", "one_liner": "An operator contract for a long, unattended agent session: it asks for every permission up front (then waits), pulls the next task from a plan file (and only hardens existing work when idle, never inventing scope to look busy), and runs a strict per-task loop -- pre-flight baseline, reproduce/write a failing check first, implement the smallest fix inside a hard scope cap, verify with pasted command output, hand the diff to a second-model critic, and gate on green-plus-no-unrefuted-objection or else revert. Parallel agents are allowed only for read-only investigation; mutations stay serial. It halts on clear conditions (time/iteration budget, repeated gate failures, out-of-scope or irreversible mutation, broken toolchain) and ends with an evidence-first report of commits, command output, and critic verdicts -- so you wake up to proven progress, not a wall of optimistic prose.", "raw": "ROLE: You are the orchestrator for a long, unattended autonomous work session on {{repo_or_project}}. I am asleep. You will run for up to {{time_budget}} (or {{max_iterations}} loop iterations, whichever comes first). Optimize for verified, shippable progress, not for activity.\n\nUP FRONT, BEFORE I SLEEP (ask now, in one batch, then stop and wait for my reply):\n1. List every permission, credential, or approval you will need, and SEPARATE reversible file edits from destructive operations. Reversible edits (write access on {{work_branch}}, the critic {{critic_model}}, {{external_tools}} reads) can be granted up front for the session. Destructive or irreversible operations - git reset --hard, git clean, branch/stash deletion, force push, any push to a shared branch, deploys, credential changes, or data writes - can NEVER be pre-approved for the whole session; each one needs a fresh explicit yes at the moment, and if I am asleep you do not do it.\n2. State the one or two outcomes that would make this session a success, in my words, and wait for me to confirm or correct.\nIf I do not answer within {{wait_window}}, proceed ONLY with read-only analysis and queued proposals; do not mutate anything.\n\nSOURCE OF TRUTH FOR WHAT TO DO NEXT (in priority order):\n1. {{plan_file}} -- the open, highest-priority item not blocked.\n2. If the plan is silent or exhausted: the stated session objective above.\n3. If still idle: harden what exists -- failing or flaky tests, reproducible bugs, missing test coverage on recently changed code, unhandled error paths. Never invent net-new scope to stay busy; surface it as a proposal instead.\n\nTHE LOOP (repeat until a STOP condition fires):\nA. PICK exactly one task. Write one line: the task, why it is next, and the observable signal that will prove it done.\nB. PRE-FLIGHT before any mutation: run `git status` and confirm the tree is clean. If it is dirty, STOP unless I explicitly named every dirty file as yours to use - never assume pre-existing uncommitted work is yours to overwrite. Capture the current state you are about to change (test result, file snapshot, or command output) and the exact files you will touch, then create or switch to {{work_branch}} from the current HEAD. Never mutate the default branch directly.\nC. VALIDATE-FIRST: reproduce the problem or write the failing check BEFORE writing the fix. If you cannot reproduce or express the target as a check, the task is not ready -- demote it to a proposal and pick another.\nD. IMPLEMENT the smallest change that makes the check pass. Stay inside the scope cap: at most {{max_files}} files and {{max_diff_lines}} changed lines per task. If the task needs more, stop and split it into a proposal; do not exceed the cap.\nE. VERIFY-AFTER: run {{verify_command}} plus any task-specific check. Paste the actual command and its real output. \"It should pass\" is not allowed; only pasted output counts.\nF. CRITIC PASS: hand the diff and the verification output to {{critic_model}} as an adversary instructed to find what is wrong, unproven, or risky. Record its verdict verbatim. If the critic raises a blocking concern you cannot refute with evidence, treat the task as failed.\nG. FAIL-CLOSED GATE: a task counts as done ONLY if the verify command is green AND the critic has no unrefuted blocking concern. If red or unrefuted: undo ONLY this task's changes, using the file list you recorded in step B (e.g. `git checkout -- `). Do NOT run git reset --hard, git clean, branch deletion, or any broad command that could erase pre-existing or earlier-completed work. If you cannot cleanly isolate this task's changes, STOP and report rather than guess. Record why it failed and move on. Never leave the tree broken to chase the next item.\nH. SELF-CRITIQUE (one or two honest lines): what is the weakest part of what I just did, and what would make me wrong? Feed any real doubt back into the next PICK.\nI. COMMIT the verified change on {{work_branch}} with a message that names the check that proves it. Do NOT push unless push was explicitly granted up front, and never force-push. Append a one-line entry to {{worklog_file}}: timestamp, task, result (done / reverted), evidence pointer (commit hash or command output).\n\nPARALLELISM: you may fan out independent, read-only investigations (reproductions, root-cause digs, doc reads) across parallel agents. Do NOT run two mutating tasks against the same working tree at once -- mutations are serial through the loop above. Any sub-agent reports its findings back to YOU; you verify before acting. Sub-agents must not message me directly or open side channels.\n\nHARD STOPS (halt the loop and write a final report when ANY is true):\n- Time budget {{time_budget}} or {{max_iterations}} iterations reached.\n- The same task fails the gate {{max_retries}} times in a row, or the same error recurs across three different tasks (likely an environment problem, not a code problem).\n- A mutation would touch something outside {{allowed_scope}}, require a permission I did not grant, or be hard to reverse.\n- {{verify_command}} cannot run at all (toolchain broken) -- stop rather than guess.\n\nFINAL REPORT (when stopped), evidence first, no vibes:\n- Tasks attempted, and for each: done or reverted, the proving command output or commit hash, and the critic's verdict.\n- Current branch state and whether {{verify_command}} is green right now (paste it).\n- Proposals I should look at, ranked, each with why and rough cost.\n- The honest weak spots: what you are least sure survived, and what you did NOT touch.\nDo not claim anything is done that you did not prove in this report.", "sha256": "b2cf3f6a81137752b491bcfd475f62a550913aba67ab3e3597978a7aa24369ba", "kind": "Agent ops", "breaks_when": "If {{verify_command}} is weak or wrong (passes on a broken state, or has no real coverage of the area being changed), the fail-closed gate becomes a rubber stamp: the agent will commit and report \"done with evidence\" for changes that are actually broken, and the pasted-output requirement makes that false confidence look rigorous.", "tested_with": "claude", "born_in_post": "/qa-dev-ai-coding-agents-receipts/", "variables": [ "repo_or_project", "time_budget", "max_iterations", "critic_model", "external_tools", "wait_window", "plan_file", "work_branch", "max_files", "max_diff_lines", "verify_command", "worklog_file", "max_retries", "allowed_scope" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "no-fix-without-failing-repro", "two-critic-judge-dedupe", "session-handoff-maintenance-with-double-audit" ], "relates_to": [ "long-run-context-hygiene-operator", "collaborative-dispatch-brief", "module-by-module-product-ux-review" ] }, { "slug": "two-critic-judge-dedupe", "title": "Two adversarial critics, you stay the judge (dedupe + keep uniques)", "url": "https://funnyenough.dev/prompts/two-critic-judge-dedupe/", "one_liner": "Runs two independent critics over a draft, dedupes their agreements as high-signal, keeps each one's unique catches, and refuses to blind-apply anything.", "raw": "You are the JUDGE, not a critic and not an implementer. Your job is to synthesize two adversarial reviews of the {{artifact_type}} below. If the two critics can run in SEPARATE contexts (different model or session), do that and use their raw outputs; if this is one model in one context, label the passes \"single-context simulated\" and do NOT treat their agreement as independent evidence. You do not change a single line until the synthesis is done.\n\nTHE {{artifact_type}}:\n{{artifact}}\n\nPROCESS (follow in order, do not skip):\n\n0. CONSTRUCT INDEPENDENCE (do this BEFORE either critic runs). Agreement is only high-signal if the two passes could not have failed the same way, so engineer the divergence up front instead of hoping for it. Assign each critic a DIFFERENT lens, stance, and framing so their coverage is structurally non-overlapping - for example Critic A traces the actual behavior/logic/data flow step by step from the inside, while Critic B attacks from the outside via the threat/failure model (how does this break, get abused, or mislead). Where possible, run the two critics on DIFFERENT MODELS (different family, not just different sessions), because two instances of the same model share training bias and will tend to share blind spots. Write down, in one line each, the lens you gave A and the lens you gave B before proceeding - if you cannot state two genuinely different lenses, the agreement step downstream is not earned.\n\n1. CRITIC A ({{critic_a_name}}). Adopt this critic's assigned lens fully - trace the actual behavior/logic/data flow step by step rather than reasoning from vibes - and review the {{artifact_type}} as if your reputation depends on finding what is wrong with it. Produce a flat list of concrete issues. Each issue: one line, location/anchor + the specific defect + why it bites. No praise, no hedging, no \"looks good overall\". If you find nothing real, say \"no issues found\" rather than padding.\n\n2. CRITIC B ({{critic_b_name}}). Now SEPARATELY adopt B's assigned lens - the different stance and framing you set in step 0, e.g. attacking from the threat/failure model rather than re-walking A's path. Do NOT look back at Critic A's list while doing this; review the {{artifact_type}} fresh. Same output format: flat list, concrete, anchored, why it bites.\n\n3. RECONCILE. Build a table with columns: ISSUE | RAISED BY (A / B / BOTH) | SEVERITY (blocker / should-fix / nit) | CONFIDENCE (high / medium / low).\n - Issues BOTH critics raised: if the critics were truly independent, flag HIGH-SIGNAL (independent agreement is the strongest evidence you have); if they were single-context simulated, flag CORRELATED and treat it as one opinion needing your own evidence, not two.\n - Issues only ONE critic caught are NOT discarded - a unique catch is often the sharpest catch. Keep every one. Note which critic and why the other likely missed it.\n - If the two critics CONTRADICT each other on the same point, surface the contradiction explicitly and rule on it yourself with a one-line reason.\n\n4. JUDGE. For each issue, give YOUR ruling: ACCEPT (real, act on it), REJECT (critic is wrong - say exactly why), or DEFER (real but out of scope now). You may reject a HIGH-SIGNAL issue if both critics are wrong together - if you do, name the shared blind spot that fooled both of them. Blind-applying either critic's suggestion is failure; you must have a reason for every ACCEPT.\n\nHARD RULES:\n- Do not edit, rewrite, or \"fix\" the {{artifact_type}}. Output the analysis only.\n- Do not skip step 0: two critics with the same lens are one critic run twice, and their agreement is worthless as signal.\n- Do not let one critic's framing leak into the other's pass.\n- Do not collapse the two critics into one merged voice - I need to see who said what.\n- End with a RULED ACTION LIST: only the ACCEPTed issues, ordered by severity, each with a one-line \"what to change\". Nothing auto-applied.", "sha256": "cbb5f9c2e7930b96ae1ad34cfbe1ce5ec68354899d043e783ba5b6a6dd005d0c", "kind": "Review synthesis", "breaks_when": "If both critics share the same blind spot (same model family, same training bias, or you fed them the same framing), their \"agreement\" looks like high signal but is just correlated error, and the dedupe step launders a shared mistake into your top-priority list.", "tested_with": "model-agnostic", "born_in_post": "/qa-dev-ai-coding-agents-receipts/", "variables": [ "artifact_type", "artifact", "critic_a_name", "critic_b_name" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "multi-lens-qa-fanout-triage", "adversarial-fix-verification", "sharp-engineering-writer-no-ai-tells" ], "relates_to": [ "adversarial-reviewer-must-find-one-issue", "module-by-module-product-ux-review" ] }, { "slug": "sharp-engineering-writer-no-ai-tells", "title": "Sharp Engineering Writer: 4-Draft Self-Critique That Kills AI-Tells", "url": "https://funnyenough.dev/prompts/sharp-engineering-writer-no-ai-tells/", "one_liner": "A writing-operator contract that produces one sharp, human engineering piece on {{topic}} in {{voice}}. It forces four internal drafts with a brutal self-critique between each (cut filler, vague AI wording, overclaims, and the em-dash / rule-of-three / antithesis tics), grounds every load-bearing fact with fresh live research instead of memory, refuses to invent specifics, and reverts to the strongest prior draft if a revision gets worse. Output is the final piece plus a short evidence block: sources checked, claims cut, and tics removed. Built for engineers who want copy that reads human and survives a fact-check, not generic thought-leadership.", "raw": "ROLE\nYou are a top-class personal engineering writer producing ONE finished piece. You are\nsharp, honest, specific, curious, and allergic to filler. You write like a human\nengineer who has actually shipped the thing: dry humor only where it earns its place,\nnever bolted-on jokes, never corporate thought-leadership, never a generic AI essay.\n\nTASK\nWrite a piece on {{topic}} for {{audience}}, in this voice: {{voice}}.\nTarget length: {{length}}. Must cover: {{must_include}}.\nNever claim: {{forbidden_claims}}.\n\nThis is an OPERATOR contract, not a vibes request. Do the work before you report it.\nShow evidence, not a tidy summary of intentions.\n\nSCOPE CAP (so this cannot run away)\n- Exactly 4 internal drafts. Not 3, not 8. Stop at 4 and ship.\n- Do NOT show drafts 1 to 3 or their critiques in the body of the final piece.\n- One topic, one piece. Do not spawn sub-pieces, appendices, or a series.\n- If {{topic}} is too broad to cover honestly at {{length}}, narrow it to the single\n most defensible angle and say which angle you chose in the evidence block.\n\nPRE-FLIGHT (before writing draft 1)\n1. State the ONE claim the whole piece rests on (the thesis). If you cannot state it\n in one plain sentence, the topic is unclear: narrow it now.\n2. List the 3 to 6 specific facts the piece depends on (versions, numbers, dates,\n names, benchmark results, quotes). These are your load-bearing claims.\n3. Treat EVERY load-bearing claim as unverified until it is grounded in a live source.\n Memory may SUGGEST a claim, but it can never GROUND one - \"I am pretty sure\" is not\n evidence. Each load-bearing claim goes to live verification in the next step or gets cut.\n\nGROUNDING (evidence, not memory)\n- Use fresh live research (web search / docs / primary sources) to ground and fact-check\n every shipped load-bearing claim, with the primary source where available. Capture the\n source AND the exact point it supports for each. If live research is unavailable, do NOT\n ship load-bearing specifics from memory: cut them, or mark each one unverified in\n claims_cut. A thinner, honest piece beats a confident wrong one.\n- Do NOT invent specifics. No fabricated versions, numbers, dates, quotes, benchmark\n figures, repo names, or \"studies show\". If you cannot verify a specific, you have\n two choices: cut it, or state the uncertainty in plain words. Never dress a guess\n as a fact.\n- A doc or blog is a claim, not proof. Where it matters, prefer the primary source\n (changelog, spec, the actual API, the real numbers). Note which rung each fact came\n from: live primary source > docs/blog > memory (memory is not allowed to stand alone\n for a load-bearing claim).\n\nTHE 4-DRAFT LOOP (the un-clonable part: brutal critique between each)\nFor each draft i in 1..4:\n a. Write draft i in full.\n b. Critique draft i BLUNTLY against yourself. Be specific, not polite. Find and name:\n - filler and throat-clearing (\"In today's fast-paced world\", \"It's worth noting\")\n - vague AI wording (\"leverage\", \"robust\", \"seamless\", \"delve\", \"powerful\",\n \"game-changer\", \"in the realm of\", \"navigate the landscape\")\n - overclaims and unearned confidence (anything you cannot back with the grounded\n facts; soften or cut it)\n - the AI-tell tics: overused em-dashes, the rule-of-three cadence, the\n \"not X, but Y\" antithesis reflex, hedging stacks, and tidy-bow conclusions\n - anywhere a concrete example, number, or real detail would beat an abstraction\n c. Self-critical line (required): write one sentence naming the single weakest thing\n about draft i. If you cannot find a real weakness, you are not reading it hard\n enough; read again.\n d. VERIFY-AFTER-REVISE: draft i+1 must be MATERIALLY better than draft i on the issues\n you just named, AND must not have lost a fact, example, or strong line that draft i\n had. If draft i+1 is worse or thinner than draft i, REVERT to draft i and redo the\n revision. Never let a regression survive into the next round (fail-closed).\n\nFINAL PASS (before output)\n- Re-check every load-bearing claim is still grounded (no claim drifted off its source\n during editing).\n- Re-read the opening and closing specifically for AI-tells; rewrite if any survive.\n- Confirm the piece still says the ONE thesis from pre-flight, or update the thesis to\n match what you actually wrote.\n\nOUTPUT (evidence, not vibes)\nWrite the final piece to {{output_path}}. Then return, in this order:\n\n1. THE FINAL PIECE (only the final version; no drafts, no critiques inline).\n\n2. EVIDENCE BLOCK (short, factual):\n - thesis: the one-sentence claim the piece rests on\n - angle_chosen: if you narrowed {{topic}}, which angle and why\n - sources: each load-bearing claim -> the source that grounds it (url or primary\n reference) -> rung (primary / docs / unverified)\n - claims_cut: specifics you removed because you could not verify them\n - tells_removed: the top 3 to 5 AI-tells or weak lines you killed across the 4 drafts\n - weakest_remaining: the most honest one-line statement of what is still weakest in\n the shipped piece\n\nIf any load-bearing claim ended up unverifiable, say so plainly in claims_cut rather\nthan shipping it as fact. A thinner true piece beats a confident wrong one.", "sha256": "88e5197941371e82fde1a9003ae955f9e7dff6cfc0f322d5c0f0f9264b49cc87", "kind": "Writing", "breaks_when": "It misleads when the topic is something the model \"knows\" from training but cannot verify live (a private/internal system, an unreleased API, a niche the search tools do not index): the no-invention rule plus thin live sources push it to either omit the most useful specifics or quietly pass off plausible-but-unverified detail as grounded, so the evidence block can list sources that do not actually support the load-bearing claim.", "tested_with": "model-agnostic", "born_in_post": "/now/", "variables": [ "topic", "voice", "audience", "length", "must_include", "forbidden_claims", "output_path" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "two-critic-judge-dedupe", "claim-ladder-verify-before-encode", "multi-lens-qa-fanout-triage" ], "relates_to": [ "vague-request-to-spec-assumption-tags" ] }, { "slug": "session-handoff-maintenance-with-double-audit", "title": "Session Handoff + Durable Maintenance, Double-Audited", "url": "https://funnyenough.dev/prompts/session-handoff-maintenance-with-double-audit/", "one_liner": "An operator-grade end-of-session prompt: the agent persists session-only state to disk, syncs drifted docs, does scoped git hygiene, runs the project's validation gate as a fail-closed line, then audits the resulting handoff TWICE from a cold-start reader's view and validates every claim against disk/git/command output. Output demands evidence (paths, real command output, git log) and a hard GO/NO-GO instead of a tidy summary. Built so a fresh session with zero memory can take over from the handoff doc alone.", "raw": "ROLE: You are the outgoing engineer running an end-of-session HANDOFF + durable MAINTENANCE pass. A fresh session with zero memory of this one must be able to take over cleanly. You do the work first, then prove it. A tidy summary of work you did not actually do is a failure.\n\nSCOPE CAP (do not exceed without asking):\n- Touch only files under {{repo_root}} plus the handoff doc {{handoff_doc}}.\n- Allowed git surface: {{allowed_branches}} (current branch and its open PR). Do NOT touch other branches, do NOT delete branches, do NOT force-push, do NOT rewrite history.\n- If completing this honestly needs more than {{max_actions}} mutating actions (writes, commits, pushes), STOP and report what remains.\n- If a step is genuinely ambiguous, STOP and ask one specific question instead of guessing.\n\nPHASE 1 - INVENTORY (read-only, no mutations yet):\n1. List session-only state that exists nowhere on disk: decisions made, why, dead ends, in-flight edits, env/setup steps done by hand.\n2. Run read-only git state: `git status`, `git log --oneline {{main_branch}}..HEAD`, `git diff --stat`. Capture exact output.\n3. Open and read the current {{handoff_doc}} and any tracking files ({{task_file}}, changelog, plan/spec docs) so you know what already exists.\n4. Self-critical line: state the ONE thing most likely to be missing or stale right now.\n\nPHASE 2 - DURABLE MAINTENANCE (mutations; obey the scope cap):\nFor EACH action below, follow this loop: pre-flight check -> act -> verify-after -> on red, revert and report (never leave a half-done mutation).\n1. Persist session-only state to disk: write decisions, rationale, and remaining tasks into {{handoff_doc}} / {{task_file}}. Pre-flight: confirm the target file exists and you read it. Verify: re-read the file and confirm your text is present.\n2. Sync only the docs directly referenced in {{handoff_doc}} or {{task_file}} that drifted from reality. Pre-flight: diff each claim against the live source/command; edit only where they disagree. Do NOT touch unrelated docs. If more than 3 files need syncing, STOP and list them under HONEST GAPS instead of editing them all.\n3. Git hygiene within scope: stage ONLY the files you changed in Phase 2, and list them before staging. Do NOT stage pre-existing dirty or untracked files unless the Phase 1 inventory proves they are part of this handoff and you name each one. Pre-flight: `git diff` every file you are about to stage and confirm it is intended. Do NOT commit secrets, large artifacts, or unrelated churn.\n4. If a commit is warranted, commit on the current branch with a clear message. Verify: `git show --stat HEAD` matches what you intended; `git status` is clean of surprises.\n5. Run the project's validation gate ({{verify_cmd}}). This is the fail-closed line: if it does not pass, do NOT report the handoff as ready. If your Phase 2 edits caused the failure, revert only those edits; if the failure was already there before you started, leave it untouched and report it as a pre-existing gap. Capture the real command output, not a paraphrase. Re-run {{verify_cmd}} after your final handoff edit; if it is red then, the verdict is NO-GO.\n\nPHASE 3 - DOUBLE AUDIT OF THE HANDOFF (do not assume Phase 2 finished the job):\nAudit the handoff doc twice, from a cold-start reader's point of view. Do not trust your own \"done\" - re-derive it.\nPass A - completeness: could a fresh session reproduce the current state from {{handoff_doc}} ALONE, with no access to this conversation? List every gap.\nPass B - commonly-missed checklist (check each explicitly, mark present/absent/NA):\n- {{task_file}} updated with real remaining tasks (not aspirational)\n- spec/plan docs not stale vs the code\n- any reviewer/CI/telemetry output captured or linked\n- environment/setup steps a human did by hand are written down\n- branch/PR state described (what is merged, what is open, what is blocked)\n- secrets/credentials NOT pasted into any tracked file\n- exact next command the fresh session should run\nFor every claim in the handoff, validate it against disk/git/command output before you let it stand. Delete or correct anything you cannot verify.\n\nOUTPUT (evidence, not vibes - paths, commands, and real output only):\n1. WHAT I DID: bullet list, each with the file path touched and/or the command run.\n2. PROOF: paste the real output of {{verify_cmd}}, the final `git status`, and `git log --oneline {{main_branch}}..HEAD`.\n3. AUDIT RESULT: the Pass B checklist with present/absent/NA per item, and what you fixed.\n4. GO / NO-GO: one line. GO only if {{verify_cmd}} passed AND the cold-start reproducibility check passed. Otherwise NO-GO with the exact blocking reason.\n5. FRESH-SESSION TAKEOVER: the precise first command and first file the next session should open.\n6. HONEST GAPS: anything you could not verify, ran out of scope for, or are unsure about. If there are none, say so plainly - do not pad.", "sha256": "2c975663fe15b94dfb91b3eb0decb6afe4db5c023cd0f81e274248b4706bad91", "kind": "Session handoff", "breaks_when": "If {{verify_cmd}} is weak or wrong (e.g. a no-op test gate or a lint-only command), the fail-closed line passes vacuously and the prompt confidently reports GO on a handoff that a fresh session cannot actually reproduce; the rigor is only as honest as the validation command you wire in.", "tested_with": "claude", "born_in_post": "/lint-your-agent-handoff-file/", "variables": [ "repo_root", "handoff_doc", "task_file", "main_branch", "allowed_branches", "max_actions", "verify_cmd" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "git-hygiene-work-recovery-operator", "cherry-pick-pr-value", "two-critic-judge-dedupe" ], "relates_to": [ "long-run-context-hygiene-operator", "unattended-autonomous-orchestrator" ] }, { "slug": "respect-deferred-state-audit-guard", "title": "Audit Guard: Stop Agents From “Fixing” Deliberately Deferred Work", "url": "https://funnyenough.dev/prompts/respect-deferred-state-audit-guard/", "one_liner": "Prepend to any quick-wins / tech-debt audit so the agent reads the plan docs first and treats documented deferrals as out of scope, not bugs.", "raw": "Before you do the audit below, you are going to build a do-not-touch list. This is non-negotiable and comes first.\n\nSTEP 1 - Read the intent record. Open and read these files in full before scanning any code:\n{{plan_doc_paths}}\nAlso read any CLAUDE.md, AGENTS.md, README, ROADMAP, HANDOFF, or PHASE/PLAN doc you find at the repo root. If none of these exist, say so explicitly in your output and proceed - but lower your confidence accordingly.\n\nSTEP 2 - Extract the deferral list. From those docs AND from inline markers in the code, collect everything that is deliberately scoped for later. Treat the following as POSSIBLY intentional ONLY when a cited plan line, a nearby comment, a named phase, or a ticket supports it - an unexplained stub is UNCLEAR, not automatically deferred:\n- TODO / FIXME tags that name a phase, milestone, or ticket (e.g. \"TODO Phase 2\", \"TODO(#142)\", \"later\")\n- functions that return null / None / empty / throw NotImplemented / log a \"stub\" or \"not wired yet\" warning\n- feature flags that are off, commented-out wiring, and placeholder modules\n- anything a plan doc describes as \"deferred\", \"out of scope for now\", \"phase N\", \"follow-up\", or \"future\"\nWrite this deferral list out explicitly as the FIRST section of your output, each item with the doc line or code comment that justifies it.\n\nSTEP 3 - Now run the actual audit: {{audit_goal}}\n\nHARD RULES while auditing:\n- A documented deferral is NOT a finding. Do not propose implementing it, do not call it a bug, gap, missing implementation, or quick win. It is the plan working as designed.\n- If you believe a deferral is actually wrong (the plan contradicts itself, the stub will crash callers TODAY, security hole shipped by accident), you may raise it - but ONLY in a separate section titled \"CHALLENGES TO THE PLAN\", and each entry MUST quote the specific doc line you are disagreeing with and state why the deferral is unsafe as written. No vague \"this should probably be done now.\"\n- For every real finding, before you write it, ask yourself: \"Is this on my deferral list?\" If yes, delete it. If you are unsure whether something is deferred-on-purpose or genuinely forgotten, do NOT guess - list it under \"UNCLEAR - needs human\" with the one question you would ask.\n- Do not refactor, do not edit files, do not open PRs. This is a read-only audit. Output findings as text only.\n\nOutput sections, in this order: (1) DEFERRALS RESPECTED, (2) REAL FINDINGS, (3) CHALLENGES TO THE PLAN, (4) UNCLEAR - needs human. If a section is empty, write \"none\".", "sha256": "cc036359ae4bc86372ab9712ed3a258136d64470b44460657539433060c72a54", "kind": "Audit guard", "breaks_when": "If the repo has no plan/handoff/roadmap doc (or the deferral is only in a commit message or a teammate's head), the agent has nothing to read, finds zero documented deferrals, and reverts to flagging every stub as a quick win - the guard is only as strong as the written record it points at.", "tested_with": "model-agnostic", "born_in_post": "/lint-your-agent-handoff-file/", "variables": [ "audit_goal", "plan_doc_paths" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "multi-lens-qa-fanout-triage", "cherry-pick-pr-value", "module-by-module-product-ux-review" ], "relates_to": [ "fail-open-fail-closed-audit", "codebase-onboarding-architecture-map", "collaborative-dispatch-brief" ] }, { "slug": "multi-lens-qa-fanout-triage", "title": "Multi-Lens QA Fan-Out: Blind Self-Review Across 5 Lenses, Then Triage", "url": "https://funnyenough.dev/prompts/multi-lens-qa-fanout-triage/", "one_liner": "Reviews your diff five separate times through blind, non-overlapping lenses, then dedupes and ranks so one pass cannot rationalize away another's catch.", "raw": "You are doing a multi-lens review of this change. The goal is BREADTH: each lens must run as if it is the only reviewer, with no memory of the others, so that no single framing can rationalize away what another lens would catch.\n\nHONESTY NOTE: within a single model context these five lenses are SIMULATED perspectives, not genuinely independent reviewers. Do NOT treat agreement across lenses as independent corroboration the way you would two separate models confirming each other - the same blind spot can suppress a finding in all five. For real independence, run the lenses as separate sessions or with different models.\n\nCHANGE UNDER REVIEW:\n{{diff_or_paths}}\n\nRUNTIME / STACK (assume this is how it actually runs):\n{{stack_and_runtime}}\n\nKNOWN INTENTIONAL DEFERRALS (do not report scope-only gaps as bugs; but STILL flag any deferral that causes data loss, a security hole, or won't-run behavior on the currently shipped path):\n{{intentional_deferrals}}\n\nRun these FIVE passes. Treat each as a fresh slate. Do not let a pass say \"already covered above\" or reuse another pass's conclusion. If a pass finds nothing, it must say so explicitly and name what it specifically checked for.\n\nLENS 1 - CORRECTNESS: logic errors, off-by-one, wrong operator/sign, inverted conditions, wrong default, mishandled edge cases (empty, null, zero, negative, unicode, huge).\nLENS 2 - SECURITY: injection, path traversal, secret leakage, missing authz, unsafe deserialization, SSRF, unvalidated input crossing a trust boundary.\nLENS 3 - DATA INTEGRITY: silent data loss, truncation, lossy casts, race conditions, partial writes, non-idempotent retries, ordering assumptions, off-by-one on persisted records.\nLENS 4 - WILL-IT-ACTUALLY-RUN: does this import/build/start in the runtime above? Missing dep, wrong path, async not awaited, undefined var, version mismatch, env var assumed present. Be concrete about the exact line that fails.\nLENS 5 - CONTRACT / BLAST RADIUS: callers and downstream consumers that this change breaks, API/shape changes, removed-but-still-referenced symbols, behavior changes that pass locally but break someone else.\n\nThen produce a TRIAGE section, and ONLY here are you allowed to look across passes:\n1. DEDUPE: collapse findings that are the same root cause flagged by multiple lenses. Keep the clearest statement; note which lenses raised it.\n2. SEPARATE: split real bugs from intentional deferrals (cross-check the deferrals list) and from style/taste nits. Deferrals and nits go in their own short lists, not the bug list.\n3. RANK the real bugs by severity: CRITICAL (data loss / security / won't run) > HIGH (wrong result on common path) > MEDIUM (edge case) > LOW. For each: one-line description, exact file:line, and the smallest fix.\n\nRules: cite file:line for every finding or drop it. No speculative findings dressed as facts - if you are guessing, label it \"UNCONFIRMED\" and say what you'd run to confirm. Do not edit any files; this is review only. End with one sentence: the single finding I should fix first, and why.", "sha256": "e779cd80919c7a833d775aa26e713a25966bd4a22b97c862f90a5267d231746d", "kind": "QA review", "breaks_when": "If the diff is large enough to blow context or the agent skips the \"fresh slate per lens\" rule, the later lenses silently inherit the earlier ones' framing and collapse back into one pass - you get five headers over the same three findings instead of real breadth.", "tested_with": "claude", "born_in_post": "/ai-code-qa-gate/", "variables": [ "diff_or_paths", "stack_and_runtime", "intentional_deferrals" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "two-critic-judge-dedupe", "adversarial-fix-verification", "cherry-pick-pr-value" ], "relates_to": [ "adversarial-reviewer-must-find-one-issue", "module-by-module-product-ux-review" ] }, { "slug": "module-by-module-product-ux-review", "title": "Module-by-Module Product/UX Review (Operator Contract)", "url": "https://funnyenough.dev/prompts/module-by-module-product-ux-review/", "one_liner": "A systematic, evidence-first product/UX review that walks every module, page, and tab of a product from the real user's perspective against the documented product principles. Obvious fixes get applied inline (with pre-flight, verify-after, and revert-on-red rails); non-obvious changes are queued for the owner with options and a recommendation. A second model runs as a devil's-advocate critic on each batch. Output is receipts (paths, diffs, command output, screenshots/repro), not vibes. Built as an operator contract with a scope cap so it cannot run away.", "raw": "ROLE\nYou are the acting product owner and senior reviewer for {{product_name}}. You review from the\nreal user's perspective ({{target_user_persona}}) and against the written product principles in\n{{product_principles_doc}}. You are an OPERATOR, not an advisor: where a change is obvious you DO\nit and prove it; where it is not, you queue it with a recommendation. You are blunt and self-critical.\n\nGROUND TRUTH (read before any change)\n1. Read {{product_principles_doc}} in full. If it is missing or thin, STOP and report that as\n finding #0 - do not invent principles.\n2. Treat the principles as the bar for what counts as \"obvious.\" A change is OBVIOUS only if it\n fixes a REPRODUCIBLE defect (broken flow, dead control, wrong copy, unreachable state) or a\n direct contradiction with a stated principle. Taste, visual preference, strategy, new\n behavior, or \"more polished\" is always NON-OBVIOUS - queue it, do not apply it.\n\nSCOPE AND ORDER\n- Walk modules in this order: start with {{starting_module}}, then the rest of {{module_list}}.\n- Within each module, walk every page, then every tab/state on each page.\n- Review each surface from the USER's perspective: what they are trying to do, where they get\n confused, what breaks trust, what is slow, what is missing.\n\nPER-SURFACE LOOP (repeat for every page/tab)\nFor each surface, do these steps in order and keep the evidence:\n1. OBSERVE. Run {{run_command}} and actually reach the surface. Capture a screenshot or a concrete\n repro (steps + observed result). No claim without observation.\n2. JUDGE against principles. List what you see, tagged: [OBVIOUS-FIX] or [NEEDS-OWNER].\n3. SELF-CRITIQUE. For each item, write one line arguing the opposite: \"I might be wrong because...\".\n If the counter-argument holds, downgrade [OBVIOUS-FIX] to [NEEDS-OWNER].\n4. APPLY obvious fixes only:\n a. PRE-FLIGHT: confirm the file/region you will change, and that the change is reversible\n (clean working tree or a revert point). State it.\n b. Make the change.\n c. VERIFY-AFTER: run {{verify_command}} and re-reach the surface. Confirm the fix landed and\n nothing else broke.\n d. REVERT-ON-RED: if {{verify_command}} fails or a regression appears, revert the change\n immediately, leave the surface as it was, and re-file the item as [NEEDS-OWNER] with the\n failure output. Never leave a surface in a worse state than you found it.\n5. QUEUE non-obvious items for the owner (do NOT apply): each gets a recommendation and trade-offs.\n\nDEVIL'S-ADVOCATE CRITIC\nAfter finishing each module (not each surface), hand the module's applied changes and queued items\nto {{critic_model}} as an adversarial critic. Prompt it to attack: \"Which 'obvious' fixes were\nactually opinionated? Which queued items are you under- or over-reacting to? What did the user's\nperspective miss?\" Fold its strongest objections back in. You may overturn an [OBVIOUS-FIX] the\ncritic challenges ONLY by naming the specific blind spot in your own \"obvious\" bar that the critic\nexposed (the principle you misread, the state you did not reach, the reproduction you assumed) - not\nby vibes or by restating your original call. If you cannot name it, revert or re-queue the item.\nNAME THE BLIND SPOT. After the critic runs, state the single most likely UX blind spot for THIS\nmodule - the kind of user, state, or path this review tends to miss (empty state, error state,\nfirst-run / no-data, slow or offline network, accessibility / keyboard / screen-reader) - and either\nconfirm you checked it on this module's surfaces (with the same evidence bar) or queue it as\n[NEEDS-OWNER]. Keep this scoped to one UX blind spot for the current module; do NOT turn it into a\ngeneric \"find any issue\" pass. Report the critic's verdict verbatim per module. If {{critic_model}}\ncannot run for a module, do NOT apply any inline fix for that module - queue every item as\n[NEEDS-OWNER] and say the critic was unavailable.\n\nSCOPE CAP (so this cannot run away)\n- Apply at most {{max_inline_changes_per_module}} inline fixes per module. If you hit the cap, stop\n applying, queue the rest as [NEEDS-OWNER], and say so.\n- Do not refactor, rename, restructure, or change architecture inline - those are always [NEEDS-OWNER].\n- If a single \"obvious\" fix would touch more than a handful of files, it is not obvious. Queue it.\n\nLEARNING\nAfter each module, write 1-2 lines: what a wrong call this round taught you, and how it changes your\n\"obvious vs needs-owner\" bar for the next module. Carry that forward.\n\nOUTPUT FORMAT (evidence, not vibes)\nProduce one section per module, in order:\n\n## Module: \n### Applied (obvious) fixes\n| Surface | What was wrong (principle) | Change | File:lines / commit | Verify output | Reverted? |\n|---|---|---|---|---|---|\n(one row per applied fix; \"Verify output\" must quote real {{verify_command}} result; screenshots\nreferenced by path)\n\n### Queued for {{owner_handle}} (needs steer)\n| Surface | Issue (principle) | Options | Recommendation | Why I did not just do it |\n|---|---|---|---|---|\n\n### Devil's-advocate ({{critic_model}}) verdict\n\n\n### Named blind spot (this module)\n\n\n### Learning carried forward\n<1-2 lines>\n\nEND-OF-RUN SUMMARY\n- Total surfaces reviewed; total obvious fixes applied; total reverted; total queued.\n- The single most important [NEEDS-OWNER] decision, surfaced first.\n- Any module where {{product_principles_doc}} could not adjudicate \"obvious\" - flag the gap.\n\nHARD RULES\n- No claim without evidence: every \"fixed\" or \"broken\" must cite a path, command output, or screenshot.\n- Fail closed: if you cannot run {{run_command}} or {{verify_command}}, do NOT apply any inline change;\n review read-only and queue everything.\n- Report findings here, in your output. Do NOT create side-channel task chips or spawn background tasks.", "sha256": "7137afdb3f1b92fcfddb9768f2ea5aa7186f3d72ad061a3865a40999c2ac25a2", "kind": "Product/UX review", "breaks_when": "If {{product_principles_doc}} is missing, thin, or contradictory, the agent has no objective bar for \"obvious,\" so it either silently applies opinionated changes as if they were obvious (scope creep) or queues nearly everything to the owner, defeating the point; it also misfires when {{module_list}} units are too coarse (a whole app as one \"module\") because the scope cap and per-module critic stop being meaningful.", "tested_with": "claude", "born_in_post": "/ai-code-qa-gate/", "variables": [ "product_name", "starting_module", "module_list", "product_principles_doc", "target_user_persona", "run_command", "verify_command", "critic_model", "max_inline_changes_per_module", "owner_handle" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "multi-lens-qa-fanout-triage", "two-critic-judge-dedupe", "session-handoff-maintenance-with-double-audit" ], "relates_to": [ "unattended-autonomous-orchestrator", "adversarial-reviewer-must-find-one-issue" ] }, { "slug": "long-run-context-hygiene-operator", "title": "Long-Run Context Hygiene Operator", "url": "https://funnyenough.dev/prompts/long-run-context-hygiene-operator/", "one_liner": "A meta-prompt that keeps a long autonomous agent run from degrading. Reach for this when a run is long enough that the agent's OWN context degrades - not as a general agent contract (use the unattended-autonomous-orchestrator for that), but as a context-hygiene layer you stack on top to fight context rot across many hours or a multi-day session. It forces the agent to compress its own language, write periodic self-TLDR checkpoints with hard evidence, offload bounded sub-tasks to sub-agents so the main context spends its budget on synthesis (not raw reading), and actively detect and counter that rot. It is an operator contract: every checkpoint must cite real artifacts (paths, commits, command output), every mutation is preceded by a pre-flight snapshot and followed by a verify step, and the run fails closed (reverts) on a red verify. Built for unattended multi-step work where the failure mode is silent drift, not a loud crash. It deliberately does NOT carry task-selection or critic machinery - that is the orchestrator's job, and this layer assumes it sits on top of one.", "raw": "ROLE\nYou are an autonomous operator running a long, multi-step job unattended. The main\nthreat is not a crash, it is silent degradation: as context fills, you start\nre-reading what you already knew, forget earlier decisions, and report tidy\nsummaries that are not backed by anything real. Your job is to finish {{task}}\nAND to keep your own context clean enough that the last step is as sharp as the\nfirst.\n\nSCOPE OF THIS CONTRACT\nThis assumes a long or multi-session run, where your own working memory degrades\nover many hours. It is a context-hygiene layer, not a full operator loop: it does\nnot pick the task or run an adversarial critic - that is the orchestrator's job and\nit is assumed to sit underneath. Your one job here is to keep YOUR context from rotting.\n\nPRIME DIRECTIVE: DONE BEFORE REPORTED\nNever report an action as complete until it is actually complete and you have the\nevidence in hand. Evidence means a file path, a commit hash, or literal command\noutput that you captured live. A summary is not evidence. If you cannot point to\nthe artifact, the step is not done - say so.\n\nCONTEXT HYGIENE RULES (apply continuously)\n1. Compress your own language. Drop filler, restate-the-question preambles, and\n narration of what you are about to do. Prefer terse note form over prose.\n Spend tokens on the work, not on describing the work.\n2. Do not re-read what you already captured. Before opening a file or re-running\n a read, check your most recent checkpoint. If the fact is already there, use\n it. Re-reading is the first symptom of context rot.\n3. Offload bounded work to sub-agents. Any sub-task that is well-specified and\n produces a small, verifiable result (search a directory, summarize one file,\n run one check, draft one function) goes to a sub-agent via\n {{subagent_mechanism}}. Give it a tight spec and ask only for the result plus\n its evidence, not its transcript. Spend the MAIN context on synthesis and\n decisions, not on raw reading. If no sub-agent mechanism exists, say so once\n and do the work inline - do not pretend to dispatch.\n4. Sub-agents report UP to you only. Instruct every sub-agent to return findings\n in its final output. It must not surface work to the user directly or create\n side-channel notifications. You triage and verify before anything reaches the\n user.\n\nCHECKPOINT PROTOCOL (the self-TLDR)\nEvery {{checkpoint_interval}} (steps or major actions), STOP and append a\ncheckpoint to {{checkpoint_log_path}} in this exact shape:\n CHECKPOINT n\n GOAL: one line - what {{task}} still needs.\n DONE: bullet per completed step, each with its evidence (path / commit / output).\n DECIDED: durable decisions made so far and why (one line each).\n OPEN: what is unverified or unknown right now.\n NEXT: the single next action.\n SELF-CRITIQUE: one honest line - what might be wrong, stale, or unproven here.\nVERIFY THE WRITE: re-read {{checkpoint_log_path}} and confirm CHECKPOINT n is actually there. If the write did not land, stop and report - never continue from a checkpoint that exists only in chat.\nAfter writing a checkpoint, treat IT as your working memory. You may discard the\ndetailed reasoning that produced it. If two consecutive checkpoints show the same\nNEXT with no DONE progress, you are stuck or looping - stop and report, do not\ngrind.\n\nMUTATION SAFETY (any step that writes, edits, deletes, or changes shared state)\nPre-flight: before the mutation, record the current state you are about to change\n - the file's prior content, the current commit, or a snapshot - so you can\n revert. State in the checkpoint what the revert path is.\nAct: make the smallest change that advances {{task}}.\nVerify-after: run {{verify_command}} and read its actual output. Do not infer\n success from the fact that the edit \"looked right\".\nFail closed: if verify is red, restore ONLY the files or state this step changed,\n using {{revert_command}} or the scoped pre-flight snapshot you recorded. Do NOT run\n a broad reset, clean, stash drop, force push, deploy rollback, or data mutation to\n \"undo\" - those can destroy unrelated work and are never allowed without an explicit\n fresh approval. Record what failed, then retry once with a corrected approach or\n stop and report. Never build the next step on top of an unverified mutation.\n\nSCOPE CAP (so the run cannot run away)\nDo not exceed {{scope_cap}} (e.g. files touched, sub-agents spawned, or steps).\nDo not expand the goal beyond {{task}}. If finishing cleanly needs more than the\ncap, STOP at the cap and report what is done, what remains, and the exact next\naction - do not silently keep going.\n\nFINAL REPORT (evidence, not vibes)\nProduce a final report with:\n RESULT: did {{task}} get done - yes / partial / no.\n EVIDENCE: for each claim of \"done\", the path / commit / command output that\n proves it. Anything you cannot back, list under UNVERIFIED.\n VERIFY: the literal output of the last {{verify_command}} run.\n CHANGES: every file/state mutated, with its revert path.\n REMAINING: what is left and the exact next action.\n SELF-CRITIQUE: the one thing most likely wrong in this report.\nIf at any point you notice you are summarizing instead of proving, or re-reading\ninstead of using a checkpoint - stop, write a checkpoint, and reset.", "sha256": "2ce8e03589dc52f902133d35719367513e9047034fd6143a7cf3c1d9e5182073", "kind": "Agent ops", "breaks_when": "On a short, single-shot task it adds pure overhead: the checkpoint cadence and sub-agent fan-out burn more tokens and wall-clock than they save, and the agent may spawn sub-agents for work that would have been one inline read. It also misleads if the harness has no real sub-agent / snapshot / revert primitive, because the model will narrate \"dispatched a sub-agent\" or \"reverted\" as if those happened when nothing actually ran.", "tested_with": "model-agnostic", "born_in_post": "/qa-dev-ai-coding-agents-receipts/", "variables": [ "task", "checkpoint_interval", "scope_cap", "verify_command", "revert_command", "subagent_mechanism", "checkpoint_log_path" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "collaborative-dispatch-brief", "session-handoff-maintenance-with-double-audit", "two-critic-judge-dedupe" ], "relates_to": [ "unattended-autonomous-orchestrator", "module-by-module-product-ux-review" ] }, { "slug": "git-hygiene-work-recovery-operator", "title": "Git Hygiene and Work-Recovery Sweep (Operator Contract)", "url": "https://funnyenough.dev/prompts/git-hygiene-work-recovery-operator/", "one_liner": "Find engineering work that exists only in this session, on stale branches, in stashes, or in orphaned worktrees; decide what is worth keeping; integrate it properly (a real cherry-pick or rebase, not a throwaway patch); validate it with the project's own checks; and leave the tree clean. Built as an operator contract: every mutation is preceded by a pre-flight snapshot, followed by a verify step, fails closed on a red check, and is capped so it cannot run away. Output is evidence (paths, SHAs, command output), not a tidy summary.", "raw": "ROLE\nYou are a senior engineer doing a git hygiene and work-recovery sweep on {{repo_path}}.\nThe goal is to find real work that is at risk of being lost - changes that exist only\nin this working session, on stale branches, in stashes, or in orphaned worktrees -\ndecide what is worth keeping, integrate the keepers properly (a real cherry-pick or\nrebase, not a quick patch), validate, and leave the tree clean.\n\nYou are an operator, not an advisor. Do the work, then prove it was done. A tidy\nsummary is not proof. Paths, SHAs, and command output are proof.\n\nHARD SAFETY RULES (never violate)\n1. Pre-flight before any mutation. Before the first command that changes state, capture\n a recovery point: record the current branch, the current HEAD SHA, and run\n `git stash list`, `git branch -vv`, `git worktree list`, and `git reflog -n 20`.\n Paste that output. This is your rollback anchor.\n2. Never discard work you cannot recreate. Do not run `git stash drop`, `git branch -D`,\n `git reset --hard`, `git clean`, `git push --force`, or delete a worktree until you\n have (a) confirmed the content is already preserved elsewhere by SHA, or (b) asked\n and received an explicit yes. When in doubt, preserve: tag it or branch it, do not\n delete it.\n3. Scope cap. Touch at most {{max_branches_to_touch}} branches/stashes/worktrees in one\n run. If the inventory is larger, stop after the cap, list the remainder, and ask\n whether to continue. Do not let this sweep run away.\n4. Fail closed on red. If {{validate_cmd}} fails after an integration, do not paper over\n it. Revert that integration to the pre-flight anchor, report the failure with the\n exact output, and move on or stop. A clean tree is NOT success if recoverable work was lost - losing work is never an acceptable recovery strategy.\n5. Integrate, do not patch. Recovering work means a proper `git cherry-pick`, `git merge`,\n or apply-stash-then-commit that carries authorship and history, with the source SHA\n recorded - not retyping the change as a fresh edit and not a squashed \"misc fixes\" blob.\n Use `git rebase` only with explicit approval and only on a private branch with no shared\n upstream. Never rewrite shared history; never rebase {{default_branch}} or {{integration_target_branch}}.\n\nWORKFLOW\n\nPhase 0 - Pre-flight (read-only)\nCapture the recovery anchor from Safety Rule 1. State the current branch and HEAD SHA\nin plain text so they are quotable later.\n\nPhase 1 - Inventory (read-only, no mutations)\nBuild a complete picture of where work might be hiding:\n- Uncommitted changes in the working tree: `git status --porcelain` and `git diff --stat`\n (and `git diff --stat --cached` for staged).\n- Untracked files that look like real work, not build junk: `git status --porcelain`\n filtered to `??`, cross-checked against `.gitignore`.\n- Stashes: `git stash list`, and for each, `git stash show -p` to see what it holds.\n- Local branches ahead of {{default_branch}}: `git branch -vv`, then for each candidate\n `git log {{default_branch}}.. --oneline` to see unmerged commits.\n- Worktrees: `git worktree list`, and the status of each.\n- Anything that exists only in this session: edits made this session that were never\n committed anywhere. Compare what you changed against `git status`.\nProduce one inventory table: source (working tree / stash@{n} / branch / worktree),\nwhat it contains (one line), and an initial keep / discard / ask verdict with a reason.\n\nPhase 2 - Triage (self-critical, still read-only)\nFor each inventory item, decide and justify:\n- KEEP: real, wanted work not already on {{integration_target_branch}}. Confirm it is\n not already there by SHA or by diff before calling it a keeper.\n- REDUNDANT: already integrated (prove it: show the SHA on the target branch). Safe to\n clean up later, with consent.\n- DISCARD: genuine junk (build output, a failed spike the author abandoned). Requires\n explicit consent before deletion per Safety Rule 2.\nFor every verdict add one self-critical line: \"What would make this verdict wrong?\"\nIf you cannot answer that, mark it ASK and move on.\n\nPhase 3 - Integrate the keepers (mutations begin here)\nFor each KEEP, one at a time, smallest/safest first, never exceeding the scope cap:\n1. State the plan: source, method (cherry-pick / rebase / apply-stash-then-commit),\n and target {{integration_target_branch}}.\n2. Execute the proper integration. Preserve authorship and message.\n3. Verify-after-change immediately:\n - `git log --oneline -n 3` on the target to show the commit landed.\n - `git status` shows a clean tree (no leftover conflict markers, no stray files).\n - Run {{validate_cmd}}. Paste the tail of its output and its exit status.\n4. If {{validate_cmd}} is red: undo ONLY this one integration (git cherry-pick --abort,\n git merge --abort, or git reset --hard to the {{integration_target_branch}} HEAD SHA you\n recorded immediately BEFORE this integration). Do NOT reset to the Phase 0 anchor if earlier\n keepers already integrated successfully - that would destroy them. Paste the failure and\n follow Safety Rule 4.\n\nPhase 4 - Clean up (only with consent)\nOnly after keepers are integrated and green:\n- Propose the cleanup list (stashes to drop, merged branches to delete, worktrees to\n prune) with the SHA-level proof that each is safe.\n- Do not execute deletions until you get an explicit yes. Then execute, and show the\n resulting `git stash list` / `git branch -vv` / `git worktree list` to prove the state\n is clean.\n\nPhase 5 - Final report (evidence, not vibes)\nReport in this shape:\n- Anchor: starting branch + HEAD SHA (from Phase 0).\n- Recovered: table of each keeper -> the new SHA on {{integration_target_branch}}.\n- Validation: the exact {{validate_cmd}} line and its final exit status (paste the tail).\n- Cleaned: what was deleted/pruned, with before/after of the relevant git listing.\n- Left alone: anything ASK or over the scope cap, and why, so a human can finish it.\n- Residual risk: one honest sentence on what could still be wrong.\n\nCONSTRAINTS\n- Read before you write; the inventory and triage phases are entirely read-only.\n- One mutation at a time, each followed by its own verify step. No batching.\n- If at any point you are about to type a SHA, branch name, count, or file path from\n memory, stop and capture it live from a command instead.\n- Report findings here, in your final output. Do not spawn side tasks or create\n external chips/tickets.", "sha256": "08880b9c58909bfa9cb1f7dd8bd695ed291b22c69961da556666723a2a7ac558", "kind": "Git workflow", "breaks_when": "It misjudges \"stranded\" work in repos that intentionally keep long-lived parallel branches or stashes (release trains, vendored forks, parked spikes) and either rebases or discards a branch the team meant to keep alive; the scope cap and the \"ask before discarding\" rule reduce but do not eliminate this, because the prompt cannot read intent that lives only in a teammate's head.", "tested_with": "model-agnostic", "born_in_post": "/verify-your-own-postmortem/", "variables": [ "repo_path", "default_branch", "validate_cmd", "max_branches_to_touch", "integration_target_branch" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "cherry-pick-pr-value", "session-handoff-maintenance-with-double-audit", "plan-then-apply-destructive-gate" ], "relates_to": [] }, { "slug": "fail-open-fail-closed-audit", "title": "Fail-Open vs Fail-Closed Audit for Any Gate or Notification Path", "url": "https://funnyenough.dev/prompts/fail-open-fail-closed-audit/", "one_liner": "Forces a reviewer to classify every guard as fail-open or fail-closed and name the worst silent-failure case before approving.", "raw": "You are reviewing a gate / validation / notification path. The worst wrong action here is: {{worst_wrong_action}}. Review only: {{path_or_files}}.\n\nFirst, write one sentence: for this path, is a false alarm (firing when it should not) or a false silence (staying quiet when it should fire) the worse outcome? That answer sets which direction is CLOSED below.\n\nDo not summarize what the code does. Do not praise it. Your job is to find where it fails OPEN when it should fail CLOSED.\n\nDefinitions, use them literally - relative to the worst action, NOT to \"staying silent\":\n- FAIL CLOSED = on missing, ambiguous, stale, or error-state input, the code defaults to whatever AVOIDS {{worst_wrong_action}}. Depending on the path that may mean refusing and staying silent, or it may mean firing the alarm/brake - whichever avoids the worst action.\n- FAIL OPEN = on that same bad input, the code does {{worst_wrong_action}} or a proxy of it: it proceeds, fires when it should not, OR stays silent when it should fire.\n\nWalk every branch that can decide \"act vs do-not-act\" and produce a table with one row per branch:\n| location (file:line) | trigger condition | on bad/missing/error input it currently... | OPEN or CLOSED | worst outcome if wrong | should be |\n\nSpecifically hunt for these fail-open smells and list each one you find, with the exact line:\n1. try/except (or try/catch) where the except branch returns a value that lets the caller proceed, swallows the error, or logs-and-continues instead of refusing.\n2. early `return True` / `return ok` / `return []` / `return None` that a caller reads as \"all clear\" rather than \"could not determine\".\n3. a default parameter, env var, or config fallback that is the PERMISSIVE value (e.g. enabled, allow, send) when the real value is absent.\n4. a check that is skipped entirely when an input is None/empty/unparseable, so absence of a signal reads as absence of risk.\n5. a timeout, network, or parse failure path that ends in the action firing rather than being suppressed.\n\nRules for your verdict:\n- You may not write \"looks fine\" or approve until you have named at least ONE concrete branch and stated, in one sentence, the exact input that makes it do the wrong thing.\n- If after a genuine line-by-line pass you find zero fail-open branches, say so explicitly and then name the single branch you were LEAST sure about and why you ultimately cleared it. Silence is not a pass.\n- For every fail-open row, give the one-line fix that makes it fail closed (what to return / refuse / suppress instead), and call out if that fix is load-bearing safety logic that a future \"cleanup\" refactor must never delete.\n- Distinguish a guard that is INTENTIONALLY fail-open (documented, with a reason) from one that is so by accident. Flag undocumented ones as the higher risk.\n\nEnd with: the single highest-risk fail-open branch, and whether you would block the change on it.", "sha256": "3bec85d60cbd58901c224ec8a4281422c3f170fdefad3b04ee4c9e449372e8ad", "kind": "Safety audit", "breaks_when": "It is only as right as the {{worst_wrong_action}} you give it. Name the worst action wrong, or pick a path whose danger flips with context (sometimes firing is worse, sometimes silence is), and it will confidently audit toward the wrong \"closed\" direction.", "tested_with": "claude", "born_in_post": "/abstention-gate-ai-agents/", "variables": [ "path_or_files", "worst_wrong_action" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "abstain-gate-suppress-stale-inputs", "adversarial-fix-verification", "multi-lens-qa-fanout-triage" ], "relates_to": [ "plan-then-apply-destructive-gate", "adversarial-reviewer-must-find-one-issue" ] }, { "slug": "claim-ladder-verify-before-encode", "title": "Claim-ladder gate: verify against the live source before you encode it", "url": "https://funnyenough.dev/prompts/claim-ladder-verify-before-encode/", "one_liner": "Forces the agent to drop to the running source and cite file:line or a command run before it writes any load-bearing config, guardrail, or claim.", "raw": "You are about to encode this load-bearing claim into {{target_file}}:\n\n {{claim_to_encode}}\n\nA load-bearing claim is anything that, if wrong, silently breaks behavior or misleads a future reader: a config value, a guardrail/threshold, a hook or cron timing, an API/library behavior, a CLI flag's effect, an \"X is safe / X is fenced off\" assertion.\n\nTreat every input as a claim on a trust ladder, cheapest and least trusted first:\n 1. your memory or a guess\n 2. docs, README, changelog, a blog, a code comment\n 3. the source RUN LIVE against the real artifact -- the ONLY rung that counts as evidence.\n\nHard rules:\n- You MAY consult rungs 1 and 2 to form a hypothesis. You may NOT encode anything into {{target_file}} on the strength of rungs 1 or 2 alone.\n- Docs are a claim too, and they are routinely stale or wrong. \"The README says so\" is not evidence. If a doc and a live run disagree, the live run wins and the doc is now suspect.\n- Before you write the claim, drop to rung 3: read the actual source at the exact file:line that governs the behavior, OR run a NON-MUTATING command / minimal script in the environment where the claim matters, and capture the raw output plus the relevant runtime / version / config / timezone.\n- Never type a value you predicted. Capture it live and paste the captured value. If you catch yourself about to write a number, path, flag, SHA, or behavior \"from memory,\" STOP and go verify it.\n\nScale the rigor to the blast radius: a throwaway script, a quick read is fine; a guardrail that decides whether a real failure reaches a human, never skip the live run.\n\nOutput, in this order:\n1. CLAIM: the one sentence you intend to encode.\n2. EVIDENCE: the exact `path/to/file:line` you read, or the exact command you ran, plus the raw captured output (verbatim, not paraphrased).\n3. VERDICT: CONFIRMED (evidence matches the claim -> eligible to encode; edit {{target_file}} only if the caller asked for writes), CORRECTED (evidence differs -> show the corrected claim and what the doc/memory got wrong), or UNVERIFIABLE (you could not reach rung 3 -> do NOT edit; say exactly what live access you are missing).\n\nIf VERDICT is anything other than CONFIRMED, do not modify {{target_file}}. Refuse to encode an unverified claim even if it \"looks obviously right.\"", "sha256": "100edf9b2ae8f6fa70aa59548a57c3925fd188b54407d804dd42d78dda62b4fa", "kind": "Verify before encode", "breaks_when": "If the \"live source\" itself is non-deterministic or environment-specific (a flaky integration test, a time/locale-dependent command, a service that behaves differently in CI vs your laptop), the cited run can be a true observation that is still wrong for production, and the agent will hand you a confidently-cited but non-generalizable claim.", "tested_with": "model-agnostic", "born_in_post": "/verify-your-own-postmortem/", "variables": [ "claim_to_encode", "target_file" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "adversarial-fix-verification", "byte-exact-copy-paste-audit", "session-handoff-maintenance-with-double-audit" ], "relates_to": [ "fail-open-fail-closed-audit", "no-fix-without-failing-repro" ] }, { "slug": "byte-exact-copy-paste-audit", "title": "Audit a “byte-exact / copy-paste-safe” claim end to end", "url": "https://funnyenough.dev/prompts/byte-exact-copy-paste-audit/", "one_liner": "A narrow, specialist audit for proving a delivery pipeline does not silently mangle bytes; trace every transform from source to what the user pastes and name the one that corrupts.", "raw": "You are auditing whether this claim survives end to end, byte for byte:\n\n CLAIM: {{claim}}\n SOURCE OF TRUTH (the original bytes): {{source_of_truth}}\n DELIVERY SURFACE (what the user actually receives/copies): {{delivery_surface}}\n\nThe claim is GUILTY until you prove it innocent. Your job is not to agree with it; your job is to find the one place it lies.\n\nDo this:\n\n1. Build the transform chain. List, in order, EVERY stage the bytes pass through from source to delivery: file read/encoding, template engine + every filter/escape applied, string interpolation, markup serialization, HTML/JSON escaping, syntax highlighter, CSS that swaps glyphs (text-transform, ligatures, ::before/::after content), minifier/bundler, CDN/proxy rewrite, and the final copy path (innerText vs textContent vs a clipboard handler). For each stage write one line: STAGE -> what it can mutate.\n\n2. Flag every lossy or substituting stage. Smart-quote / curly-quote conversion, en/em dash rewriting, NBSP injection, tab-to-space, trailing-whitespace strip, Unicode normalization (NFC/NFD), HTML-entity encode/decode that does not perfectly round-trip, autolink, trailing-newline add/strip, zero-width or BOM insertion. A stage is suspect even if it \"usually\" round-trips.\n\n3. Run the witness - against REAL bytes, not a rendered sample. Do not trust the characters printed below or in {{sample_string}} as-is; a Markdown render may already have mangled them. First GENERATE a witness file whose bytes include straight quotes, an apostrophe, a double hyphen, a backslash, one real tab byte (0x09), doubled spaces, and one trailing space byte (0x20), and hexdump it to confirm. Then walk that file through the chain stage by stage, showing the bytes after each stage (the line below only illustrates the kinds of characters to include):\n\n `\"It costs $5 -- that's 3--4x. Path: C:\\\\temp\\tab two-spaces. Don't trust it.\"`\n\n Use a string that already contains: straight quotes, a double hyphen, a real tab, an apostrophe, doubled spaces, a backslash, and a trailing-space candidate. Show where any byte changes.\n\n4. Verdict. State HOLDS, BROKEN, or UNKNOWN (UNKNOWN = one or more stages could not be observed; list the missing stage and the cheapest probe). If BROKEN you MUST name the SPECIFIC corrupting transform: which stage, which exact input byte/sequence becomes which exact output byte/sequence, and the one-line code/config location that does it (e.g. \"Jinja `|e` autoescape\", \"marked.js smartypants\", \"CSS text-transform on .code\", \"innerText collapsing the tab\"). \"Encoding issues somewhere\" is not an answer and is a failed audit.\n\n5. Give the cheapest proof I can run myself to confirm: a diff, a `xxd`/hexdump of source vs delivered, a `len()` compare, or a clipboard round-trip check. One command.\n\nDo not refactor anything. Do not declare HOLDS unless you actually traced the witness through every stage in step 3 without a byte changing. If a stage's behavior is unknown, say so and treat it as suspect, not safe.", "sha256": "bccaa64a0adfaca4f1513ce497b35f7d1935e1a4f3a775dcb56b81b083e4b88c", "kind": "Integrity audit", "breaks_when": "It only audits the pipeline path you point it at: if the corrupting transform lives in a layer outside the named files/route (a CDN minifier, an editor's auto-format-on-save, the OS clipboard, a font ligature that only looks like a substitution), it will declare the path clean and you'll trust a claim that still breaks downstream.", "tested_with": "model-agnostic", "born_in_post": "/qa-dev-ai-coding-agents-receipts/", "variables": [ "claim", "source_of_truth", "delivery_surface", "sample_string" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "experimental", "used_with": [ "claim-ladder-verify-before-encode", "adversarial-fix-verification", "multi-lens-qa-fanout-triage" ], "relates_to": [ "fail-open-fail-closed-audit", "respect-deferred-state-audit-guard" ] }, { "slug": "adversarial-reviewer-must-find-one-issue", "title": "Adversarial Code Reviewer That Refuses to Rubber-Stamp", "url": "https://funnyenough.dev/prompts/adversarial-reviewer-must-find-one-issue/", "one_liner": "A code-review prompt that can't approve until it names one concrete issue (or proves the diff clean line-by-line).", "raw": "You are an adversarial code reviewer. Start from suspicion, not trust - but only evidence earns a finding; an unsupported concern goes in UNVERIFIED, never in ISSUES. Most diffs that look fine are hiding something; your job is to find it before it ships, not to manufacture a finding to satisfy a rule.\n\nReview this change:\n{{diff_or_path}}\n\nContext (what it is supposed to do, constraints, prior bugs):\n{{context}}\n\nHard rules you cannot violate:\n\n1. You may NOT output APPROVE until you have either:\n (a) named at least one concrete, specific issue - with the exact file, line or hunk, what is wrong, why it bites, and the fix; OR\n (b) walked EVERY changed hunk one by one and stated, per hunk, why it is correct and safe. A blanket \"the rest looks fine\" is forbidden. If you skip a hunk, you have not earned APPROVE.\n\n2. \"Looks good\", \"LGTM\", \"no issues found\", and praise of any kind are banned as a verdict on their own. They carry zero information. Delete them.\n\n3. Severity-tag every issue you raise: [BLOCKER] correctness/security/data-loss, [SHOULD] real but shippable, [NIT] taste. Do not pad the list with [NIT]s to look thorough - if all you have is one [NIT], say so plainly and treat the diff as effectively clean.\n\n4. Hunt specifically for the failure classes reviewers miss: off-by-one and boundary conditions, null/undefined/empty-collection paths, error and exception paths that are swallowed or unhandled, concurrency and ordering, resource leaks (unclosed handles, unbounded buffers), inputs that are attacker-controlled, and behavior changes that the tests in this diff do NOT cover. For each applicable class, cite the handling line or raise a concrete finding; for a class not implicated by this hunk, write \"not implicated\" rather than inventing a concern.\n\n5. Separate what you VERIFIED from what you ASSUMED. If you could not see a definition, a caller, or a test, say \"unverified: \" rather than guessing it is fine. Never invent a line number or a symbol you did not actually read.\n\nOutput format, in this order:\n- VERDICT: one of REQUEST-CHANGES or APPROVE (and APPROVE only if rule 1 is satisfied).\n- ISSUES: numbered, each tagged, each with file:line + problem + why it bites + concrete fix.\n- IF APPROVING WITH NO BLOCKER: the per-hunk safety walk required by rule 1(b).\n- UNVERIFIED: the list of things you could not check and what would let you check them.\n\nBegin.", "sha256": "cf798743829802e707884c89aac2c275729195c0af2d2eaa513af5aad6f1c679", "kind": "Code review", "breaks_when": "On a genuinely trivial diff (a one-line typo fix, a version bump) the \"find at least one issue\" pressure can manufacture a nitpick to satisfy the rule; treat a lone style gripe as equivalent to a clean pass, not a real blocker.", "tested_with": "claude", "born_in_post": "/ai-code-qa-gate/", "variables": [ "diff_or_path", "context" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "adversarial-fix-verification", "two-critic-judge-dedupe", "cherry-pick-pr-value" ], "relates_to": [ "multi-lens-qa-fanout-triage", "fail-open-fail-closed-audit" ] }, { "slug": "adversarial-fix-verification", "title": "Adversarial Fix Verification: Prove the Bug Is Gone, Not Just Green CI", "url": "https://funnyenough.dev/prompts/adversarial-fix-verification/", "one_liner": "Forces an agent to prove a claimed fix actually closes the bug, hunt the regressions it introduced, and probe the changed lines before signing off.", "raw": "You are reviewing a claimed fix. Your job is NOT to confirm it. Your job is to find out whether the bug is actually gone and what the fix broke on its way there. A green test suite is evidence of nothing until you have separated \"tests passed\" from \"the bug is dead\".\n\nBUG BEING FIXED:\n{{bug_description}}\n\nTHE FIX (commit / branch / diff):\n{{fix_ref}}\n\nHOW TO REPRODUCE THE ORIGINAL BUG:\n{{repro_command}}\n\nHOW TO RUN THE TESTS:\n{{test_command}}\n\nWork through these gates in order. Do not skip a gate because an earlier one \"looked fine\". Report findings per gate.\n\nGATE 1 - Pin the bug before trusting the fix.\n- State the exact observable that defined the bug (wrong value, crash, leak, status code, race). If you cannot name a concrete observable, say so and stop - you have nothing to verify against.\n- Reproduce the original bug against the PRE-FIX state, but ONLY in a clean disposable worktree or clone, or after explicit permission. Do not stash, checkout, reset, or rewrite the user's working tree as part of verification. Confirm with your own eyes that it reproduces. If it does not reproduce on the old code, the diff may be fixing a bug that was never the reported one - flag this loudly.\n\nGATE 2 - Prove the bug is dead, separately from the suite.\n- Run {{repro_command}} on the fixed code. Paste the actual output in a fenced block; \"ran successfully\" with no output shown is a FAIL of this gate.\n- Is there a test that FAILS on pre-fix code and PASSES on fixed code, asserting the specific observable from Gate 1? If the only \"proof\" is that the existing suite is green, that is not proof - existing tests passed before the bug was filed too. Name the test or declare it missing.\n- Distinguish: did the fix remove the cause, or just suppress the symptom (swallowed exception, widened type, loosened assertion, retry that hides a race)? Symptom suppression is a FAIL of this gate.\n\nGATE 3 - Hunt the regression the fix introduced.\n- List every behavior that depended on the OLD code path. For each, ask: does the new code still honor it? This is where a passing CI hides a reintroduced bug - the fix satisfied its own new test and quietly changed an adjacent contract.\n- Look specifically for: callers that relied on the old return value/shape, error paths now skipped, defaults that changed, ordering/timing the fix altered, state that is now set or cleared earlier/later.\n- For each suspect, either run it or write the one-line case that would catch it. Do not hand-wave \"probably fine\".\n\nGATE 4 - Edge cases around the changed lines.\n- Read only the lines the diff touched and their immediate neighbors. Enumerate the boundaries: null/empty/zero, first/last element, concurrent entry, the largest input, the path taken when the new branch is FALSE.\n- Which of these does the test suite actually cover? Which are asserted only by your optimism? Name the uncovered ones.\n\nVERDICT - pick exactly one, and you may not pick PASS without naming concrete evidence for Gates 2, 3, and 4:\n- PASS: bug provably dead (cite the failing-then-passing test), no regression found (cite what you checked), edges covered (cite them).\n- FAIL: the bug is not actually closed, OR a regression exists. State which, with the reproducing case.\n- INCONCLUSIVE: you could not pin the bug (Gate 1) or could not run the repro. Say exactly what you'd need.\n\nYou are not allowed to end on \"looks good\" or \"tests pass\". If everything genuinely checks out, your last line must name the single case that would most likely break this fix in production, so the next person knows where the thin ice is.", "sha256": "dccc89860b668a9f7077985aba24642d74b4abb69bb1b074ae2052b4f4184e89", "kind": "Fix verification", "breaks_when": "If there is no failing test or reproduction that pins the original bug, the agent can only reason about the code and may declare the bug \"gone\" from a plausible-looking diff it never actually exercised - the same false-green it's meant to catch.", "tested_with": "claude", "born_in_post": "/verify-your-own-postmortem/", "variables": [ "bug_description", "fix_ref", "repro_command", "test_command" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "multi-lens-qa-fanout-triage", "two-critic-judge-dedupe", "session-handoff-maintenance-with-double-audit" ], "relates_to": [ "no-fix-without-failing-repro", "adversarial-reviewer-must-find-one-issue", "claim-ladder-verify-before-encode" ] }, { "slug": "cherry-pick-pr-value", "title": "Cherry-pick the value from every PR (never merge dirty)", "url": "https://funnyenough.dev/prompts/cherry-pick-pr-value/", "one_liner": "Review each open PR against main, extract its best parts cleanly, capture the lesson from the rest, close the worthless with a real reason - leave the repo cleaner than you found it.", "raw": "You are reviewing open pull requests against the current codebase. The goal is NOT to merge them as-is and NOT to close them to clear the queue. It is to EXTRACT the value from each PR and leave the project cleaner and higher-quality than you found it. A lazy \"merge or close\" pass is a failure of this task.\n\nPRs / branches to review:\n{{prs_or_branches}}\n\nWhat main currently does + the quality bar:\n{{repo_context}}\n\nBefore you touch anything: confirm main is current (fetched and up to date), the working tree is clean, and you have a restore point (a branch or a known-good commit). Capture the starting branch and HEAD SHA with a live command (e.g. git rev-parse HEAD) and record it, so a red validate after a cherry-pick can be reverted to THAT recorded SHA without disturbing earlier-landed keepers. If any of those is false, STOP and report what must be fixed first - do not change files or close PRs from a dirty or stale base. Process at most 5 PRs this pass (fewer if any integration is large); defer the rest with a one-line reason each - no skim-rulings. Finish one PR completely - integrated-and-green, captured, or closed - before you start the next.\n\nFor EACH pull request, in order:\n\n1. ASSESS against main. Read BOTH the current code on main AND the PR's diff - you cannot rule on a PR you only skimmed. Check whether its change already landed on main (in whole or part) and what its CI / review state is. State concretely what it brings: useful logic, an implementation pattern, a bug fix, a reusable asset, or only a lesson / failed experiment. Be specific: \"adds retry-with-backoff to the upload path\" not \"improves uploads\".\n\n2. RULE - exactly one:\n - INTEGRATE: it has valuable parts. Do NOT merge, squash, or fast-forward the PR. On a fresh branch off current main, port the SMALLEST coherent set of its ideas, ADAPTED to main's conventions, not pasted. Name exactly which hunks/ideas you took, which you dropped, and why. Run the project's build and tests. If they fail, either fix it cleanly now or REVERT this PR's changes and re-rule it CAPTURE or CLOSE - never carry broken work forward and never merge red. Only after green: land it and record the commit/PR reference in your table row.\n - CAPTURE: no shippable code, but a real lesson, pattern, or \"this approach failed because X\" worth keeping. Write it somewhere durable and grep-findable - an ADR (docs/adr/NNN-title.md), a named test whose name states the failure, or an issue/comment - tagged with the PR number and the concrete lesson. NEVER close the PR until that capture exists on disk or as a URL. Put the exact path/URL in your table row.\n - CLOSE: only after the assessment and the self-critical loss check below, and only if nothing reusable remains (superseded, wrong direction, broken beyond worth). If ANY idea is reusable, CAPTURE it first. Close it yourself with a clear, specific comment: WHY, the evidence on main that made it obsolete or wrong, and whether anything was captured (link it). No vague \"closing stale PR\" - the author deserves the real reason, even if the author is you last week.\n\n3. Be self-critical at the decision, in one written line before you act. Tempted to CLOSE? Answer \"what exactly would I lose, and did I capture it?\" Tempted to INTEGRATE? Answer \"is this actually better than main, or just different?\"\n\nHard rules:\n- Never merge a PR whole to dodge the work of extracting its good parts; never merge or push red.\n- Every CLOSE has a written reason + evidence. Every CAPTURE exists on disk or as a URL before its PR is closed. Every INTEGRATE names what was taken and dropped and lands only green.\n- One PR's mutations are finished and verified before the next begins - no two half-applied cherry-picks interleaved.\n- Leave main coherent: no half-applied features, no dead code, no failing build, nothing re-implemented that already landed elsewhere.\n\nEnd with:\n- Proof per PR: ruling + evidence (commit hash / file path / close-comment URL) + your one-line self-critical answer.\n- A table: PR | ruling (INTEGRATE / CAPTURE / CLOSE) | what was taken, captured, or why closed | evidence.\n- Deferred PRs (if any): list + why.\n- One honest line: is the codebase cleaner and higher-quality than before you started? You may say yes only with evidence - green build/tests on main, captures on disk, closes logged with reasons. If not, you are not done.", "sha256": "76711bdb6947ece13ee74e8be4f4717597b7d193dc1a4724f59a96b3c09099de", "kind": "PR review", "breaks_when": "It assumes a clean, current main and a restore point. Run it from a dirty or stale worktree and an INTEGRATE can smear half-applied changes across PRs. It also cannot see CI/review nuance a maintainer would, so on a shared repo confirm a PR is really yours to close before closing it.", "tested_with": "claude", "born_in_post": "/qa-dev-ai-coding-agents-receipts/", "variables": [ "prs_or_branches", "repo_context" ], "last_verified": "2026-06-21", "freshness": { "state": "fresh", "label": "Fresh", "tone": "fresh" }, "status": "active", "used_with": [ "git-hygiene-work-recovery-operator", "session-handoff-maintenance-with-double-audit", "adversarial-reviewer-must-find-one-issue" ], "relates_to": [ "multi-lens-qa-fanout-triage" ] } ] }