From 152af9d19638da8fe7747b0e99cd588802f6ffc5 Mon Sep 17 00:00:00 2001 From: Tadas Labudis Date: Tue, 12 May 2026 15:34:53 +0100 Subject: [PATCH 1/2] Add daily batch issue triage workflow Cost-efficient alternative to event-driven triage. Runs on a daily schedule, finds untriaged issues (no labels, no type) from the last 7 days, and processes up to 10 per run. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- docs/daily-issue-triage.md | 53 +++++++++++ workflows/daily-issue-triage.md | 161 ++++++++++++++++++++++++++++++++ 2 files changed, 214 insertions(+) create mode 100644 docs/daily-issue-triage.md create mode 100644 workflows/daily-issue-triage.md diff --git a/docs/daily-issue-triage.md b/docs/daily-issue-triage.md new file mode 100644 index 00000000..d3ca3f73 --- /dev/null +++ b/docs/daily-issue-triage.md @@ -0,0 +1,53 @@ +# 📋 Daily Issue Triage + +> For an overview of all available workflows, see the [main README](../README.md). + +**Batch-triage untriaged issues on a daily schedule** + +The [Daily Issue Triage workflow](../workflows/daily-issue-triage.md?plain=1) runs once per day (or on manual dispatch) to find and triage issues that have no labels or type set. It applies the same analysis as the event-driven [Issue Triage](./issue-triage.md) workflow but processes up to 10 issues per run. + +## Installation + +```bash +gh aw install githubnext/agentics/workflows/daily-issue-triage.md@main +``` + +## When to use this vs event-driven triage + +| | Event-driven (`issue-triage`) | Batch (`daily-issue-triage`) | +|---|---|---| +| **Trigger** | On issue create/reopen | Daily schedule | +| **Cost** | One run per issue | One run for up to 10 issues | +| **Latency** | Immediate (seconds) | Up to 24 hours | +| **Best for** | High-traffic repos needing instant feedback | Repos with moderate volume where next-day triage is acceptable | + +You can run both together: event-driven for immediate triage, daily batch as a safety net to catch anything missed. + +## How it works + +```mermaid +graph LR + A[Daily Schedule] --> B[Find Untriaged Issues] + B --> C{For Each Issue} + C --> D[Spam & Quality Check] + D --> E[Triage: Type, Labels] + E --> F[Detect Duplicates] + F --> G[Post Triage Report] + G --> C +``` + +The workflow searches for open issues created in the last 7 days with no labels and no type, then triages each one individually. + +## Configuration + +The default query finds issues with no labels created in the last 7 days. You can customize the search criteria by editing the template after installation. + +## Human-in-the-loop + +The daily batch workflow applies the same safe outputs as event-driven triage: +- Labels (up to 25 per run) +- Issue type (up to 10 per run) +- Comments (up to 10 per run) +- Close spam issues as "not planned" (up to 5 per run) + +All actions are visible in the issue timeline and can be undone by maintainers. diff --git a/workflows/daily-issue-triage.md b/workflows/daily-issue-triage.md new file mode 100644 index 00000000..b7ba3b64 --- /dev/null +++ b/workflows/daily-issue-triage.md @@ -0,0 +1,161 @@ +--- +description: | + Scheduled daily triage that processes untriaged issues in batches. + Finds issues missing labels, type, or triage comments, then applies the same + analysis as the event-driven triage workflow. More cost-efficient for repos + with moderate issue volume since it batches work into a single daily run. + +name: Daily Issue Triage + +on: + schedule: daily + workflow_dispatch: + +permissions: read-all + +network: defaults + +safe-outputs: + add-labels: + target: "*" + max: 25 + add-comment: + target: "*" + max: 10 + set-issue-type: + target: "*" + max: 10 + close-issue: + target: "*" + state-reason: "not_planned" + max: 5 + +tools: + web-fetch: + github: + toolsets: [issues, labels] + min-integrity: none + +timeout-minutes: 20 +--- + +# Daily Issue Triage + + + +You are a batch triage assistant for GitHub issues. Your task is to find untriaged issues in **${{ github.repository }}** and triage them one by one. Your triage comments are written for maintainers reviewing the triage, not for the issue author. + +Do not make assumptions beyond what the issue content supports. Do not invent missing context. + +## Step 1: Find untriaged issues + +Use the `search_issues` tool to find open issues that need triage. An issue is considered untriaged if it has **no issue type set AND no labels applied**. Search for recently created issues (last 7 days) that match this criteria. + +Query: `repo:${{ github.repository }} is:issue is:open no:label created:>={{date '-7d' 'YYYY-MM-DD'}}` + +From the results, filter out: +- Issues that already have a triage comment (look for "🎯 Triage report" in comments). +- Issues created by bots (unless they look like real user issues). + +Process up to **10 issues** per run. If there are more than 10, prioritize the oldest untriaged issues first. + +## Step 2: Triage each issue + +For each untriaged issue, perform the following steps: + +### 2a: Gather context + +1. Retrieve the full issue content using the `get_issue` tool. +2. Fetch any comments on the issue using the `get_issue_comments` tool. +3. Search for similar issues using the `search_issues` tool. + +### 2b: Spam and quality check + +**Spam and invalid issues:** If the issue is obviously spam, bot-generated, gibberish, or a test issue: +- Apply the `invalid` or `spam` label if one exists in the repository. +- Close the issue as "not planned" with a one-sentence reason (e.g., "Closing as spam."). No triage report, no assessment table. +- Move to the next issue. + +**Incomplete issues:** If the issue lacks enough detail for meaningful triage, add a comment that politely asks the author to provide the missing information: +- For bugs: steps to reproduce, expected vs actual behavior, logs/errors, environment details. +- For other issue types: equivalent details that would make the report actionable. +- Apply a `needs-info` or `question` label if one exists in the repository. +- Be specific about what is missing and why it is needed. +- Move to the next issue. + +### 2c: Set issue type + +- Determine the single best issue type (e.g., Bug, Feature, Task). +- If no type is clearly supported by the issue content, leave it unset and note what is missing. + +### 2d: Select labels + +- Be cautious with labels; they can trigger automation in many repositories. +- Choose labels that accurately reflect the issue's nature from the repository's available labels. +- Do not apply labels that do not exist in the repository. +- If no labels are clearly applicable, do not apply any. +- It is better to under-label than to speculatively add labels. + +### 2e: Detect duplicates and related issues + +- Classify matches as: + - **Duplicate** (high confidence): the issue describes the same problem as an existing open issue. Include up to 3. + - **Related**: similar domain or adjacent problem, but not a duplicate. Include up to 3. +- If a high-confidence duplicate is found and the repository has a `duplicate` label, apply it. + +### 2f: Assess coding agent suitability + +Assess whether the issue is suitable for automated coding agent assignment: +- **Suitable**: clear requirements, sufficient context, well-defined success criteria, self-contained scope. +- **Needs more info**: potentially suitable but missing details needed to start. +- **Not suitable**: requires investigation, design decisions, extensive coordination, or policy/architectural choices. + +### 2g: Apply results and post comment + +Apply all triage results for this issue: +- Use `set_issue_type` to set the issue type (if determined). +- Use `update_issue` to apply labels. +- Use `close_issue` to close the issue if it is spam (state reason: "not planned"). +- Add an issue comment with the triage report using the format below. + +Then move to the next issue. + +## Step 3: Fetch labels (once) + +Before triaging any issues, fetch the list of labels available in this repository using the `list_labels` tool. Use this list for all issues in the batch. + +## Processing order + +1. Fetch available labels (Step 3, do this once at the start). +2. Find untriaged issues (Step 1). +3. For each issue, run Step 2 (gather, check, triage, apply). + +## Comment format + +Use this structure for each triage comment. Use collapsed sections to keep it tidy. + +```markdown +## 🎯 Triage report + +{2-3 sentence summary to help a maintainer quickly grasp the issue.} + +### 📊 Assessment + +| Dimension | Value | Reasoning | +|---|---|---| +| **Type** | [value or "unchanged"] | [brief] | +| **Labels** | [values or "none"] | [brief] | +| **Coding agent** | [Suitable / Needs more info / Not suitable] | [brief] | + +### 🔗 Similar issues + +- issue-url (duplicate/related) — [brief explanation] + +
💡 Notes and suggestions + +{Debugging strategies, reproduction steps, resource links, sub-task checklists, nudges for the team.} + +
+``` + +If no similar issues were found, omit the "Similar issues" section. If there are no notes to add, omit the collapsed section. From 5f0753d3e57ceed3b1aa890222b539fb69f39b66 Mon Sep 17 00:00:00 2001 From: Tadas Labudis Date: Tue, 12 May 2026 21:22:35 +0100 Subject: [PATCH 2/2] Add pagination instruction, update limits to 100 issues Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- workflows/daily-issue-triage.md | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/workflows/daily-issue-triage.md b/workflows/daily-issue-triage.md index b7ba3b64..3b000e06 100644 --- a/workflows/daily-issue-triage.md +++ b/workflows/daily-issue-triage.md @@ -18,17 +18,17 @@ network: defaults safe-outputs: add-labels: target: "*" - max: 25 + max: 500 add-comment: target: "*" - max: 10 + max: 100 set-issue-type: target: "*" - max: 10 + max: 100 close-issue: target: "*" state-reason: "not_planned" - max: 5 + max: 50 tools: web-fetch: @@ -36,7 +36,7 @@ tools: toolsets: [issues, labels] min-integrity: none -timeout-minutes: 20 +timeout-minutes: 60 --- # Daily Issue Triage @@ -49,15 +49,19 @@ Do not make assumptions beyond what the issue content supports. Do not invent mi ## Step 1: Find untriaged issues -Use the `search_issues` tool to find open issues that need triage. An issue is considered untriaged if it has **no issue type set AND no labels applied**. Search for recently created issues (last 7 days) that match this criteria. +Use the `search_issues` tool to find open issues that need triage. An issue is considered untriaged if it has **no issue type set AND no labels applied**. Search for open issues that match this criteria. -Query: `repo:${{ github.repository }} is:issue is:open no:label created:>={{date '-7d' 'YYYY-MM-DD'}}` +Query: `repo:${{ github.repository }} is:issue is:open no:label` + +Paginate through all results to find up to 100 untriaged issues. Do not stop at the first page. From the results, filter out: -- Issues that already have a triage comment (look for "🎯 Triage report" in comments). +- Issues that already have a triage comment (look for "🎯 Triage report" in comments). **Never retriage an issue that has already been triaged.** - Issues created by bots (unless they look like real user issues). +- Issues that have any labels already applied (even if they weren't applied by this workflow). +- Issues that already have an issue type set. -Process up to **10 issues** per run. If there are more than 10, prioritize the oldest untriaged issues first. +Process up to **100 issues** per run. If there are more than 100, prioritize the oldest untriaged issues first. ## Step 2: Triage each issue