Repository Manager

Phase Direction

rm_gates_phase_direction

Run and inspect a two-tier pre-commit gate across repositories: fast stage covers formatters/linters, heavy stage runs pre-push checks like pytest and cargo.

Instructions

Phase direction (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

B3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false, and 'Run' is consistent with a non-read-only operation. The description adds useful context that this actually executes hooks (formatters/linters offline vs. pytest/cargo/network), but it omits auth requirements, side effects on repos, and what the run persists. With annotations present the bar is lower, so a 3 fits.

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?

The purpose is front-loaded in the first sentence and the fast/heavy explanation follows efficiently in two tight sentences. The framing 'The single tool that can actually drive both tiers' is slightly promotional but does not waste much space.

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 tool whose schema references many unlisted modes (audit_fail_fast, status, explain, profile, retest, xdist_apply, phase_direction_here), the description never explains how a mode is selected or which parameters pair with which operation. An output schema exists so return values need no prose, but the operational completeness is a significant 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 all 12 parameters are already documented in the schema, and the description only reinforces the stage semantics rather than adding new meaning. Baseline 3 applies when the schema does the heavy lifting; no extra syntax or default rationale is provided beyond what the schema states.

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 verb and resource (run/inspect the two-tier pre-commit gate) and adds that it is 'the single tool that can actually drive both tiers,' which is a distinguishing claim. However, it never reconciles this with siblings like rm_gates_run, rm_gates_status, and rm_gates_explain, nor does it explain the mode mechanism its own schema references (status/explain/profile/retest/xdist_apply), leaving the actual scope fuzzy.

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

Usage Guidelines3/5

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

It gives real guidance for the stage parameter (fast -> pre-commit hooks, heavy -> pre-push hooks with pytest/cargo), which is a when-to-use signal. But there is no explicit when-not, no prerequisite, and no named alternative among the many rm_gates_* siblings, so the routing guidance is only implied.

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

Deploy Server