About triage
A Herdr repository skill for triaging open GitHub issues in herdrdev/herdr. It prioritizes issues using defined severity categories and returns a concise Markdown table with age, reactions, and rationale.
Key features
- 01Open issue review
- 02Severity-based recommendations
- 03Issue age and reaction reporting
- 04Concise Markdown table output
Use cases
- 01Prioritizing Herdr bug reports
- 02Preparing a concise issue-triage summary
Install
Copy the command and run it in a terminal.
npx skills add https:/After installing, type/triagein Claude Code to confirm it loaded.
Details
From the project READMEHerdr Issue Triage
Use this skill only inside the herdr repository.
When the user says triage, inspect open GitHub issues for herdrdev/herdr and return a concise Markdown table. Prefer GitHub MCP tools when available. If they are unavailable, use gh issue list / gh issue view only when authenticated access is already configured.
Use this table shape:
| Light | Recommendation | Issue | Age | Reactions | Why |
|---|---|---|---|---|---|
| 🔴 | fix now | #123 | 18d | 5 | user-visible regression |
| 🟡 | queue | #124 | 42d | 2 | useful but not blocking |
| 🔵 | defer | #125 | 7d | 0 | cosmetic polish |
Keep issue numbers as Markdown links. Use days since issue creation for Age. Use total reactions for Reactions; include a compact breakdown only when it changes interpretation, such as 7 (5 👍, 2 👀).
Classify with these lights:
- 🔴
fix now: reproducible bug, crash, data loss, blocked workflow, release risk, or high-confidence user-visible regression. - 🟡
queue: useful feature, important quality issue, repeated user signal, stale issue that still looks valid, or behavior worth scheduling. - 🔵
defer: cosmetic polish, low-signal idea, unclear report, docs-only nit, or issue that likely needs more evidence before implementation.
Recommendations should be short imperative phrases: fix now, queue, defer, needs repro, close?, or needs owner decision.
Write one sentence before the table only if needed to state scope, such as how many open issues were inspected. After the table, add at most one short note for uncertainty or follow-up. Do not produce a long narrative unless the user asks for depth.