Use when brand or marketing work needs to be on-brand and traceable — set up a Brand Context Protocol (BCP) for a business, capture brand truth, or produce/score a deliverable (landing page, deck, email, ad copy) against the brand. Triggers on "set up a brand", "make this on-brand", "scaffold a BCP", "brand context…
Use when you need to measure front-end performance or Core Web Vitals — LCP, CLS, INP/TBT, page load and hydration timing — for a page or a change, and judge it against a perf budget or baseline to catch regressions. Reach for it when a page feels slow, before/after a UI change, or when you must prove a perf budget…
Use when you have a raw, vague, or unexamined idea or feature request and you want to pressure-test it with forcing questions BEFORE any planning or design — to make sure you build the right thing. Produces a sharpened problem statement and scope boundaries you can hand to the plan workflow. Skip when the problem is…
Use when a coding task is non-trivial — a new feature, a multi-file change, a refactor, or anything with more than one reasonable approach — and you want a reviewed implementation plan before writing code. Produces a concrete, criticised plan you can hand to a build step. Skip for typo-level or single-obvious-line…
Use when you must verify a change actually works through the REAL browser UI — acceptance, end-to-end, smoke tests, form interactions, navigation, login flows — driven by the agent-browser tool. Invoke when "click through it", "does the UI work", "smoke test the page", or browser-level evidence (screenshots…
Use when you have a diff, a PR, or a set of changed files and want a staff-engineer-level audit before it merges — correctness and security bugs, error handling, and simplification/reuse opportunities — with findings classified by severity and confidence and high-confidence fixes optionally applied and verified. Skip…
Use when a change has been reviewed and you are ready to land it — merge the PR, cut the release, or push to production. Drives the change out the door: tests in place, changelog updated, a tight PR description, CI green, and the deploy verified end-to-end. Skip while still building or before review; this is the last…
Use when you need to confirm a code change actually works by running the app and observing real behavior — not by trusting green unit tests. Triggers — verify a PR or fix, confirm a feature works, manually validate a change before shipping, start the app/server/CLI and exercise the specific behavior the change…