Choose an appropriate test level and use red-green-refactor when test-first work is requested. Use when the user asks for TDD, red-green-refactor, test-first development, integration tests, or help deciding coverage. Prefer integration tests for meaningful behavior across boundaries, unit tests for nontrivial isolated logic requiring little or no mocking, and no new test for trivial behavior adequately covered by types or existing tests.
Expert guidance for Effect-TS architecture, typed error design, Layers, services, concurrency, resource management, and meaningful Effect refactoring. Use when the user explicitly asks for Effect patterns or the task materially changes Effect architecture. Do not use merely because a file imports Effect or a repository uses Effect.
Use for pnpm dependency management, workspace configuration, catalogs, patches, overrides, or package-resolution problems. Do not use for routine `pnpm test`, `pnpm build`, `pnpm lint`, or `pnpm type-check` commands.
Prepare, publish, and maintain GitHub pull requests with template-faithful descriptions, fewer pushes, and CI follow-through. Use when creating, updating, pushing, or checking a GitHub PR, or when the user asks to open, ship, publish, or polish a PR.
Review software implementation plans before execution. Use when a programming plan, technical approach, implementation checklist, or execution brief needs approval, critique, validation, or readiness review before an execution agent starts work.
Selectively stress-test a plan or design by asking only high-leverage questions that could materially change the outcome. Use when user wants to be grilled, stress-test a plan, pressure-test a design, or mentions "grill me".
Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.