bug-triage

name	bug-triage
description	Triage open Comet issues marked `requires-triage` per the project bug triage guide. Applies the recommended priority and area labels, removes `requires-triage`, and files a dated summary issue listing what was done. A human reviews the summary issue and closes it when satisfied.

Run a bug triage pass for the apache/datafusion-comet repository.

Overview

This skill triages every open issue carrying the requires-triage label. For each one it:

1. Decides a priority and area labels using the project's triage guide.
2. Applies those labels via gh.
3. Removes the requires-triage label.
4. Records the decision (with rationale) in a single dated summary issue.

A human reviewer reads the summary issue, sanity-checks the calls, and closes it when satisfied. Any label correction is done by the reviewer directly on the affected issue.

The triage criteria come from the project's own guide. Read it before doing any classification work; do not rely on memory.

Step 1: Read the Triage Guide

Read the canonical guide in this repository:

docs/source/contributor-guide/bug_triage.md

Use the priority decision tree, escalation triggers, area labels, and prioritization principles from that guide. If the guide and this skill ever disagree, the guide wins. Do not paraphrase the guide; quote the labels and criteria verbatim when classifying.

Step 2: Gather Issues That Need Triage

Fetch all open issues labeled requires-triage:

gh issue list \
  --repo apache/datafusion-comet \
  --label requires-triage \
  --state open \
  --limit 200 \
  --json number,title,author,createdAt,labels,body,url

If the list is empty, stop and tell the user there is nothing to triage. Do not file an empty summary issue and do not modify any labels.

Step 3: Classify Each Issue

For each issue, review the title and body and determine:

1. Priority label (exactly one): apply the decision tree from the guide.
   • priority:critical for correctness issues (silent wrong results, data corruption) and security vulnerabilities
   • priority:high for crashes, panics, segfaults, NPEs on supported paths
   • priority:medium for functional bugs / performance regressions with workarounds
   • priority:low for test-only, CI flakes, tooling, cosmetic
2. Area labels (zero or more): from the area table in the guide (area:writer, area:shuffle, area:aggregation, area:scan, area:expressions, area:ffi, area:ci) plus the pre-existing area indicators (spark 4, spark sql tests).
3. Escalation note: if the issue matches an escalation trigger from the guide (e.g., a priority:high crash that may also produce wrong results), note it in the summary.

Step 4: Skip Issues You Cannot Confidently Classify

If an issue lacks reproduction steps or is otherwise too ambiguous to classify with confidence:

• Do not apply a priority label.
• Do not remove requires-triage.
• Do not comment on the issue or ask the reporter for more info from this skill (that is the human reviewer's call).
• Record it in the summary under a "Skipped — needs more info" section so the reviewer can follow up.

Guessing is worse than skipping.

Step 5: Apply Labels

For each issue you classified in Step 3, apply the labels and remove requires-triage in a single gh call:

gh issue edit <NUMBER> \
  --repo apache/datafusion-comet \
  --add-label "priority:high,area:expressions" \
  --remove-label "requires-triage"

Notes:

• Pass the labels as a single comma-separated string (no spaces around commas).
• Quote labels that contain spaces (e.g., "spark 4").
• Only add labels that already exist in the repo. If a label from the guide is missing in the repo, skip it for that issue and record a note in the summary rather than creating new labels.
• Do not comment on the issue.

If gh issue edit fails for any issue, leave that issue's requires-triage label intact and record the failure in the summary under a "Failed to label" section.

Step 6: File the Summary Issue

Compute today's date in YYYY-MM-DD form (use the system date, not memory):

TRIAGE_DATE=$(date -u +%Y-%m-%d)

Title: Bug triage results: ${TRIAGE_DATE}

Body: a markdown report with these sections, in this order:

1. Header

   • Date, total issues processed, and counts per priority
   • Link to docs/source/contributor-guide/bug_triage.md
   • Note that labels have already been applied; the reviewer should spot-check and close this issue when satisfied

2. Triaged — one subsection per priority, ordered highest priority first (priority:critical, then priority:high, then priority:medium, then priority:low). Omit any subsection whose count is zero. Do not use a markdown table anywhere in this section; use nested bullet lists only.

   Within each subsection, one top-level bullet per issue:

   ### priority:critical
   
   - <issue title> ([#1234](https://github.com/apache/datafusion-comet/issues/1234))
     - Area labels: `area:expressions`, `area:scan`
     - Rationale: one sentence tying the call to the guide
   

   The issue number (not the title) is the link target. The title is plain text. If there are no area labels, write Area labels: none.

3. Escalations to consider (omit section if empty) — bullet per issue with the same <title> ([#N](url)) form, plus a sub-bullet explaining the trigger from the guide.

4. Skipped — needs more info (omit if empty) — bullet per issue with the same <title> ([#N](url)) form, plus a sub-bullet explaining what is missing.

5. Failed to label (omit if empty) — bullet per issue with the same <title> ([#N](url)) form, plus a sub-bullet quoting the gh error.

File the issue with gh. Use a temp file for the body to keep quoting sane:

gh issue create \
  --repo apache/datafusion-comet \
  --title "Bug triage results: ${TRIAGE_DATE}" \
  --body-file /tmp/triage-summary-${TRIAGE_DATE}.md

Do not add labels to the summary issue itself.

After creating the issue, print its URL.

Output to the User

Report back:

1. Number of requires-triage issues processed
2. Counts per priority that were applied
3. Number skipped (needs more info) and number failed
4. URL of the new summary issue

Do not paste the full per-issue listing back into the chat; it is in the summary issue.

What This Skill Must Not Do

• Do not invent priority or area labels that are not in the guide
• Do not create new labels in the repo
• Do not comment on the triaged issues
• Do not close any triaged issue
• Do not file the summary issue if there were zero requires-triage issues
• Do not re-label issues that were skipped or failed (leave requires-triage in place so they show up in the next pass)
• Do not include AI/Claude attribution in the summary issue