agents-library

Triage all open GitHub pull requests and locally batch-merge the trivial ones onto one branch the user names. Use when the user wants to sweep or bulk-merge the PR queue, "clean up the PR queue", collect the easy/trivial/low-risk PRs, or assemble several PRs onto one branch. Requires the `gh` CLI; merges are local only — never pushes, never closes PRs on GitHub. Do NOT use to review a single PR or the current branch (use review-pr) or to triage GitHub issues (use triage-issues).

Explain how a codebase is shaped: the whole repository, one subsystem (path/glob), or a single feature/flow traced end to end. Produces a skimmable orientation brief with file:line references; can optionally write it to ARCHITECTURE.md. Use when the user wants to understand or onboard onto an unfamiliar codebase, "explain how this works", map the architecture, or trace how a feature/endpoint flows. Read-only — it explains, it never judges or edits. Do NOT use to review, critique, or improve code (use review-pr for the branch diff, simplify-sweep for cleanup opportunities). No `gh` or remote required.

Install the library's stack-agnostic maintenance agents (architect, deadwood, docbot, refactor, sentinel, testforge, uidesigner, uxpolish) into the current project and schedule them to run periodically — once per week by default, staggered so at most one agent runs at a time. Copies the chosen agent definitions into .claude/agents/, seeds their journals, and wires the schedule through the best available mechanism (Claude Code scheduled agents, a GitHub Actions workflow, or local cron). Use when the user wants to "install the agents", put a repo on automatic/recurring maintenance, or schedule the library's agents weekly/daily/monthly. Do NOT use to run one agent a single time right now (just act as that agent directly), to review the current branch (use review-pr), or to install this plugin into Claude Code itself (that's /plugin).

Review the visual design of a UI — hierarchy, spacing, typography, color/contrast, dark mode, depth, interaction states — judged against the project's own design tokens, for a view/component, a path/glob, or the branch diff; then optionally apply fixes behind the project's lint/build gate. Use when the user wants a design pass, a critique of how a screen looks, or an audit of visual hierarchy / spacing / typography / color / dark mode. Do NOT use for conversion, persuasion, or metric-moving flow reviews (use review-ux-psychology) or a general code-quality review of the diff (use review-pr). No `gh` or remote required.

Review the current branch's local diff across ten quality domains (correctness, architecture, dead code, docs, refactor, testing, UX polish, visual design, security, conventions), with every finding independently verified to screen out false positives; then optionally apply fixes behind the project's lint/test gate. Use when the user wants to review a PR, a branch, or their changes before merging — "review my changes", "check what I just built", a pre-merge / pre-PR review. Works on the local diff before a GitHub PR exists; no `gh` or remote required. Do NOT use for whole-repo cleanup (use simplify-sweep), a visual-only design pass (use review-design), conversion/flow psychology (use review-ux-psychology), or explaining a codebase (use describe-codebase).

Review a flow's decision architecture — defaults, progress, value-before-ask, ownership, loss/gain framing, price anchoring — against behavioral psychology, to move a named product metric (signup, activation, trial-to-paid, checkout completion, retention). Targets a screen or flow (onboarding, signup, checkout, pricing, a form), a path/glob, or the branch diff; every finding names its principle and the metric it moves, is verified against the real code/flow, and fixes apply behind the lint/build gate. Use when the user wants to lift conversion or a metric, reduce drop-off/friction in a flow, critique onboarding/signup/checkout/pricing, or audit a form for decision fatigue. Do NOT use for how the UI looks — hierarchy, spacing, color (use review-design) — or general code review (use review-pr). No `gh` or remote required.

Survey a target — whole repository (default), a path/glob, or the branch diff — for behavior-preserving simplifications: duplication, dead code, deep nesting, unclear names, over-engineering, stale docs; then optionally apply them behind the project's lint/test gate. Use when the user wants to simplify, declutter, or tidy the codebase, reduce complexity, or hunt duplication and dead code across the whole project. Never fixes bugs or changes behavior. Do NOT use for a full quality review of the branch diff — bugs, security, tests (use review-pr) — or to explain how the codebase works (use describe-codebase). No `gh` or remote required.

Triage the project's open GitHub issues into a ranked action plan: duplicates clustered, easy wins backed by code-grounded evidence, needs-info drafts, larger work classified. Only after per-action approval it applies labels, posts comments, closes duplicates, and fixes approved easy wins — one PR per issue, never committing to the default branch. Use when the user wants to triage or groom the issue tracker/backlog, find duplicate issues, find and fix easy wins or good first issues, or label open issues. Requires the `gh` CLI. Do NOT use for pull requests (use batch-merge-prs for the PR queue, review-pr for the current branch).