Auto-Triage GitHub Issues

The Problem

Drowning in open issues with no time to triage?

Every open issue needs to be read, understood, and turned into an actionable bug-fix spec before anyone can work on it. When the backlog is long, that triage work piles up fast — and it is the kind of repetitive, structured writing that an agent can do in seconds.

📃

Manual copy-paste

Opening each issue, reading the description, and reformatting it into a bug-fix spec by hand is slow and error-prone — especially across a large backlog.

🔄

Context bleed between issues

Asking an agent to process many issues in a single prompt means earlier issues influence later ones — producing muddled, inconsistent output.

📋

Inconsistent specs

Without a fixed template, every spec looks different. Developers waste time figuring out what the acceptance criteria actually mean before they can start work.

See it in action

Watch it triage a real repo

The recording below shows github-issue-summary.mgx running against a live repository — fetching open issues and writing a bug-fix spec for each one.

1

Create the .mgx

The github-issue-summary.mgx file orchestrates everything. It declares a @memory variable to hold the fetched issues, calls the GitHub CLI to populate it, then iterates over each issue — with a clean context — to write out a structured bug-fix template.

github-issue-summary.mgx

---
description: Grab a summary of github issues and create AI use case fix templates.
---

@memory var issues
@state noIssues = false

<<
Your task is to grab a summary of the github issues for a given repository.
The summary should include the following information for each issue:

{
    "title": "The title of the issue",
    "number": "The issue number",
    "body": "The description of the issue",
    "state": "The state of the issue (open or closed)",
    "created_at": "When the issue was created",
    "updated_at": "When the issue was last updated"
}

The variable `issues` holds a dictionary keyed by issue number.

Run `gh issue list --json title,body,number,state,createdAt,updatedAt | cat`

If there are no issues, print "No issues found." and set `noIssues` = true.
>>

@effect run

if noIssues:
    @effect log "No issues found for this repository."
elif:
    for issue in issues:
        @effect context clear
        <<
        Here is the information for issue #${issue['number']}:
        ${issue['body']}

        Translate the above into a file using this template:

        # Bug: $issue['title']} ${issue['number']}

        ## Objective:
        <concise summary of how to fix the issue>

        ## Steps to reproduce:
        - <specific, actionable reproduction step>

        ## Acceptance Criteria:
        - <measurable outcome that confirms the fix>
        - <another measurable outcome>

        Output the file to ./temp/bugfix_${issue['number']}.md
        >>

        @effect run

2

Declare memory and state

Two declarations set up the data layer for the whole run. @memory var issues tells Margarita to persist the issues dictionary to disk so it is saved between executions and reloaded on startup. @state noIssues = false initialises a typed boolean the agent can flip to signal an empty repository — short-circuiting the loop entirely.

@memory var issues

Declares issues as a memory-backed variable. The agent populates it with the JSON returned by gh issue list. Because it lives in @memory, it is written to disk and reloaded on the next startup — so a partial run can resume right where it left off without re-fetching all issues.

// Declared once at the top of the .mgx file
@memory var issues

// The agent writes to it after running gh issue list:
// issues = {
//   "42": { "title": "Login fails on Safari", "body": "...", ... },
//   "43": { "title": "404 on /profile page",  "body": "...", ... }
// }

// Later in the loop it is still accessible:
for issue in issues:
    @effect context clear   // context reset — memory persists on disk
    << Here is issue #${issue['number']}: ${issue['body']} >>

@state noIssues = false

A boolean state variable initialised to false. If the GitHub CLI returns an empty list the agent sets it to true, and the if / elif block logs a friendly message and skips the loop entirely — no wasted iterations over an empty dataset.

@state noIssues = false

// Agent sets noIssues = true when gh returns []
@effect run

if noIssues:
    // Short-circuit — skip the loop
    @effect log "No issues found for this repository."
elif:
    // Proceed only when there are real issues to process
    for issue in issues:
        ...

3

Loop, clear, and generate

For each issue, Margarita clears the context so the agent sees only the current issue — no noise from previous ones. The prompt injects the issue body and title, then instructs the agent to write a fully structured bug-fix spec to ./temp/bugfix_<number>.md.

github-issue-summary.mgx Loop logic

for issue in issues:
    // Isolate each issue — no cross-contamination
    @effect context clear

    << Here is the information for issue #${issue['number']}:
${issue['body']}

Translate the above into a file using this template:

# Bug: ${issue['title']} ${issue['number']}

## Objective:
## Steps to reproduce:
## Acceptance Criteria:

Output to ./temp/bugfix_${issue['number']}.md >>

    @effect run

Output ./temp/bugfix_42.md

# Bug: Login fails on Safari 42

## Objective:
Fix the authentication flow so that the login
form submits correctly in Safari 16+. The issue
is caused by an incompatible use of the Web
Crypto API on that browser.

## Steps to reproduce:
- Open the app in Safari 16
- Navigate to /login
- Enter valid credentials and submit
- Observe the request hang with no feedback

## Acceptance Criteria:
- Login succeeds in Safari 16 and 17
- No console errors related to crypto.subtle
- Existing tests continue to pass

💾

Memory persists across executions

@memory variables are written to disk and reloaded on startup. If you stop a run mid-way through and restart it, the issues fetched in the first phase are still there — no need to call the GitHub CLI again.

✏️

One issue, one context

@effect context clear resets the conversation before each issue. The agent focuses only on the issue at hand — no earlier issue descriptions bleeding in to distort the generated spec.

🔧

GitHub CLI as a first-class tool

The prompt instructs the agent to run gh issue list directly. Any CLI tool the agent can reach becomes part of the workflow — no custom integration code required.

Ready to clear your backlog?

Grab the example file from GitHub and run it against any repository to generate bug-fix specs in seconds.

Read the Margarita Docs Back to Margarita

Auto-TriageGitHub Issues