Use when a ticket is about a slow or heavy frontend — page load, bundle size, Core Web Vitals (LCP, INP, CLS), a janky list, re-render storms, large images or fonts — and the fix must be measured in the browser before and after with the same tooling, not guessed. Invoke for "the page is slow", "reduce the bundle"…
Use when a ticket adds or reshapes client-side state — where data lives, how it flows between components, server cache versus UI state, a store, context, URL state, persisted drafts, optimistic updates, multiple tabs — and the result must keep one source of truth per fact and avoid the prop-drilling or global-store…
Use when a ticket needs tests for UI code — a component's behaviour, a hook, a form, a page's states, accessibility assertions, visual regressions — below the full browser end-to-end level, using the repo's component test runner and testing-library conventions. Invoke for "add tests for the component", "cover the…
Use when a ticket adds user-facing text or must support more than one language, locale, or region — translations, plurals, dates and numbers, currencies, right-to-left layout, time zones — and the implementation must externalise every string, use ICU/CLDR plural rules, format by locale with the platform's APIs, and…
Use when a ticket makes an operation safe to repeat or adds retries — payment or order creation that must not double-charge, a webhook handler that receives duplicates, a client retry policy, an outbound call to a flaky dependency — and the design must guarantee exactly-once effect under at-least-once delivery. Invoke…
Use when a ticket adds or changes Kotlin code — Android, Ktor/Spring services, multiplatform modules — and it must follow the repo's Kotlin conventions — the Kotlin coding conventions, null-safety without !!, immutability by default, coroutines and Flow used with structured concurrency and correct cancellation, sealed…
Use as a REVIEW LENS when judging another agent's diff that changes a database schema or data — a migration, a backfill, a dropped or renamed column, an index, a constraint — for irreversibility, locking, data loss, and deploy-order hazards before recommending approval. Invoke on every review whose diff touches a…
Use when a ticket adds or changes an HTTP API and the repo keeps (or should keep) a machine-readable contract — an OpenAPI/Swagger document, JSON Schemas, generated clients or types — that must stay in lockstep with the routes and be validated in CI. Invoke for "document the endpoint", "update the OpenAPI spec", "the…
Use when a ticket makes the system call other systems on events — outbound webhooks, notifications to a partner URL, callbacks — and the delivery must be signed, retried safely, observable, and impossible to turn into a server-side request forgery. Invoke for "notify the customer's endpoint", "add a webhook for X"…
Use when a ticket exposes a list — an API collection endpoint, a table in the UI, an export — with paging, sorting, filtering, or search, and the result must be stable under concurrent writes, bounded in cost, and consistent with the repo's existing list conventions. Invoke for "list the X", "add pagination", "let…
Use when a ticket is about speed or resource use — a slow endpoint, a hot loop, memory growth, a test suite that takes too long, "make X faster" — and the change must be driven by a measurement, not a hunch, and proven with a before/after number under the same conditions. Invoke for latency, throughput, CPU, memory…
Use as a REVIEW LENS when judging another agent's diff for performance regressions — N+1 queries, unbounded loops or fan-outs, missing indexes, blocking calls on hot paths, unbounded memory, bundle growth, needless re-renders — before recommending approval. Invoke on every review of a ticket that touches data access…
Use when a ticket's correctness is about invariants over many inputs — parsers and serialisers, encoders/decoders, arithmetic and date logic, sorting and merging, state machines, concurrent operations and interleavings — anything with "for all inputs" in its contract, where example tests would miss the edge case…
Use when a ticket protects a surface from overload or abuse — per-user or per-key request limits, login-attempt throttling, a quota, backpressure to a downstream, "someone is hammering the API" — and the limit must be correct across instances, communicated to clients, and never lock out legitimate use. Invoke for any…
Use when a ticket adds or changes React code — components, hooks, effects, context, actions and forms, server components, suspense boundaries — and it must follow the Rules of React and modern React 19 idioms (pure render, effects only for synchronisation, derived state computed not stored, stable keys, composition…
Use when a ticket adds or changes Ruby code — Rails apps, gems, Rake tasks — and it must follow the repo's Ruby conventions — the Ruby Style Guide, small objects with clear responsibilities, Rails idioms where Rails is present (migrations, validations, scopes, jobs), thread-safe code under Puma and Sidekiq, no…
Use when a ticket adds or changes Rust code and it must follow the repo's Rust conventions — ownership and borrowing done right, explicit error handling with Result and typed errors, no needless unsafe or clones, idiomatic traits and iterators per the Rust API Guidelines, async/tokio used without blocking or…
Use when a ticket adds or changes time-driven work — a cron, a nightly report, a periodic cleanup, a poll every N minutes, a retention sweep — and the job must run exactly as intended across time zones, deployments, and multiple instances without overlapping or being silently skipped. Invoke for "run X every night"…
Use as a REVIEW LENS when judging another agent's diff for security defects — injection, broken authentication or authorization, secrets in code, unsafe deserialisation, SSRF, path traversal, missing validation, mass assignment, insecure defaults — before recommending approval. Invoke on every review of a ticket that…
Use when a ticket adds or changes shell scripts — bash automation, CI steps, install or release scripts, git hooks, Makefile recipes — and they must follow the Google Shell Style Guide, be safe under set -euo pipefail (knowing its caveats), quote every expansion, clean up temp files and locks, stay portable across GNU…
Use when a ticket is about a slow or expensive database query — a timeout, an N+1, a missing index, a report that locks the table, "the list page takes 8 seconds" — and the fix must be driven by the query plan and proven with before/after timings on realistic data. Invoke for any query optimisation, index addition, or…
Use when a ticket adds or changes what a service records about itself — log lines, metrics, spans, correlation ids — and the output must be structured, correlated across processes, safe (no secrets or personal data), and useful to the person debugging at 3am. Invoke for "add logging for X", "we can't see why Y fails"…
Use when a ticket adds or changes Swift code — iOS/macOS apps, SwiftUI or UIKit, server-side Swift — and it must follow the repo's Swift conventions — the Swift API Design Guidelines, value types and protocols, optionals handled without force-unwraps, Swift 6 strict concurrency (async/await, actors, Sendable) used…
Use when tests need realistic data — users, orders, records, files — and the ticket or the existing suite calls for fixtures, factories, builders, seed data, temp directories or test databases that stay readable and isolated. Invoke for "add a factory for X", "the tests share state", "set up a test DB", or when you…
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: