agentleFS
brittbritt/agent-skills/skills/triage-new-issues/SKILL.md

triage-new-issues

Skill11 starsChanged 7 days agoMITView on GitHub

Use when processing new or untriaged GitHub issues - assesses urgency from keyword and label signals, assigns P0-P3 priority, suggests labels and assignees, and flags issues needing escalation or clarification

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use the gh CLI (must be installed and authenticated):

    line 20
  2. Distinctive:

    Action: Add to backlog

    line 50
  3. Distinctive:

    Read title and full description

    line 56
  4. Distinctive:

    Check for existing labels that signal priority

    line 58
  5. Distinctive:

    Look for workarounds mentioned

    line 60
  6. Distinctive:

    Check if duplicate of existing issue

    line 61
  7. Distinctive:

    No indication of urgency or timeline

    line 75

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Triage New Issues Skill

Review new or untriaged GitHub issues, assess priority based on urgency signals, suggest labels, and recommend owners.

When to Use

Activate when:

  • Processing new incoming issues
  • Reviewing untriaged backlog
  • Assessing issue priority
  • Assigning issues to owners

Fetching and Applying Triage

Use the gh CLI (must be installed and authenticated):

# Find untriaged issues
gh issue list --search 'no:label' --json number,title,body,labels

# Apply labels after triage
gh issue edit <n> --add-label <label>

Priority Signals

Critical (P0)

Keywords: "down", "outage", "security", "vulnerability", "production", "urgent", "ASAP", "breach" Labels: critical, security, production Action: Immediate attention required

High (P1)

Keywords: "blocking", "regression", "broken", "can't use", "data loss", "crash" Labels: blocker, regression, priority/high Action: Address this sprint

Medium (P2)

Keywords: "bug", "incorrect", "should", "expected", "wrong" Labels: bug, priority/medium Action: Schedule for upcoming sprint

Low (P3)

Keywords: "nice to have", "minor", "cosmetic", "enhancement", "workaround exists" Labels: enhancement, low-priority Action: Add to backlog

Triage Guidelines

Assessment Process

  1. Read title and full description
  2. Scan for urgency keywords and labels
  3. Check for existing labels that signal priority
  4. Assess impact (how many users affected)
  5. Look for workarounds mentioned
  6. Check if duplicate of existing issue
  7. Determine ownership: check CODEOWNERS, recent git log on affected paths, or past assignees of similar issues — omit the assignee suggestion if none found

When to Escalate

  • Security vulnerabilities → Flag immediately
  • Production outages → Notify on-call
  • Data integrity issues → High priority regardless of other signals

When to Ask Questions

  • Unclear reproduction steps
  • Missing environment details
  • Ambiguous severity ("it's broken" but unclear impact)
  • No indication of urgency or timeline

Red Flags

  • Issues with no response from author (>7 days)
  • Duplicate of closed/wontfix issue
  • Feature request disguised as bug
  • Missing required information from template

Output Structure (per issue)

## Triage: #[number] — [title]

### Priority Assessment

**Urgency**: [Critical | High | Medium | Low]
**Impact**: [Wide | Moderate | Limited]
**Recommended Priority**: P[0-3]

| Signal | Indicator |
|--------|-----------|
| [Keyword/label found] | [What it suggests] |

### Classification

**Type**: [Bug | Feature | Question | Task]
**Area**: [Component or area affected]
**Suggested Labels**: `priority/high`, `bug`, `area/auth`
**Suggested Assignee**: @username — based on CODEOWNERS, git history, or similar past issues (omit if no owner found)

### Assessment

[Summary of the issue and reasoning for priority assignment]

### Clarifying Questions (if needed)

- [ ] [Question to understand severity]

### Recommendation

[Immediate action | Next sprint | Backlog | Needs info | Duplicate of #X]

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.