RepoPilot

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.

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 changed quiet-fallback candidate in parsed JS/TS or Python; a removed named TypeScript/JavaScript export that a resolved local caller still imports; a Rust public function whose parameter count changes while a proven module-qualified caller keeps the old argument count); 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). Treat quiet-fallback signals as candidates to verify, not proof of harmful behavior, and preserve intentional recovery paths. Signals are evidence, not verdicts; explain one with repopilot_explain_review_signal. RepoPilot uploads nothing. Only a non-empty `verify` array selects configured local checks. Each selected check runs only after one-time form-mode Elicitation consent from a client that negotiated protocol `2025-11-25` and `elicitation.form`; otherwise it is skipped. The prompt shows the command, exact arguments, and w…

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.