Review a Git change locally: what it touched and which checks it weakened. Use it before finishing work or before a merge. By default it reviews uncommitted work (working tree vs HEAD); pass base (e.g. "origin/main") to review a branch. For a repository health check that is not about one change, use repopilot_scan instead. Returns a JSON report with a decision, findings on changed lines vs the rest, blast radius (files that import the changed files), and deterministic signals grouped by confidence tier (definitely / maybe / noise) in tiered_signals: checks the change weakened (focused or skipped tests, removed tests, tests that lost assertions, new lint/type/coverage suppressions, relaxed CI or tool gates); security-boundary changes (auth, CORS, CI, dependency manifests, committed .env); behavioral changes (network, subprocess, filesystem, env, dependency, migration, or raw SQL added; error handling, an auth check, or a test removed; a removed named TypeScript/JavaScript export that a resolved local caller still imports); algorithmic changes (deeper nesting, a new nested loop, a grown function, new recursion); and taint-lite reachability (HTTP request or process arguments reaching SQL, exec, filesystem-write, or outbound-network sinks in a changed function). Signals are evidence, not verdicts; explain one with repopilot_explain_review_signal. RepoPilot uploads nothing. Only a non-empty verify array runs commands: the configured local checks, which may modify workspace files or contact external systems. Their captured output is bounded and redacted.

Audit a repository, folder, or file for findings across architecture, coupling, code quality, security, and testing, and return the JSON scan report (findings, metrics, risk summary). Use it for a health check that is not about one change. To review what a change touched or which checks it weakened, use repopilot_review_change; for a short Markdown brief to read before editing, use repopilot_context. Explain a returned finding with repopilot_explain_finding. Runs entirely on disk; nothing is uploaded.

Generate a budgeted Markdown brief of the repository (risks, hotspots, structure) to read before editing, especially in an unfamiliar codebase. Use it for orientation. For the full findings as JSON, use repopilot_scan; to review a change, use repopilot_review_change. Pass analysis_handle to make sure the brief still matches an earlier scan or review. Built locally from a scan; no AI service is called and nothing is uploaded.

Explain how RepoPilot treats one file: the role it assigns (for example test, generated, config, or CLI command handler) and the evidence for it, which rules apply, the ordered overrides that change a rule's severity, and whether the default profile would show the result. Use it to understand a file without a report, or to ask why a rule (rule, optionally one detector signal) would or would not fire there. To explain a finding already in a scan or review, use repopilot_explain_finding; for a review signal, use repopilot_explain_review_signal. Reads local files only and returns JSON.

Explain why a finding was reported. Use it when you have a finding_id from repopilot_scan or repopilot_review_change in this session and need to know why it fired or whether it still reproduces. It replays the stored rule decision against the current workspace, returns the full decision trace, and reports whether the decision matched or drifted. For a review signal (signal_id), use repopilot_explain_review_signal; for a file with no finding, use repopilot_explain_file. Local-only.

Explain one signal from a review: where it came from, its confidence tier, whether it can fail a gate, the files it affects, how to verify it, and its limits. Use it after repopilot_review_change, with a signal_id from that report's tiered_signals. For a finding (finding_id in the findings array), use repopilot_explain_finding instead. Reads the stored review only; it runs nothing and changes nothing.