Skip to content

Commit d7c1dc4

Browse files
labudislabudis
authored
Add daily batch issue triage workflow (#333)
1 parent 298f992 commit d7c1dc4

2 files changed

Lines changed: 218 additions & 0 deletions

File tree

‎docs/daily-issue-triage.md‎

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
# 📋 Daily Issue Triage
2+
3+
> For an overview of all available workflows, see the [main README](../README.md).
4+
5+
**Batch-triage untriaged issues on a daily schedule**
6+
7+
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.
8+
9+
## Installation
10+
11+
```bash
12+
gh aw install githubnext/agentics/workflows/daily-issue-triage.md@main
13+
```
14+
15+
## When to use this vs event-driven triage
16+
17+
| | Event-driven (`issue-triage`) | Batch (`daily-issue-triage`) |
18+
|---|---|---|
19+
| **Trigger** | On issue create/reopen | Daily schedule |
20+
| **Cost** | One run per issue | One run for up to 10 issues |
21+
| **Latency** | Immediate (seconds) | Up to 24 hours |
22+
| **Best for** | High-traffic repos needing instant feedback | Repos with moderate volume where next-day triage is acceptable |
23+
24+
You can run both together: event-driven for immediate triage, daily batch as a safety net to catch anything missed.
25+
26+
## How it works
27+
28+
```mermaid
29+
graph LR
30+
A[Daily Schedule] --> B[Find Untriaged Issues]
31+
B --> C{For Each Issue}
32+
C --> D[Spam & Quality Check]
33+
D --> E[Triage: Type, Labels]
34+
E --> F[Detect Duplicates]
35+
F --> G[Post Triage Report]
36+
G --> C
37+
```
38+
39+
The workflow searches for open issues created in the last 7 days with no labels and no type, then triages each one individually.
40+
41+
## Configuration
42+
43+
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.
44+
45+
## Human-in-the-loop
46+
47+
The daily batch workflow applies the same safe outputs as event-driven triage:
48+
- Labels (up to 25 per run)
49+
- Issue type (up to 10 per run)
50+
- Comments (up to 10 per run)
51+
- Close spam issues as "not planned" (up to 5 per run)
52+
53+
All actions are visible in the issue timeline and can be undone by maintainers.

‎workflows/daily-issue-triage.md‎

Lines changed: 165 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,165 @@
1+
---
2+
description: |
3+
Scheduled daily triage that processes untriaged issues in batches.
4+
Finds issues missing labels, type, or triage comments, then applies the same
5+
analysis as the event-driven triage workflow. More cost-efficient for repos
6+
with moderate issue volume since it batches work into a single daily run.
7+
8+
name: Daily Issue Triage
9+
10+
on:
11+
schedule: daily
12+
workflow_dispatch:
13+
14+
permissions: read-all
15+
16+
network: defaults
17+
18+
safe-outputs:
19+
add-labels:
20+
target: "*"
21+
max: 500
22+
add-comment:
23+
target: "*"
24+
max: 100
25+
set-issue-type:
26+
target: "*"
27+
max: 100
28+
close-issue:
29+
target: "*"
30+
state-reason: "not_planned"
31+
max: 50
32+
33+
tools:
34+
web-fetch:
35+
github:
36+
toolsets: [issues, labels]
37+
min-integrity: none
38+
39+
timeout-minutes: 60
40+
---
41+
42+
# Daily Issue Triage
43+
44+
<!-- Note - this file can be customized to your needs. Replace this section directly, or add further instructions here. After editing run 'gh aw compile' -->
45+
46+
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.
47+
48+
Do not make assumptions beyond what the issue content supports. Do not invent missing context.
49+
50+
## Step 1: Find untriaged issues
51+
52+
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.
53+
54+
Query: `repo:${{ github.repository }} is:issue is:open no:label`
55+
56+
Paginate through all results to find up to 100 untriaged issues. Do not stop at the first page.
57+
58+
From the results, filter out:
59+
- Issues that already have a triage comment (look for "🎯 Triage report" in comments). **Never retriage an issue that has already been triaged.**
60+
- Issues created by bots (unless they look like real user issues).
61+
- Issues that have any labels already applied (even if they weren't applied by this workflow).
62+
- Issues that already have an issue type set.
63+
64+
Process up to **100 issues** per run. If there are more than 100, prioritize the oldest untriaged issues first.
65+
66+
## Step 2: Triage each issue
67+
68+
For each untriaged issue, perform the following steps:
69+
70+
### 2a: Gather context
71+
72+
1. Retrieve the full issue content using the `get_issue` tool.
73+
2. Fetch any comments on the issue using the `get_issue_comments` tool.
74+
3. Search for similar issues using the `search_issues` tool.
75+
76+
### 2b: Spam and quality check
77+
78+
**Spam and invalid issues:** If the issue is obviously spam, bot-generated, gibberish, or a test issue:
79+
- Apply the `invalid` or `spam` label if one exists in the repository.
80+
- Close the issue as "not planned" with a one-sentence reason (e.g., "Closing as spam."). No triage report, no assessment table.
81+
- Move to the next issue.
82+
83+
**Incomplete issues:** If the issue lacks enough detail for meaningful triage, add a comment that politely asks the author to provide the missing information:
84+
- For bugs: steps to reproduce, expected vs actual behavior, logs/errors, environment details.
85+
- For other issue types: equivalent details that would make the report actionable.
86+
- Apply a `needs-info` or `question` label if one exists in the repository.
87+
- Be specific about what is missing and why it is needed.
88+
- Move to the next issue.
89+
90+
### 2c: Set issue type
91+
92+
- Determine the single best issue type (e.g., Bug, Feature, Task).
93+
- If no type is clearly supported by the issue content, leave it unset and note what is missing.
94+
95+
### 2d: Select labels
96+
97+
- Be cautious with labels; they can trigger automation in many repositories.
98+
- Choose labels that accurately reflect the issue's nature from the repository's available labels.
99+
- Do not apply labels that do not exist in the repository.
100+
- If no labels are clearly applicable, do not apply any.
101+
- It is better to under-label than to speculatively add labels.
102+
103+
### 2e: Detect duplicates and related issues
104+
105+
- Classify matches as:
106+
- **Duplicate** (high confidence): the issue describes the same problem as an existing open issue. Include up to 3.
107+
- **Related**: similar domain or adjacent problem, but not a duplicate. Include up to 3.
108+
- If a high-confidence duplicate is found and the repository has a `duplicate` label, apply it.
109+
110+
### 2f: Assess coding agent suitability
111+
112+
Assess whether the issue is suitable for automated coding agent assignment:
113+
- **Suitable**: clear requirements, sufficient context, well-defined success criteria, self-contained scope.
114+
- **Needs more info**: potentially suitable but missing details needed to start.
115+
- **Not suitable**: requires investigation, design decisions, extensive coordination, or policy/architectural choices.
116+
117+
### 2g: Apply results and post comment
118+
119+
Apply all triage results for this issue:
120+
- Use `set_issue_type` to set the issue type (if determined).
121+
- Use `update_issue` to apply labels.
122+
- Use `close_issue` to close the issue if it is spam (state reason: "not planned").
123+
- Add an issue comment with the triage report using the format below.
124+
125+
Then move to the next issue.
126+
127+
## Step 3: Fetch labels (once)
128+
129+
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.
130+
131+
## Processing order
132+
133+
1. Fetch available labels (Step 3, do this once at the start).
134+
2. Find untriaged issues (Step 1).
135+
3. For each issue, run Step 2 (gather, check, triage, apply).
136+
137+
## Comment format
138+
139+
Use this structure for each triage comment. Use collapsed sections to keep it tidy.
140+
141+
```markdown
142+
## 🎯 Triage report
143+
144+
{2-3 sentence summary to help a maintainer quickly grasp the issue.}
145+
146+
### 📊 Assessment
147+
148+
| Dimension | Value | Reasoning |
149+
|---|---|---|
150+
| **Type** | [value or "unchanged"] | [brief] |
151+
| **Labels** | [values or "none"] | [brief] |
152+
| **Coding agent** | [Suitable / Needs more info / Not suitable] | [brief] |
153+
154+
### 🔗 Similar issues
155+
156+
- issue-url (duplicate/related) — [brief explanation]
157+
158+
<details><summary>💡 Notes and suggestions</summary>
159+
160+
{Debugging strategies, reproduction steps, resource links, sub-task checklists, nudges for the team.}
161+
162+
</details>
163+
```
164+
165+
If no similar issues were found, omit the "Similar issues" section. If there are no notes to add, omit the collapsed section.

0 commit comments

Comments
 (0)