Repository Manager

Profile

rm_gates_profile

Profile pre-commit and pre-push gate hooks across repositories to pinpoint the slowest checks and speed up CI feedback.

Instructions

Profile (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 declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is partly carried by structured data. The description adds real behavioral context beyond annotations by spelling out what each stage actually executes (pre-commit formatters/linters with no network/tests vs pre-push pytest/cargo/uv lock), but it never discloses the write/mutation surface implied by the non-readonly annotation.

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?

Two sentences with little waste; the purpose statement is front-loaded before the stage-model detail. The redundant 'Profile (rm_gates).' opener and the over-strong 'single tool' claim cost a point, but the body is reasonably tight.

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?

An output schema exists, so return values need not be explained, but for a 12-parameter tool the description leaves a major gap: parameter descriptions repeatedly reference modes ('status', 'explain', 'profile', 'audit_fail_fast', 'run', 'retest', 'xdist_apply') with no corresponding mode/action parameter or explanation, so an agent has no mental model of how this tool's behavior is selected.

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 the schema already documents all 12 parameters and the baseline is 3. The description contributes additional meaning for the stage enum by mapping 'fast'/'heavy' to concrete hook stages, but says nothing about the many mode-scoped parameters whose descriptions reference verbs not present in this tool's flow.

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 names a resource (the two-tier fast/heavy pre-commit gate) and a verb, but 'Profile' is never actually defined — the text emphasizes running gates rather than profiling hook performance, which is what top_n ('slowest hooks to report') implies. The claim that this is 'the single tool that can actually drive both tiers' conflicts with the sibling rm_gates_run and rm_gates_retest, muddying rather than clarifying differentiation.

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?

There is no statement of when to choose this tool over rm_gates_status, rm_gates_explain, rm_gates_run, or rm_gates_retest. The parameter descriptions reference modes ('status', 'run', 'retest', 'xdist_apply'), hinting that alternatives exist, but the description never explains which mode belongs to this tool or when to use it.

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

Deploy Server