triage

name	triage
description	Classify a bug report, security finding, or feature request. Assigns priority P0-P3, picks a label, and creates a GitHub issue on the project board. Use whenever something needs to enter the backlog.
allowed-tools	Bash, Read

/triage

Local setup: gh issue create (GitHub) and Slack alerts need a remote + the Slack MCP, neither configured here. Locally, record the triage decision (priority, label, summary) in the conversation or a backlog note instead of opening an issue.

You convert raw inputs (bug descriptions, audit findings, feature ideas) into well-formed GitHub issues with priority, labels, and routing.

Invocation

/triage bug: <description>
/triage feature: <description>
/triage security: <description>
/triage finding SC-F-1234         # Convert a scorecard finding into a GitHub issue
/triage from devops:<run-id>      # Convert a CI failure into an issue

Process

1. Classify type: bug, feature, security, tech-debt, infra, docs
2. Assign priority:
   • P0 — production down, security breach, data leak, blocking customers
   • P1 — security violation, broken main branch, broken core feature
   • P2 — bug in feature, missing validation, scorecard finding HIGH
   • P3 — tech debt, refactor, scorecard finding MEDIUM/LOW, polish
3. Pick labels — one type label, one priority label, one or more area labels (area:scorecards, area:auth, area:frontend, etc.), plus auto-triaged if generated by another skill
4. Identify the owner team — from the affected area or service. If none, leave unassigned and add needs-owner label.
5. Create the issue using gh issue create with the structured body below
6. Add to the project board — column "Backlog" by default, "Ready" if priority is P0 or P1
7. Notify if P0/P1 — auto-trigger /notify to Slack #gatherly-alerts

Issue body template

## Summary
<1-2 sentence problem description in user-facing terms>

## Context
<Why this matters, what's affected, who reported it>

## Steps to reproduce (bugs only)
1. ...
2. ...

## Expected
<What should happen>

## Actual
<What does happen>

## Acceptance Criteria
- [ ] AC-1 ...
- [ ] AC-2 ...

## Source
<Where this came from — user report, /audit-security run, /devops failure, /audit-service finding, etc.>

## Suggested approach
<Optional — if obvious, propose a direction. If not, leave blank.>

---

Auto-triaged by /triage on <timestamp>
Priority: P<N>
Owner: <team or unassigned>

Priority decision tree

Is the issue actively breaking production or leaking data?
├── YES → P0
└── NO →
    Does it violate security (S1-S8) or break main branch?
    ├── YES → P1
    └── NO →
        Is it a real bug in a shipped feature, or HIGH-severity finding?
        ├── YES → P2
        └── NO → P3

Auto-triage from other skills

Sources that feed /triage:

Source	Maps to
/audit-security CRITICAL violation	P0 security
/audit-security HIGH violation	P1 security
/devops test failure on main	P1 bug
/devops flaky test	P3 tech-debt
/audit-service CRITICAL finding	P1
/audit-service HIGH finding	P2
/audit-service MEDIUM finding	P3
/review-pr HIGH bug	P2

What you must NOT do

• Assign yourself or another teammate without explicit approval (use labels for routing instead)
• Inflate priority. P0 means production-down. Not "important."
• Create duplicates. Search existing issues first with gh issue list --search.
• Skip the AC section. An issue without AC is unactionable.
• Auto-close stale issues. That's a separate process.