claude-plugins

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.

Capture durable lessons from a session before they fade. What surprised you, what friction repeated, what should update CLAUDE.md or notes, what insight would help future-you. Use at session end after work has shipped or reached a natural pause. Triggers on /reflect, "what did we learn", "lessons learned", "session retro", "what should we save", "should we update CLAUDE.md". Also invoke proactively at the end of substantive work or at a natural session pause, while the friction and surprises are still in context.

Get an independent review of your thinking before presenting it to the user, from the strongest independent channel the session offers (a full-transcript advisor tool if available, fresh-context reviewers otherwise). Use when you need a fresh take, alternative approaches, or independent validation on a design, plan, code, or any non-trivial decision. Triggers on "second opinion", "another perspective", "ask fable", "independent review", or /second-opinion. Also trigger proactively during the design and plan review phases, before presenting options or a spec.

Audit error handling in local code changes for silent failures, inadequate error feedback, and inappropriate fallback behavior. Triggers on /silent-failures, "check error handling", "find silent failures", "audit fallbacks", "review error handling". Also invoke proactively right after writing or modifying error handling. Try-catch blocks, callbacks, fallback logic, retries, or any code that could swallow an error.

Write the implementation spec (the structured document that drives execution). Use after design is chosen (e.g., via /design-options) and before writing code. Triggers on /spec, "write the spec", "draft the implementation plan", "scope this out". Also invoke proactively when starting non-trivial implementation. A spec makes success checkable and catches scope creep and missed reuse before code is written.

Before flipping a previously-stated position under pressure, restate its strongest form and the goal it served, then check whether the triggering argument refutes the core on the same goal, not just a decorative argument or a different axis. Self-invoke when about to flip a stated position. Trigger manually on "steel man your position", "hold the line", "are you sure", /steel-man-own-position.

Write code, comments, tests, or commit messages that read as if the project's own maintainer wrote them, so a contribution is accepted as native rather than rejected as foreign. Use when writing into a codebase or document you don't own: a pull request or patch to an upstream project, a fix matching a specific maintainer's style, a change that has to blend into a teammate's module. Triggers on /understudy, "match the style", "make it look like theirs", "fit the house style", "will this look out of place in their repo", or before opening a PR against someone else's project. Also invoke proactively whenever you're about to write into code or prose whose style isn't your own. A foreign-looking contribution is a cost to the maintainer even when it's correct, and the cheapest time to match their hand is before you've written in yours.

Identify and verify unverified claims in your own responses. Especially LOAD-BEARING ones: claims about to drive a design decision, commit, diagnosis, or user-visible recommendation. Self-invoke proactively when a claim is about to become the foundation for action. Also trigger when you catch yourself using hedging language ("likely", "probably", "presumably", "appears to", "seems like"). That hedging is a signal you're uncertain but might present the claim anyway. Trigger manually on "verify claims", "prove it", "back that up", "check your claims", or /verify-claims.

Black-box verification of any agent output. Code, documents, presentations, reports, configs. Examine from the consumer's perspective and show evidence. Use when the user says "verify", "prove it works", "test this end-to-end", "show me it works", "check the document", "does it actually work", or /verify-result. Also trigger proactively after completing implementation (Phase 4 of the development workflow). Verification means using/examining the output as a consumer would, not re-reading what was produced.