Skip to main content
Glama
saidsef

GitHub PR Issue Analyser

by saidsef

Github Rerun Job

github_rerun_job

Re-run a GitHub Actions job and all dependent jobs without adding a commit, so you can retry failed CI checks while preserving the original run's privileges.

Instructions

Re-runs one Actions job and every job that depends on it, without a commit on the branch. Each call starts another attempt, so calling it twice runs the job twice. A re-run keeps the privileges of the first run, so a Dependabot job that failed on its read-only token wants github_create_empty_commit instead. See #503.

Workflow and conventions: github_get_skill('pr-management').

Input Schema

NameRequiredDescriptionDefault
job_idYesThe check run's id, as github_get_pr_status_checks reports it
repo_nameYes
repo_ownerYes
enable_debug_loggingNoRun the job again with runner and step debug logging

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv54.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses cascading behavior (dependent jobs also rerun), that privileges are inherited from the first run (a real auth caveat), and the concrete consequence of non-idempotency. These match idempotentHint=false rather than contradicting it, and the privilege-retention note is information an agent cannot get from any structured field.

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 action and scoped tightly across four short sentences, each carrying real signal. The bare 'See #503' reference is opaque to an agent and is the one element that doesn't earn its place.

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

Completeness5/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 needn't be described. What remains for a mutating, non-idempotent, open-world tool — cascading effects, privilege inheritance, repeat-call risk, and the correct fallback tool — is all present.

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 coverage is 50%: job_id and enable_debug_logging are documented, while repo_owner and repo_name are not, though they follow obvious GitHub naming. The description identifies the target as 'one Actions job' but adds no syntax, id format, or guidance on the undocumented parameters, so it neither compensates for nor worsens the gap.

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

Purpose5/5

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

States a specific verb and resource ('Re-runs one Actions job') and extends the scope precisely to 'every job that depends on it, without a commit on the branch.' It also distinguishes itself from the sibling github_create_empty_commit for the Dependabot case, so an agent can pick between them without opening either schema.

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

Usage Guidelines5/5

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

Gives an explicit when-not with a named alternative: a Dependabot job that failed on its read-only token should use github_create_empty_commit instead. It also flags the repeat-call hazard ('calling it twice runs the job twice'), which tells the agent when not to invoke it again.

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