bugs-triage
Triage Jira bugs (New->Backlog) and GitHub issues for openshift-hyperfleet repos interactively.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Triage Jira bugs (New->Backlog) and GitHub issues for openshift-hyperfleet repos interactively.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Manage Renovate/MintMaker dependency update PRs across HyperFleet repos — list, classify, approve, rebase, and merge
Validates JIRA tickets against HyperFleet ticket-hygiene standards — checks required fields, valid components, activity types, story points, and acceptance criteria. Suggests and applies fixes via jira CLI. Use when triaging tickets, validating sprint readiness, or asking "does this ticket have everything we need?"
Review a PR with JIRA validation, architecture checks, impact analysis, and interactive recommendations
Shows unassigned, non-blocked tickets in the current JIRA sprint backlog, sorted by priority, helping developers pick their next task.
Analyzes HyperFleet E2E CI pipeline failures from a Prow URL, GitHub Actions URL, job name, or JIRA ticket. Use when a nightly or periodic E2E pipeline run fails and you need a structured root cause analysis with confidence scoring.
Surface and prioritize open PRs across the openshift-hyperfleet org using GitHub + JIRA context, PR content analysis, and intelligent multi-factor scoring with confidence levels
| name | bugs-triage |
| description | Triage Jira bugs (New->Backlog) and GitHub issues for openshift-hyperfleet repos interactively. |
| allowed-tools | Bash, Read, Grep, Glob, AskUserQuestion, Skill |
| argument-hint | [jira|github] (default: both) |
command -v jira >/dev/null 2>&1 && echo "available" || echo "NOT available"command -v gh >/dev/null 2>&1 && echo "available" || echo "NOT available"jira: Run only Jira bug triagegithub: Run only GitHub issues triageLoad these files as needed during triage:
references/owners.csv — Component/domain owners for assignee suggestions../../references/github-repos.md — GitHub repositories in triage scope (skip issues from unlisted repos)Before triaging, fetch the current field requirements (valid components):
curl -sL https://raw.githubusercontent.com/openshift-hyperfleet/architecture/main/hyperfleet/standards/ticket-hygiene.md 2>/dev/null
Use the fetched document as the source of truth for component validation. Do NOT rely on hardcoded component lists.
When creating JIRA tickets (e.g., from accepted GitHub issues or RFE conversions), use the hyperfleet-jira:jira-ticket-creator skill via the Skill tool. This skill handles description formatting, Activity Type classification, Story Points estimation, and all ticket creation best practices. Pass the issue context (title, description, component, suggested priority) as the skill argument.
ALWAYS include clickable links in all tables, headings, and references:
[TICKET-KEY](https://redhat.atlassian.net/browse/TICKET-KEY)[REPO#NUMBER](https://github.com/openshift-hyperfleet/REPO/issues/NUMBER)| Priority | Triage SLA | Fix/Workaround SLA |
|---|---|---|
| Blocker | Within 24 hours | Within 72 working hours |
| Critical/Major | Per Week | Within 5 working days |
| Normal | Per Sprint | Must be fixed in coming release |
| Low | Per Sprint | Planned per capacity; max 2 sprints, re-evaluate in 3rd |
jira issue list -q"project = HYPERFLEET AND status = New AND issuetype = Bug" --plain --columns "KEY,SUMMARY,PRIORITY,STATUS,COMPONENT,ASSIGNEE,CREATED" 2>/dev/null
If no bugs found, report "No bugs in New status" and skip to Step 5.
jira issue list -q"project = HYPERFLEET AND issuetype = Bug AND status not in (Closed, Done) AND created <= -42d" --plain --columns "KEY,SUMMARY,PRIORITY,STATUS,ASSIGNEE,CREATED" 2>/dev/null
Skip bugs that already have an assignee — they are already being handled.
For each remaining bug, do the following one at a time:
jira issue view TICKET-KEY --plain 2>/dev/null
Start with a heading: ### [TICKET-KEY](https://redhat.atlassian.net/browse/TICKET-KEY) - Summary
Evaluate and present:
| Check | Status | Notes |
|---|---|---|
| Sufficient info/logs | PASS/FAIL | Logs, steps to reproduce, environment details? |
| Priority set correctly | PASS/FAIL/MISSING | Based on SLA table |
| Component identified | PASS/FAIL/MISSING | Must be a valid project component from ticket-hygiene.md (fetched above). Match names in references/owners.csv. If multiple components apply, add ALL |
| Target version | SET/MISSING | If MVP bug, set "MVP". Otherwise set planned fix version per release strategy (if field is available) |
| Valid bug | LIKELY/UNCLEAR | Real defect? Or actually a feature request (RFE)? |
| Hyperfleet scope | YES/NO | If not in Hyperfleet scope, move to the correct Jira Project |
| Assignee | SET/MISSING | If missing, suggest owner from references/owners.csv |
jira issue list -q"project = HYPERFLEET AND issuetype = Bug AND summary ~ 'keyword'" --plain 2>/dev/null
[RFE] prefix and keep in "New" statusUse AskUserQuestion to confirm the action, then execute:
jira issue move TICKET-KEY "Backlog"jira issue edit TICKET-KEY --priority "Normal" --no-input — always add a comment explaining why the priority was changedjira issue edit TICKET-KEY --component "Name" --no-input — if multiple components apply, add all of themjira issue edit TICKET-KEY --custom target-version="MVP" --no-input (if the field is available in the project)jira issue comment add TICKET-KEY "..."jira issue move TICKET-KEY "Closed" --resolution "<Resolution>" — valid resolutions: Won't Do, Rejected, Duplicatejira issue link TICKET-KEY DUPLICATE-KEY "Duplicate"[RFE] prefix to summary, keep in "New" statusPresent in a table and ask the user to re-evaluate or close each one:
| Ticket | Priority | Status | Assignee | Created |
Low priority rule: Bugs with Low priority can be held for max 2 sprints. In the 3rd sprint, recommend re-evaluating — either fix or close them. Do not defer indefinitely.
| Metric | Count |
|--------|-------|
| Bugs triaged | X |
| Moved to Backlog | X |
| Closed (Won't Do/Rejected/Duplicate) | X |
| Info requested | X |
| Skipped | X |
| Bugs open > 3 sprints | X |
Read ../../references/github-repos.md to get the list of repos in scope. For each repo name, build a repo:openshift-hyperfleet/<name> token and include all of them in the -f q= parameter. Fetch issues that are either unlabeled or have hf-needs-triage but NOT already triaged labels:
gh api search/issues -X GET \
-f q="is:issue is:open -label:hf-triaged/accepted -label:hf-triaged/rejected -label:hf-triaged/duplicate repo:openshift-hyperfleet/hyperfleet-api repo:openshift-hyperfleet/hyperfleet-sentinel ..." \
-f per_page=50 \
--jq '.items[] | "\(.repository_url | split("/") | .[-1])|\(.number)|\(.title)|\(.state)|\(.labels | map(.name) | join(","))|\(.created_at[:10])"' 2>/dev/null
If none found, report "No untriaged GitHub issues" and skip to summary.
Same repo list as Step 1, but filter by creation date older than 42 days:
DATE=$(date -d '42 days ago' '+%Y-%m-%d' 2>/dev/null || date -v-42d '+%Y-%m-%d')
gh api search/issues -X GET \
-f q="is:issue is:open created:<$DATE repo:openshift-hyperfleet/hyperfleet-api repo:openshift-hyperfleet/hyperfleet-sentinel ..." \
-f per_page=50 \
--jq '.items[] | "\(.repository_url | split("/") | .[-1])|\(.number)|\(.title)|\(.created_at[:10])|\(.labels | map(.name) | join(","))"' 2>/dev/null
For each untriaged issue, do the following one at a time:
gh issue view NUMBER --repo openshift-hyperfleet/REPO_NAME 2>/dev/null
Before assessing, search for existing Jira tickets and merged PRs:
jira issue list -q"project = HYPERFLEET AND summary ~ 'keyword'" --plain --columns "KEY,SUMMARY,STATUS" 2>/dev/null
gh pr list --repo openshift-hyperfleet/REPO_NAME --state merged --search "keyword" --limit 5 2>/dev/null
hf-triaged/accepted label, keep the issue open (a Closed/Done Jira ticket alone does not prove the fix is in the repo), skiphf-triaged/accepted label, close the issue, skipAlways add the appropriate triage label (hf-triaged/accepted, hf-triaged/rejected, or hf-triaged/duplicate) when closing or resolving an issue.
Start with: ### [REPO#NUMBER](https://github.com/openshift-hyperfleet/REPO/issues/NUMBER) - Title
| Check | Status | Notes |
|---|---|---|
| Sufficient info | PASS/FAIL | Clear description, steps, context? |
| Labels present | PASS/FAIL | Existing labels? |
| Category | Bug/RFE/Help Request | Classify the issue |
| Hyperfleet scope | YES/NO/UNCLEAR | Within Hyperfleet's scope? |
hf-triaged/accepted[RFE] prefix, label hf-triaged/acceptedhf-triaged/acceptedhf-triaged/rejectedhf-triaged/duplicatehf-needs-infoUse AskUserQuestion to confirm, then execute. Adding labels may fail due to repo permissions — handle gracefully and report.
For accepted bugs/RFEs — create Jira ticket:
Use the hyperfleet-jira:jira-ticket-creator skill via the Skill tool, passing the issue context (title, description, component, suggested priority). The skill handles description formatting, Activity Type, Story Points, and all creation best practices.
After creating the Jira ticket, comment on the GitHub issue and add label. Keep the GitHub issue open until the fix is available in the repository:
gh issue comment NUMBER --repo openshift-hyperfleet/REPO_NAME --body "This issue has been accepted and is being tracked in JIRA as [HYPERFLEET-XXX](https://redhat.atlassian.net/browse/HYPERFLEET-XXX). We will update this issue when there is progress." 2>/dev/null
gh issue edit NUMBER --repo openshift-hyperfleet/REPO_NAME --add-label "hf-triaged/accepted" 2>&1
Present in a table and ask the user to re-evaluate or close each one:
| Issue | Title | Created | Labels |
| Metric | Count |
|--------|-------|
| Issues triaged | X |
| Accepted (Bug) | X |
| Accepted (RFE) | X |
| Help provided | X |
| Rejected | X |
| Duplicate | X |
| Info requested | X |
| Skipped | X |
| Issues open > 3 sprints | X |
Present a combined summary of all triage actions taken during the session.
jira CLI for Jira and gh CLI for GitHub; do not use other external CLIs, but allowed-tools (AskUserQuestion, Read, Skill) may be used as declared[RFE] prefix in "New" statushyperfleet-jira:jira-ticket-creator skill when creating Jira tickets (handles formatting, Activity Type, and Story Points)references/owners.csv to suggest assignees based on component