Drive a browser with Playwright as a dual-mode superset. Resilient locators/selectors for debugging your own web app (exact DOM, sub-second timing, CSS-media emulation) and a vision/coordinate loop (screenshot → click x,y → type) for genuinely opaque UI on unknown or messy real sites. Use whenever you actually drive a browser. Reproducing a UI bug in a running web app, automating or scraping a site, filling forms, or walking a checkout. Triggers on /drive-browser, "drive my browser", "drive Helium", "drive my real session", "automate the browser". This is the HOW (the mechanism). /run and /verify decide when to drive. When driving the user's REAL logged-in session, the Safety section is binding.
Surface what I think we're doing before acting on it. Use when the user types /align, says "let's align first", "check in before you start", or "mirror what you're hearing". Also invoke before starting any task with real interpretive weight. An ambiguous request, a vague spec, a "build X" with the details unstated. Where drafting from the wrong premise would waste the work. Produces a structured manifest exposing every silent commitment so the user can correct course before any artifact is produced.
Surface and resolve underspecified decisions before designing. Use after task interpretation and terrain mapping, when you've understood what's being asked AND what's already there but still need user input on judgment calls. Boundaries and scope, edge behavior, trade-offs and calibration, integration with surroundings, hard constraints, audience specifics. Triggers on /clarify, "any clarifying questions", "what should I confirm", "before designing, what's unclear". Also invoke proactively before substantive design or planning work. Designing without resolving ambiguities locks them in silently.
Generate multiple strong design options with explicit tradeoff profiles. Use when the user asks "what are my options", "how should we approach this", "design this", "what's the architecture", "propose some approaches", "give me options", or /design-options. Also trigger proactively during Phase 1 (Understand & Design) of the development workflow. The gate requires presenting several design options with different tradeoff profiles before proceeding.
Map the terrain before designing. Use before any substantive design or planning step. Codebase changes, doc drafting, strategy decisions, anything with non-trivial structure. Triggers on /explore, "explore first", "what's already there", "map the codebase", "survey the landscape". The output is mostly for my own grounding. Only surprises, hard constraints, and gotchas surface to the user. If exploration was uneventful, that itself is the report.
Write a durable handoff for work that's about to ship. Structured PR descriptions, summaries, memos, or memory notes about completed work. Use when creating a PR, wrapping up a session, writing a project summary, drafting documentation about what was built, or composing memory notes for future sessions. Triggers on /handoff, "write the PR description", "summarize what we did", "wrap up the work", "create a summary". Also invoke proactively when shipping substantive work. Opening a PR, wrapping up a session, or handing a thread to a teammate.
Systematically identify how a plan, design, or decision could fail before committing to it. Trigger on /pre-mortem, "what could go wrong", "failure modes", "risk analysis", "what am I missing". Also invoke proactively before finalizing significant design decisions, before deploying with irreversible consequences, or when something feels "too clean". Suspiciously few concerns is exactly when pre-mortem matters most.
Honest self-assessment of the current state of work before shipping. Use when the user asks "how happy are you", "how do you feel about this", "preflight check", "honest assessment", "are you satisfied", "what's the state of things", or /preflight. This is about surfacing what's genuinely good, what's incomplete, what's buggy, and what could be better, with concrete actionable items.