Use when repository behavior is reproducibly wrong and needs causal diagnosis or repair, including errors, broken tests, crashes, regressions, failed contracts, or incorrect runtime behavior. Do not use for general audits or final verification when no active defect is being diagnosed.
Use only when repository work requires a persistent development server, file watcher, long-lived preview, or interactive CLI that must stay alive across later steps. Do not use for one-shot tests, builds, linters, migrations, checks, diagnostics, or release gates.
Use for read-only repository questions that need evidence, including architecture audits, feasibility studies, dependency or caller tracing, impact analysis, implementation-status checks, and proof of how something works. Do not use to implement fixes or for final completion or release verification of changes already…
Use for non-trivial repository features, refactors, migrations, or multi-stage changes where architecture, sequencing, dependencies, or durable task tracking must be decided before implementation. Do not use for small localized changes with an already-clear implementation path.
Use after repository changes, fixes, or release work when the task needs proof of completion, including targeted regression checks, final verification, release readiness, completion audits, or confirmation that implemented behavior works. Do not use for open-ended architecture or feasibility investigation before…
Use when work must inspect, read, edit, test, build, debug, validate, review, or publish a configured repository through Rel.AI, including local UI or process execution. Do not use when the request needs no repository or local runtime access.
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: