jagreehal-claude-skills

Automates real browsers from the command line using a ref-based snapshot-then-interact workflow. Use when you need to drive a live browser, navigating pages, filling and submitting forms, clicking buttons, taking screenshots, scraping or extracting data, testing or logging into web apps, mocking network requests, or verifying responsive layouts. Triggers include "open a website", "fill out this form", "take a screenshot", "scrape this page", "test this web app", "log in to a site", "automate browser actions", or any task requiring programmatic web interaction via the agent-browser CLI.

Detects question-shaped input and forces a literal answer before any action. Use when the user's message contains "?" or trigger patterns like "why did you…?", "will that work?", "have you considered…?", "shouldn't we…?", "doesn't that…?", "is that correct?", especially when the question challenges a decision, requests an assessment, or could be misread as criticism.

Builds production-ready HTTP APIs with thin handlers, consistent error envelopes, health/readiness checks, CORS, idempotency, rate limiting, and graceful shutdown. Use when designing or implementing HTTP endpoints, writing orpc route factories, defining Zod request/response schemas, mapping domain errors to status codes, or adding operational concerns (health checks, X-Request-ID, Retry-After) to a TypeScript API.

Guides completion of development work by verifying tests, presenting structured merge/PR/keep/discard options, and executing the chosen cleanup. Use when implementation is complete and tests pass, when wrapping up a feature branch, or when deciding how to land or discard work.

Traces a code execution path with file:line references and an execution diagram before any change is made, forcing real understanding of fn(args, deps) flows, Result propagation, and workflow composition. Use before fixing a bug, implementing a feature, refactoring, or starting a TDD cycle, whenever you are about to change non-trivial code.

Receives code review feedback through technical verification rather than performative agreement or blind implementation. Use when receiving review comments, before implementing reviewer suggestions, when feedback is unclear, or when a suggestion may be wrong for this codebase.

Enforces extreme brevity and high signal-to-noise ratio so every word justifies its existence. Strips filler phrases, preambles, announcements, and unnecessary elaboration. Use when writing any response, commit message, PR description, README, implementation plan, or status update, when you catch yourself opening with "I'll help you with that" or "Let me explain", or when output is drifting into paragraphs where a list or table would carry more information in fewer words.

Forces honest, calibrated confidence assessment instead of vague certainty. Expresses confidence as a percentage, shows the evidence behind it, explains every gap below 100%, and gathers more evidence before concluding when possible. Use when about to state a root cause, diagnosis, or conclusion ("the problem is", "definitely", "clearly the issue", "complete clarity"), when an answer would mislead if it looked more certain than it is, or any time you're presenting an investigation result the user will act on.

Validates application configuration once at startup with Zod or node-env-resolver, injects it via deps, and keeps secrets in memory instead of environment variables. Use when loading env vars, building a config schema, wiring secret managers (AWS Secrets Manager, ephemeral credentials), deciding where config is read, adding secret scanning to CI, or testing code that depends on config.

Creates well-formed, self-contained tasks from a template that any engineer can implement without prior context or follow-up questions. Use when creating tasks, defining work items, breaking down a feature or PRD, or converting requirements into actionable, vertically-sliced work.

Acts as a skeptical engineering peer rather than an agreeable assistant. Verifies before agreeing, challenges pattern violations immediately, proposes instead of asking, and gives factual assessment with no praise or enthusiasm. Use when the user pushes back ("you made a mistake", "the test is wrong"), when reviewing or writing code that may violate fn(args, deps), Result types, validation-boundary, or testing conventions, when tempted to answer "you're absolutely right" before checking, or any time the default to please would produce worse engineering than honest challenge.

Selects chart types, encodings, rendering technology, and layout algorithms so a visualization communicates accurately and accessibly. Use when building charts, graphs, or dashboards, choosing between SVG/Canvas/WebGL, picking a graph layout, or making a visualization colorblind-safe and screen-reader accessible.

Debugs failures by gathering evidence before proposing fixes, enforcing the Iron Law that no fix happens without root-cause investigation first. Use when encountering any bug, test failure, unexpected behavior, intermittent failure, or "it works locally but fails in CI", before changing any code.

