Use when recording or ranking any finding — read each source for what it IS and weight it by strength of evidence (behavioral > attitudinal, observed > reported, first-party >…
Use when generating or accepting AI/LLM-written code — treat the model as a fast junior, not an oracle: give it context, then verify every line; never ship plausible-but-wrong…
Use for any change before calling it done — prove it with the right tests (unit base + an integration test that hits the real surface and asserts persisted state), then do an…
Use when copy across surfaces is inconsistent or ad-hoc, when you need a reusable messaging framework the whole team can derive from (homepage, deck, ads, onboarding all ladder to…
Use when rolling out any risky change to many users/hosts — stage it (canary → progressive → full) behind health gates and flags so a bad change is caught at 1% and auto-aborted,…
Use when a verdict rests on a measured quantity rather than a single deterministic assertion — a noisy/probabilistic output, a performance number, an accuracy or conversion rate.
Use before recording any new person/entity/insight/belief — search what already exists and converge new signal onto it; coin a new node only when nothing fits.
Use before gathering — pick the method by the question (attitudinal vs behavioral, qual vs quant), match the source to what you need to learn, and right-size the rigor to the…
Use when scoping any user-facing surface — require a whole-surface design up front; ship in slices, but each slice lands in its final place, nothing bolted on to be re-placed…
Use when deciding how to represent a design to test or communicate it — match fidelity to the question.
Use whenever a surface will be seen on more than one screen size or input — which is almost always (62%+ of web traffic is mobile).
Use when designing or fixing how the system is configured (env vars, json/yaml/toml files, flags, per-project/per-box settings, layered defaults) — give config a versioned schema,…
Use on every surface before it ships — the pre-merge craft pass. Work the polish checklist (tabular nums, optical alignment, concentric radius, shadow-vs-border, focus, type…
Use when assessing founder conviction and "why you / why this" — separate a genuine haunting from FOMO.
Use whenever a change is heading to production or you're asked "is this ready to ship / is it live / is it healthy" — adopt the you-build-it-you-run-it posture and verify by…
Use when the message is aimed at "everyone," when one product serves multiple distinct buyers, or when you need to pick the beachhead segment to lead with.
Use when reviewing a change, a design, or a system's readiness — ask "if this gets attacked or exploited in prod, would we even know?" Review the audit trail, the…
Use when assessing defensibility and timing — why won't the incumbent (or a well-funded lab) just do this, and what's the durable moat once the easy parts commoditize.
Use when a load-bearing fact is unknown — ask the founder the few questions you cannot responsibly default; propose defaults for the reversible ones; fill placeholders, never…
Use when reviewing anything that authenticates users, checks permissions, or exposes objects by id — broken access control is the #1 web risk; verify authz is enforced server-side…
Use whenever designing any surface or component — design the full set of states, not just the happy path.
Use before writing or changing any non-trivial code, especially in an unfamiliar codebase — understand the problem, the brief, and the surrounding code first; never start typing…
Use to decide where to spend a finite testing budget — prioritize by risk (likelihood × impact), hammering data loss, auth, the core flow, and money first, and right-size the…
Use when reliability/recoverability is being assumed rather than proven — deliberately inject the failure (dependency down, AZ/region loss, restore from backup, failover, on-call…
Use when protecting working behavior across changes — keep a fast, risk-prioritized regression gate on the highest-value journeys, and quarantine-and-own a flaky test instead of…
Use when a security incident is suspected or active (breach, leaked secret, active exploit, suspicious activity) — run the NIST lifecycle: contain, eradicate the root cause,…
Use when laying out any screen or composing a set of elements — make the eye go where it should. Establish visual hierarchy (one focal point, deliberate scan path), group with…
Use when structuring content, navigation, or labels — when users can't find things, the nav is growing organically, a new section needs a home, or you're naming/grouping concepts.
Use first, before any copy — when positioning is unwritten, vague, aspirational, or being re-improvised per artifact.
Use when asked "what should we build (next / at all)?", when the roadmap is turning into a stakeholder wishlist, or for a build-vs-buy call — set the strategic bet first and…
Use when reporting status or accepting work — keep the board honest (in-progress only if truly in progress, done only if verified done) and CHECK the definition of done against…
Use before or while designing when you need to understand users — their goals, context, mental models, and real behavior.
Use for build-vs-buy, adopting a new framework/database/language, or "should we use X" — apply the innovation-token test; default to the well-understood; a stack only the AI…
Use when summarizing whether the bet clears the bar — explicitly tally how many unique insights it carries across tech, market, and GTM. One isn't enough; name which ones and why.
Use to keep research a habit, not a phase — small weekly touchpoints with real users, structured as an opportunity-solution tree, with every belief paired to the cheapest test…
Use during the runtime adversarial pass — attack the build the way real users (and bad actors) actually behave: malformed input, concurrency, network failure, refresh/back,…
Use before drawing any screen — when asked to "design a page/feature/screen," map the user's task end to end (entry, happy path, branches, every empty/loading/error/edge state,…
Use before a launch/traffic spike (marketing push, Black Friday, a new large customer) or when asked "can we handle the load / will this scale" — model the expected and worst-case…
Use whenever you record a claim — attach its verbatim source (the quote, who, when, what kind) so a finding can always be traced back.
Use when there's a technical or scientific claim under the pitch — push on the mechanism in proportion to how load-bearing it is.
Use when deciding whether a deal is real and worth your effort, or what's missing to win it — qualify with MEDDPICC (Metrics, Economic Buyer, Decision criteria/process, Paper…
Use when reviewing config, env handling, CI/CD, logging, or anything that touches credentials — secrets never in repo or logs, short-lived and least-scope, with insecure defaults…
Use when cloud spend is rising, unexplained, or unattributed, or before provisioning expensive resources — treat cost as an engineering metric: make it visible, attribute it, find…
Use when you have findings to report — grade each by real-world risk (P0–P3) with a specific minimal remediation, block only real exploitable harm, and name accepted risk out loud.
Use whenever you (or AI) produce or review a UI draft — your prime reflex against generic, templated design.
Use when price, discount, or terms come up at the deal's end — hold value, trade don't give (every concession buys something back), use tactical empathy and calibrated questions.
Use before any account, call, or outreach — research the buyer from THEIR side (their world, what they use today + what it costs, the trigger event, who pays vs.
Use when running a founder meeting or generating the questions you'd ask — the texture of the conversation, not a diligence checklist.
Use when surfacing findings — lead with the unmet need and what to do about it, ranked by confidence; never dump a transcript or a deck. The output is a decision, not data.
Evidence group skill. Runs direct end-user interviews to saturation. Gates on access — halts if discovery-context says user_access is none or proxy-only.
Use before building on or committing to a vendor/runtime (cloud, PaaS, serverless, queue, DB, third-party API) — read the actual pricing, runtime-limits, and execution-model docs…
Use before any change touches prod — enumerate what's stateful, what's a one-way door, what's reversible, and who's downstream, so rigor matches risk and the irreversible parts…
Use whenever you reach for a value (color, spacing, radius, type, motion) or build a component — extend tokens and shared components in place, never fork into one-off className…
Use to keep problems distinct from solutions — map how people actually think about getting their job done (their cognition, reactions, guiding principles), deliberately separated…
Use before you test anything — build your own model of "correct" from the brief, spec, and user journeys so you have a basis to call something a bug, and state which expectation…
Use when designing any interface where AI acts, generates, or decides on the user's behalf (agents, generative UI, AI suggestions, automation).
Use for any release that needs to reach users — a new product, a major feature, or a steady stream of small features.
Use whenever a rewrite, redesign, or refactor would remove, replace, or overwrite copy or visuals that are already in place — a tuned headline, a converting landing page, a hero,…
Use when a vulnerability is reported from OUTSIDE the team (a security researcher, a user, a bug bounty, an embargoed upstream CVE) — triage it without shooting the messenger,…
Use BEFORE picking which questions matter — reweight the load-bearing themes by the company's category and stage.