ai-bug-fix-triage
starsforks
How to install ai-bug-fix-triage?
opendatahub-io/ai-helpers/ai-bug-fix-triage
$npx -y skills add opendatahub-io/ai-helpers --skill ai-bug-fix-triageTriage JIRA bugs against repository code to classify AI fixability. Use when reviewing a backlog of bugs to determine which ones an AI agent can fix.
SKILL.md
| 1 | # Bug Triage |
| 2 | |
| 3 | Triage JIRA bugs from a project backlog against a loaded repository to determine which bugs an AI agent can fix. Produces a focused fixability report. |
| 4 | |
| 5 | ## Scope |
| 6 | |
| 7 | This skill answers one question: **can an AI agent fix this bug in this repo?** It classifies issues as AI-Fixable, Needs Human, or Needs Info based on a fixability rubric. |
| 8 | |
| 9 | "Bug" is used broadly here — analyze **Bugs and Stories** for fixability. Skip **Epics, Initiatives, and Features** as they are too high-level for a single code fix (note them as skipped in the report). |
| 10 | |
| 11 | **Out of scope:** |
| 12 | |
| 13 | - **Deduplicate bugs** — does not detect or merge duplicate tickets |
| 14 | - **Prioritize or re-rank severity** — respects the existing JIRA priority as-is |
| 15 | - **Estimate effort** — no story points, t-shirt sizes, or time estimates |
| 16 | |
| 17 | ## Prerequisites |
| 18 | |
| 19 | - **Atlassian MCP** configured and authenticated (provides `getAccessibleAtlassianResources`, `searchJiraIssuesUsingJql`, `getJiraIssue`, `editJiraIssue`, `addCommentToJiraIssue`) |
| 20 | - **Target repository** loaded in the workspace — the user will have it open or will specify it |
| 21 | - **AGENTS.md or CLAUDE.md** present in the repo (used to understand repo structure, test commands, and conventions) |
| 22 | |
| 23 | ## Usage |
| 24 | |
| 25 | ```text |
| 26 | User: Triage <PROJECT> bugs against this repo |
| 27 | User: Triage bugs from filter=<ID> |
| 28 | User: Triage project = <PROJECT> AND component = "<component>" AND status = New |
| 29 | User: Triage filter=<ID> and update JIRA with labels |
| 30 | User: Triage just <KEY> |
| 31 | ``` |
| 32 | |
| 33 | ## Implementation |
| 34 | |
| 35 | ### Step 1: Determine the Query, Target Repo, and Scope |
| 36 | |
| 37 | **Query:** |
| 38 | |
| 39 | 1. If the user provides a JQL query, use it directly |
| 40 | 2. If the user provides a filter ID, use `filter=<ID>` as the JQL |
| 41 | 3. If the user names a component or project, construct JQL defaulting to **untriaged, unassigned** bugs and stories: |
| 42 | `project = <PROJECT> AND component = "<component>" AND type in (Bug, Story) AND status in (New, Refinement, "To Do") AND assignee is EMPTY ORDER BY priority DESC` |
| 43 | 4. If nothing specific is given, ask: "What JQL query or JIRA filter should I use?" |
| 44 | |
| 45 | **Target repo:** |
| 46 | |
| 47 | 1. If the user names a repo, use it |
| 48 | 2. If the workspace has a repo loaded, confirm: "I see `<repo>` loaded — should I triage bugs against this repo?" |
| 49 | 3. If ambiguous, ask which repo to analyze against |
| 50 | |
| 51 | **Repo state (read-only by default):** |
| 52 | |
| 53 | Triage is read-only — never switch branches or modify files. Run `git fetch origin` and compare HEAD with `origin/main`. If behind, inform the user but proceed on the current HEAD. Only create a temporary branch (`git checkout -b ai-bug-fix-triage-<date> origin/main`) if the user explicitly asks. State which commit is being used. |
| 54 | |
| 55 | ### Steps 2-6: Detailed Implementation |
| 56 | |
| 57 | See `references/guidelines.md` for detailed criteria covering: |
| 58 | - **Step 2**: Fetching bugs via Atlassian MCP, batch progress tracking, and fast-path vs. interactive-path logic |
| 59 | - **Step 3**: Filtering irrelevant tickets using label hints, idempotency checks, and exclusion criteria |
| 60 | - **Step 4**: Analyzing each bug for AI fixability (relevance check, code search, fixability rubric, classification) |
| 61 | - **Step 5**: Generating the triage report (header, summary table, AI-Fixable bugs table, detailed analysis) |
| 62 | - **Step 6**: Optional JIRA writeback (labels and triage comments with idempotency) |
| 63 | |
| 64 | **Classifications at a glance:** |
| 65 | |
| 66 | | Classification | Criteria | Label | |
| 67 | |---------------|----------|-------| |
| 68 | | **AI-Fixable** | Root cause identifiable, clear code fix, fix verifiable | `ai-fixable` | |
| 69 | | **Needs Human** | Any criterion fails | `ai-nonfixable` | |
| 70 | | **Needs Info** | Description too vague to determine root cause | `ai-needs-info` | |
| 71 | |
| 72 | ## Error Handling |
| 73 | |
| 74 | - **MCP not available**: Tell the user to configure and authenticate the Atlassian MCP server |
| 75 | - **Empty results**: Report no bugs found, suggest broadening the JQL |
| 76 | - **Repo not loaded**: Ask the user to open the target repo first |
| 77 | - **Permission denied on writeback**: Skip that ticket, continue with the rest |
| 78 | - **Rate limiting**: Process writeback calls sequentially; back off on 429 responses |
People who liked this also viewed
6 picksType
- azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026
- systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026
- safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026
- explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026
- minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026
- insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 2026
