HamzaYM

multi-model-adversarial-review

Use before merging any substantive change, or before finalizing a document, plan, or claim, when you want a genuine adversarial pass rather than the same model re-reading its own work. Applies to code diffs, PRs, architecture plans, and prose (specs, memos, claims). Not worth it for trivial one-line changes.

architecture-contracts-as-law

Use when changing anything that crosses a system boundary: database schema, wire/API shapes, cross-module imports, the one place a third-party SDK is allowed to be called from, or when tempted to build infrastructure "ahead of need." Establishes a single merge-blocking source of truth for system invariants, kept current in the same commit as the code that changes it.

multi-tenant-auth-reference

Use when debugging or changing auth, tokens, sessions, invites, or tenant isolation in a multi-tenant application: unexpected 401s/403s, cross-tenant data leaking or disappearing, role checks that seem too wide or too narrow, or row-level security that appears to be silently doing nothing.

multi-agent-batch-campaigns

Use when executing a large backlog of review findings or a multi-part feature as coordinated batches across parallel agents or sessions, planning waves, avoiding file-contention collisions, and resuming a campaign that a previous session left mid-way through.

git-change-control-for-agents

Use when doing any git work: cutting a branch, opening a PR, merging parallel work, or resuming work in a repo you didn't just leave. Covers state verification before acting, the dead-base PR trap, migration-number collisions, working-tree discipline, and how to handle a product decision that surfaces mid-task.

ai-cost-tracking-and-guardrails

Use when adding or changing any LLM call in a system that handles regulated or sensitive data (health records, financial data, other personal information) or that needs hard cost control: provider fallover between vendors, rate limiting, per-session or per-tenant cost caps, or making sure every call is tracked and priced.

budget-aware-model-allocation

Use when you're working with more than one model or provider with separate rate-limit or token budgets, and one of them is running low. Decide whether to proceed lean, defer non-urgent work, or shift heavy work to whichever provider has headroom, instead of blowing through a limit on autopilot.

config-and-secrets-hygiene

Use when adding or changing configuration, environment variables, or feature flags: deciding which config layer something belongs in, adding a new per-tenant flag, debugging why a config value or flag "does nothing," or reviewing whether a boot-time secret guard is safe to weaken.

failure-archaeology

Use when you're about to propose something that smells like it might have already been tried and abandoned: a hosting/platform migration, a framework or library swap, a "quick fix" to code that looks deliberately unusual, or when a revert commit turns up in git history. Prevents re-litigating settled decisions and re-fighting battles someone already lost on purpose.

systematic-debugging-playbook

Use when debugging any bug, regression, or failing test, before proposing a fix, and especially before editing a file you know is a frequent source of regressions. Establishes ground truth before hypothesizing, and defines the discipline for multi-round fix loops after a review pass finds problems.

environment-and-build-hazards

Use when bringing up or diagnosing a local development environment: services won't start, database connection/permission errors, seed data missing, or when "local" development actually points at a shared remote environment and destructive commands are one keystroke away from hitting it.

staging-to-prod-cutover-campaign

Use when standing up a new deployment environment (first staging deploy, or a greenfield production environment), when infra work has been authored but not yet applied, or when deciding what staging config must never be inherited by production. Covers first-apply traps, ops-script deployment pitfalls, and the do-not-inherit scrub.

consent-and-regulated-data-reference

Use when a change touches user consent, data retention or erasure, breach notification, or any messaging/communication opt-in that's subject to privacy or marketing-communication law (health data, financial data, or general personal-data regulation). Establishes fail-closed defaults and the never-cross lines that keep a system defensible.

docs-of-record-and-arbitration

Use when project documentation disagrees with itself, disagrees with the code, or you're not sure which of several overlapping docs is actually current, and when producing a business or team-facing deliverable (a showcase, a report, screenshots) that needs to be factually solid before it ships.

llm-eval-harness-and-scoring-pipeline

Use when building or changing a pipeline that scores, grades, or extracts structured output from an LLM in production: composite/aggregate scoring math, partial-failure handling when one sub-call fails, prompt versioning, an eval harness that makes real model calls, or comparing a candidate model/prompt against production without flipping it live.

tiered-consultancy-review

Use when a deliverable needs to go from rough draft to genuinely finished without the requester babysitting every pass, a cover letter, a strategy memo, a customer-facing document, a recommendation, a decision review, or any artifact where tone, framing, and defensibility all matter as much as correctness. Mirrors how a consulting firm actually reviews work before a partner signs it.

pre-merge-validation-gate

Use before declaring any change "done," before opening or updating a PR, after any UI-touching change, or whenever you're about to report test results. Defines what "done" actually means and how to report it without overstating what was checked.