Menu
Create TRT JIRA bugs, open revert PRs, and trigger payload jobs for high-confidence revert candidates
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Generate a comprehensive manual testing guide from a Jira issue, GitHub PR URLs, or both. Use when the user wants test steps, a QE test plan, or a testing guide for code changes.
Create Jira issues — story, bug, epic, feature, initiative, task, or feature-request — with CNTRLPLANE, OCPBUGS, GCP, HyperShift, ARO, ROSA conventions and type-specific templates
Generate triage reports and post findings to Jira and Slack
Query and deduplicate open CVE vulnerability issues from OCPBUGS for Node team components
Check whether a Jira issue is well-groomed and ready for /jira:solve
Analyze and compare disruption across one or more Prow CI job runs by examining interval data, audit logs, pod logs, and CPU metrics
| name | stage-payload-reverts |
| description | Create TRT JIRA bugs, open revert PRs, and trigger payload jobs for high-confidence revert candidates |
This skill automates the full revert-staging workflow for payload regressions: creating TRT JIRA bugs, opening revert PRs, and triggering payload validation jobs.
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 analyzedversion, stream, architecture: Parsed from the payload tagrelease_controller_url: URL to the payload on the release controllerrevert_candidates: List of PRs to revert, each with:
pr_url, pr_number, component, confidence_score, rationaleoriginating_payload_tag: The payload where this candidate PR first caused failuresfailing_jobs: List of {job_name, prow_url, is_aggregated, underlying_job_name}Before starting, you MUST load the following skills (they define output schemas used when updating results):
payload-results-yaml — schema for the payload results YAML filepayload-autodl-json — schema for the autodl JSON data filegh): Installed and authenticatedBefore 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:
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.
For each qualifying revert candidate, launch a parallel subagent (do NOT set the model parameter). Each subagent executes Steps 3–5 in order.
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.
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:
--context): This PR is causing blocking job failures ({job names}) in the {stream} {architecture} payload [{payload_tag}]({release_controller_url}).Record the revert PR URL (created or reused).
Use the trigger-payload-job skill (plugins/ci/skills/trigger-payload-job/SKILL.md) to trigger payload validation jobs on the revert PR and collect the resulting URLs. Pass:
pr_url: The revert PR URL from Step 4jobs: The failing_jobs list for this candidate (includes job_name, is_aggregated, underlying_job_name for each job)The skill handles idempotency (checking for existing bot replies), correct command selection, polling, and URL extraction.
See the trigger-payload-job skill for exact command syntax. The skill enforces format requirements.
Record the payload_test_url and individual prow_urls from the skill's return data.
Each subagent should use the payload-results-yaml skill to update the results YAML, then return a brief status summary (success/partial/failed with any error descriptions) for the caller to print.
Collect all subagent results.
After all subagents complete, use the payload-results-yaml skill to append an action to each processed candidate's actions array in the results file at results_yaml_path:
type: "revert"status: "staged" (or "failed" if the revert PR could not be created)revert_pr_url, revert_pr_state, jira_key, jira_url, result_summary, payload_jobsSee the payload-results-yaml skill for the full schema.
After updating the results YAML, update the HTML report (payload-analysis-{sanitized_tag}-summary.html in the current working directory) to include links to the staged reverts.
Find the existing "Recommended Reverts" section in the HTML. For each candidate that was successfully staged, add a new row to the table or update the existing row to include:
<a href="{revert_pr_url}">#{revert_pr_number}</a>)<a href="{jira_url}">{jira_key}</a>)<a href="{payload_test_url}">Payload Test</a>)Revert Staged (use the badge-rejected class for visual consistency)If the report has no "Recommended Reverts" section (all candidates scored below 85 during analysis), add one before the per-job details section, using the same HTML structure as described in payload-analysis Step 7.4.
After updating the HTML report, use the payload-autodl-json skill's "Update Revert Status" operation to update the autodl JSON file for each candidate that was successfully staged.
Return results to the caller for inclusion in the report.
payload-results-yaml - Schema and operations for the payload results YAMLrevert-pr - The git revert workflow (plugins/ci/skills/revert-pr/SKILL.md)trigger-payload-job - Triggers payload jobs and collects URLs (plugins/ci/skills/trigger-payload-job/SKILL.md)payload-analysis - Identifies revert candidates (plugins/ci/skills/payload-analysis/SKILL.md)/ci:payload-revert - Command for staging reverts (plugins/ci/commands/payload-revert.md)