Stage Payload Reverts

Stage Payload Reverts

This skill automates the full revert-staging workflow for payload regressions: creating TRT JIRA bugs, opening revert PRs, and triggering payload validation jobs.

When to Use This Skill

Use this skill when revert candidates have already been identified with high confidence by the payload-analysis skill. The caller passes all required context in-memory — this skill does not perform its own analysis.

Inputs (passed in-context by the caller):

• results_yaml_path: Path to the payload results YAML file (e.g., ./payload-results-{tag}.yaml)
• payload_tag: The full payload tag being analyzed
• version, stream, architecture: Parsed from the payload tag
• release_controller_url: URL to the payload on the release controller
• revert_candidates: List of PRs to revert, each with:
  • pr_url, pr_number, component, confidence_score, rationale
  • originating_payload_tag: The payload where this candidate PR first caused failures
  • failing_jobs: List of {job_name, prow_url, is_aggregated, underlying_job_name}

Required Skills

Before starting, you MUST load the following skills (they define output schemas used when updating results):

1. payload-results-yaml — schema for the payload results YAML file
2. payload-autodl-json — schema for the autodl JSON data file

Prerequisites

1. GitHub CLI (gh): Installed and authenticated
2. JIRA MCP: Configured for creating TRT issues (validated in Step 1)
3. Repository Access: User must have push access to their fork of each target repository

Implementation Steps

Step 1: Check Jira MCP Availability

Before launching subagents, verify the Jira MCP server is working by attempting a lightweight read-only Jira MCP call (e.g., a simple JQL search or fetching the current user profile — use whichever Jira MCP tool is available).

If the call fails (tool not found, connection error, authentication error, or any other error), stop and inform the user. Present two options:

1. Fix and retry: "Fix your Jira MCP configuration and tell me when it's working. I'll pick up where I left off."
2. Continue without Jira: "Continue without creating Jira issues. I'll open the revert PRs and trigger payload jobs, and give you the details to create Jira issues yourself afterward."

Wait for the user to choose. If no user input is available (e.g., running autonomously), default to option 2. If the user chooses option 1, re-run the check when they say it's ready.

Step 2: Launch Subagents

For each qualifying revert candidate, launch a parallel subagent (do NOT set the model parameter). Each subagent executes Steps 3–5 in order.

Step 3: Create TRT JIRA Bug (with idempotency check)

If Jira MCP was unavailable in Step 1 and the user chose to continue without it, skip Jira creation and proceed to Step 4. After all subagents complete, print the Jira issue details for each candidate (project, type, summary, description, and labels as described below) so the user can create them manually.

Preflight: Before creating a new issue, search for an existing TRT bug for this PR:

jql: project = TRT AND labels = "trt-incident" AND description ~ "{pr_url}" ORDER BY created DESC

Use the Jira MCP search tool with this JQL. If a matching issue is found, reuse its key and URL — skip creation and proceed to Step 4.

Create (only if no existing issue found): Use the Jira MCP create issue tool:

• project_key: "TRT"
• issue_type: "Bug"
• summary: A concise description of the problem (the symptom, not the solution). Summarize which jobs are failing and the failure mode. For example: "aws-ovn and aws-ovn-upgrade jobs failing with KAS crashloop in {stream} {architecture} payload". Do NOT use "Revert ..." as the summary — the revert is the action, not the problem.
• description (Jira wiki markup):

  h2. Payload Regression
  
  PR {pr_url} is causing blocking job failures in the {stream} {architecture} payload.
  
  h2. Evidence
  
  * Payload: [{payload_tag}|{release_controller_url}]
  * Failing blocking jobs:
  ** [{job_name_1}|{prow_url_1}]
  ** [{job_name_2}|{prow_url_2}]
  * Originating payload: {originating_payload_tag}
  * {rationale}
  
  h2. Action
  
  Revert PR {pr_url} to restore payload acceptance.

• additional_fields:
  • labels: ["trt-incident", "ai-generated-jira"]

Record the created (or reused) JIRA key and URL.

Step 4: Open Revert PR (with idempotency check)

Preflight: Before opening a new revert PR, check whether one already exists:

gh pr list --repo <org>/<repo> --search "revert <pr_number>" --json number,title,url,state --limit 5

If an open or draft revert PR is found for this PR number, reuse its URL — skip the revert-pr skill and proceed to Step 5.

Create (only if no existing revert PR found): Load the revert-pr skill (plugins/ci/skills/revert-pr/SKILL.md) and follow its workflow:

• PR URL: the offending PR
• JIRA ticket: the TRT key from Step 3 (if available)
• Context (use --context): This PR is causing blocking job failures ({job names}) in the {stream} {architecture} payload [{payload_tag}]({release_controller_url}).
• Do NOT prompt the user for any input

Record the revert PR URL (created or reused).