llm-plugins

Use when reviewing a completed implementation holistically - a finished branch, a completed plan step, or a diff before PR. Reviews every changed line against the implementation plan (if one exists) and high engineering standards across seven dimensions, verifies tests by deliberately breaking crucial code, and emits severity-classified findings with a PASS/FAIL verdict.

Use when performing a holistic code review of an implementation - routes to codex:rescue or falls back to a direct subagent, both running the house-style:holistic-review skill

ALWAYS use before any implementation work, review, or planning: designing, writing, editing, refactoring, debugging, reviewing, or generating source code, tests, scripts, config-as-code, or behavior-affecting files. This is a baseline engineering skill and should be invoked even when a more specific language, framework, testing, or database skill also applies.

Use when asked to write, draft, file, or open a GitHub issue - mandates exploring the relevant code to understand the whole problem space, reasoning any proposed solution, and structuring the issue with summary, what/why, references, nuances, open questions, and acceptance criteria. Adds professionalism and no-sensitive-info discipline for public repos.

Use when creating, editing, triaging, or cleaning up GitHub issues - a mechanical pass that verifies the title is accurate and current, labels/assignees/milestone are correct, and the body is valid, well-formed markdown, all via the gh CLI. Does not judge content quality.

Use when running Python, installing Python packages, creating virtualenvs, or executing Python CLI tools - mandates uv/uvx over direct python/pip/pipx/venv calls when uv is installed, and gives the drop-in command mappings

Use when the user provides a reference implementation (URL, repo path, branch, file) plus a verb like "use", "copy", "adapt", "port", "model after" - mandates fetching/reading the reference before designing, and lifting the structure rather than reimagining it.

Use when adding or modifying non-trivial code - requires happy-path AND sad-path tests covering every return permutation, blocks declaring "done" if production code grew without matching test additions.

Use when editing rendered UI, dashboard, chart, or any visual artifact (Grafana, Terraform-generated panels, frontend components, plot output) - blocks declaring "done" without an external verification artifact.

Use for executing implementation plans

Set up and run an autonomous experiment loop for any optimization target. Gathers what to optimize, then starts the loop immediately. Use when asked to "run autoresearch", "optimize X in a loop", "set up autoresearch for X", or "start experiments".

Use when performing a blank-slate codebase review -- orchestrates the scout, file sampling, fan-out decision, reviewer dispatch, and output formatting pipeline

Use for creating tightly scoped implementation plans

Compute and interpret MAD-based confidence scores for experiment results. Use when logging experiment results after 3+ data points to determine if improvements are real or within noise.

Git commit and revert patterns for autoresearch experiments. Use when keeping or discarding experiment results to manage git state correctly.

Parse METRIC output lines, infer units, and track primary vs secondary metrics. Use when processing experiment output from autoresearch.sh.

Manage autoresearch.jsonl logging, session initialization, segment tracking, and session recovery. Use when starting, resuming, or recording experiments.

Use when searching markdown knowledge bases, documentation, or notes for relevant context - provides qmd CLI syntax for keyword, semantic, and hybrid search across indexed collections

Use when searching for or transforming code patterns structurally - provides ast-grep CLI syntax, metavariable patterns, and language-specific examples for precise AST-based code search and rewriting

Use when invalid data causes failures deep in execution - validates at every layer data passes through to make bugs structurally impossible rather than temporarily fixed

Use when writing database access code, creating schemas, or managing transactions with PostgreSQL - enforces transaction safety with TX_ naming, read-write separation, type safety for UUIDs/JSONB, and snake_case conventions to prevent data corruption and type errors

Use when writing tests for serialization, validation, normalization, or pure functions - provides property catalog, pattern detection, and library reference for property-based testing

Use when writing documentation, guides, API references, or technical content for developers - enforces clarity, conciseness, and authenticity while avoiding AI writing patterns that signal inauthenticity

Use when writing or reviewing tests - covers test philosophy, condition-based waiting, mocking strategy, and test isolation