Repository Manager

Repos

rm_gates_repos

Run and inspect two-tier pre-commit gates across repositories: fast hooks for formatters and linters, heavy hooks for pytest, cargo, and lock checks.

Instructions

Repos (rm_gates). Run and inspect the two-tier (fast/heavy) pre-commit gate across repos.

The single tool that can actually drive both tiers of the two-tier gate model: stage="fast" exercises a repo's pre-commit-stage hooks, stage="heavy" exercises its pre-push-stage hooks (pytest, cargo, uv lock --check, ...) via pre-commit run --hook-stage <stage>.

Input Schema

Name	Required	Description	Default
`repo`	No	Target one repo's latest gate job for 'status'/'explain'/'profile' (alternative to job_id).
`fleet`	No	For 'audit_fail_fast': scan every repository in the workspace rather than the ones named by 'repos'.
`repos`	No	Comma-separated repo names or absolute paths to target. Omit for 'run'/'retest' to target the whole workspace.
`stage`	No	'fast' -> `pre-commit run --hook-stage pre-commit` (formatters/linters, no network/tests). 'heavy' -> `--hook-stage pre-push` (pytest, cargo, `uv lock --check`, ...). For 'run'/'retest'.	fast
`start`	No	For 'phase_direction_here': directory to resolve the repository from (default: this process's current working directory).
`top_n`	No	'profile' with no job_id/repo: how many slowest hooks to report fleet-wide.
`job_id`	No	Target one gate job for 'status'/'explain'/'profile'.
`dry_run`	No	For 'xdist_apply': report what would change without writing. Defaults to True on purpose -- rewriting ~40 repositories' pre-commit configs must be an explicit choice, never the consequence of omitting an argument.
`summary`	No	'status': compact roll-up (counts + failed set) vs the full per-job detail.
`threads`	No	Parallel workers.
`timeout`	No	Per-repo pre-commit timeout in seconds.
`escalate`	No	'retest' only: when a repo's narrowed retest passes every requested hook, also submit a SECOND job for that repo's full wave (a narrowed pass alone is never sufficient evidence of shippability -- see gate_ledger.is_shippable).

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.5.1Oct 19, 2026

TDQS

C2.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations give a full profile (readOnlyHint=false, idempotentHint=false, openWorldHint=false) so the safety burden is partly lifted. The description usefully discloses that "heavy" runs pytest/cargo/uv-lock and that "fast" avoids network/tests, adding tier semantics beyond the annotations, but it never warns that executing gates can mutate the working tree (formatters rewriting files) despite readOnlyHint=false, nor notes timeouts/parallelism behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and then the tier mechanics; two short passages, no padding. The framing clause "The single tool that can actually drive both tiers of the two-tier gate model" is redundant editorializing that does not earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter dispatcher covering run/retest/status/explain/profile/audit_fail_fast/xdist_apply/phase_direction, the description never explains how an operation is selected, leaving the agent unable to map intent onto the parameters. An output schema existing relieves return-value explanation, but the missing operation model is a major functional gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter is already documented, setting the baseline at 3. The description's stage explanation duplicates the schema's own stage description rather than adding syntax, defaults, or interaction rules, so it does not rise above the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb+resource ("Run and inspect the two-tier (fast/heavy) pre-commit gate across repos") and explains the fast/heavy tier split. However, it gives no help distinguishing this tool from the many sibling gate/status tools (rm_gates_run, rm_gates_retest, rm_gates_status, rm_gates_explain, rm_gates_profile), and the boast that it is "the single tool that can actually drive both tiers" differentiates only vaguely without naming what it supersedes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It partially clarifies when to pick stage="fast" vs stage="heavy" (formatters/linters vs pytest/cargo/uv lock), which is usable. But there is no when-to-use-this-tool guidance versus the numerous sibling gate tools, and no mention of the operation-dispatch concept (status/explain/profile/run/retest/audit_fail_fast/xdist_apply) that the schema parameters clearly rely on.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server