Explores user intent, requirements, and trade-offs through collaborative dialogue before any code is written, producing a validated design document. Use before creating features, building components, or making significant behavior changes. Use when requirements are ambiguous, when an architectural decision is imminent, or when you are tempted to start coding without a shared understanding of what "done" means.

Applies software design rules beyond syntax (fail-fast over fallbacks, explicit over implicit, composition over inheritance, illegal states unrepresentable) and runs an 8-dimension design analysis on code. Use when reviewing or refactoring code for design quality, naming, coupling, type safety, or when deciding how to structure functions, types, and modules.

Frames documentation around reader needs using eight quality dimensions, document-type requirements, and a review checklist. Use when writing or reviewing READMEs, API references, tutorials, changelogs, or error messages, when documenting a public API, or when judging whether docs are good enough to ship.

Enforces the fn(args, deps) pattern, business logic as functions with explicit dependency injection instead of classes. Use when writing or refactoring TypeScript business logic, replacing service classes, deciding how to structure dependencies, setting up a composition root, or making functions testable with mocked collaborators.

Isolates feature work in a dedicated git worktree that shares the repository but lives in its own directory, with directory selection, gitignore safety checks, project setup, and baseline test verification. Use when starting feature work that needs isolation from the current workspace, before executing a multi-task implementation plan, when running parallel work on different branches, or for experimental work that might be discarded.

Creates bite-sized, TDD-ordered implementation plans with exact file paths, complete copy-pasteable code, and explicit verification steps, written for an executor with zero prior context. Use when you have an approved design or clear requirements for a multi-step task and are about to write code. Use before features with 3+ steps, complex refactoring, or any change that coordinates edits across multiple files.

Separates technical work into three explicit, non-overlapping modes (LEARNING to build understanding, INVESTIGATION to diagnose a problem, SOLVING to implement a fix) and prevents drifting between them without the user's consent. Use when analyzing how a system works, debugging or diagnosing a specific failure, or implementing a fix, and especially when a request chains phases with "do X, THEN Y". Every message is prefixed with its mode; mode transitions require user confirmation.

Treats a question as a question, not as a hidden instruction, then answers honestly and stops before acting on assumed intent. Use when the user asks "will that work?", "have you considered X?", "is this the best approach?", "what happens if Y?", or otherwise probes your reasoning, and you feel the pull to read it as "change direction" and start doing instead of answering.

Makes functions observable with the trace() wrapper, structured logging (Pino), and OpenTelemetry, keeping telemetry orthogonal to business logic. Use when adding tracing or spans to fn(args, deps) functions, emitting structured JSON logs, redacting sensitive data, applying OpenTelemetry semantic conventions, correlating logs with traceId/spanId, or emitting canonical wide-event log lines with autotel.

Dispatches one focused agent per independent problem domain for concurrent investigation. Use when facing 2+ independent failures or tasks with no shared state, when sequential investigation wastes time, or when work can be safely parallelized across agents.

Enforces architectural patterns at build time with ESLint so violations fail CI instead of relying on convention. Use when configuring eslint.config.mjs, blocking domain code from importing infra, requiring object parameters, preventing server code from leaking into client bundles, choosing ESLint plugins (boundaries, prefer-object-params, no-server-imports), or constraining AI-generated code.

Validates that a system holds up under pressure using progressive k6 load profiles, trace correlation, SLO thresholds, and chaos injection. Use when verifying throughput or latency under load, finding breaking points, proving resilience patterns work, or catching performance regressions in CI.

Rewrites long policy, compliance, HR, legal, operational, or governance documents into accurate, digestible story-led explanations. Use when the user wants a policy document made more relatable, scenario-based, easier to understand, or turned into realistic examples without watering down the original content.

Builds portable, testable React applications using Container/View separation, dependency injection, and framework-agnostic architecture. Use when creating or refactoring React components, wiring data fetching with React Query, parsing URL state with Zod, handling forms with react-hook-form, or when components mix framework imports (next/navigation, useRouter, useParams) with presentation. Use when output must be Storybook-friendly, accessible, and survive a framework migration.

Makes React components testable and storybookable by keeping them dependent only on props and injectable context, never on API, router, or globals, so a story and a test come almost for free. Use when building or refactoring a component and you want a matching story and test, setting up renderWithProviders or a test-only provider, sharing one MSW handler/fixture set across Vitest + Storybook + dev, or writing React Query hooks with a key factory that surface explicit status.

Researches and validates answers before presenting them, so the user never has to do homework you could have done yourself. Use when about to recommend a command, library, or config; when tempted to ask "what version/framework/database are you using?"; when a solution is untested ("this should work"); or when the answer is a verifiable fact rather than a user preference.

Adds retry, timeout, jitter, and circuit-breaker patterns at the workflow level so business functions stay clean. Use when wrapping flaky operations (HTTP calls, DB reads, external APIs) with retry/backoff, setting per-attempt timeouts, deciding which errors are retryable, protecting against retry storms and double-charges, or composing step.retry/step.withTimeout in a @jagreehal/workflow workflow.

Models expected failures as values with Result<T, E> instead of throwing, and composes them with railway-oriented workflows. Use when a function can fail in expected ways (not found, validation, conflict, timeout), when designing error types, when chaining fallible operations, when mapping errors to HTTP status codes, or when deciding whether to throw or return a Result.

Manages a persistent, multi-session task workflow through a strict state machine backed by files in the project's .claude/ directory. Use when resuming work across sessions, when the user says "continue" or "create a plan"/"setup tasks", or when work must survive a session restart, context compaction, or handoff. Every message announces its state; tasks never auto-advance and TodoWrite is never used.

Guides authoring of skills that Claude can discover and apply, covering description optimization, structure patterns by skill type, progressive disclosure, testing, and frontmatter rules. Use when creating, editing, or reviewing a SKILL.md, deciding how to structure a skill, or fixing a skill that isn't being discovered or followed.

Evaluates and improves technical articles against the SPINE framework (Stakes, Point, Illustration, Nuance, Exit, plus Voice and Clean) to verify they carry a real insight, prove it, and land. Use when writing or reviewing blog posts, tutorials, technical documentation, or any draft article, or when scoring an article's quality.

Creates Storybook "user journey" storyboards that demonstrate end-to-end React flows (page/screen stories, MSW API mocking, interaction play functions, optional test-runner CI wiring). Use when the user wants Storybook demos of whole flows rather than atomic components, e.g. signup/login/checkout/onboarding, with mocked APIs and scripted interactions, or mentions "storybook storyboard", "user journey stories", "MSW fake API in storybook", "play function", or "show a whole page in storybook".

Configures TypeScript compiler and type-level patterns beyond strict:true to make unsafe code fail at compile time. Use when setting up or hardening tsconfig.json, choosing compiler flags (noUncheckedIndexedAccess, exactOptionalPropertyTypes, verbatimModuleSyntax, erasableSyntaxOnly), eliminating any/as, installing ts-reset or type-fest, writing branded/template-literal/conditional types, or wiring @typescript-eslint strict-type-checked.

Structures dictated content into clear documents while preserving the author's voice, asking clarifying questions and flagging gaps. Use when helping someone draft, organize, or tighten writing (planning docs, decision docs, proposals, meeting notes) where the author owns the ideas and the tool owns the structure.

Designs systems for change through explicit trade-off analysis, pattern selection by context, and ADR-documented rationale. Use when choosing an architecture (monolith vs microservices), selecting a database, planning for scale or resilience, designing APIs or event flows, or recording a significant technical decision.

Drives implementation through a strict TDD state machine that forbids production code without a failing test first. Use when implementing any feature, fixing any bug, or changing behavior with test-first discipline; use when you need enforced red-green-refactor with Result types and dependency injection.

Structures a test suite as a pyramid of unit, integration, load, and chaos tests where dependency injection enables typed mocking without module interception. Use when deciding what kind of test to write, setting up vitest with typed mocks, naming test files by type, or wiring database guardrails and Faker test data.