hyperhive/claude-plugins/plugins/base/skills/forge-triage/SKILL.md

47 lines
2.4 KiB
Markdown

---
name: forge-triage
description: Verify triage coverage on a forge repo using the existing lint verbs instead of manually scanning issues/PRs - unassigned items, missing labels by scope, PRs with no reviewer, and stale branches each have a dedicated check. Use this whenever you want to confirm nothing has fallen through the cracks (new activity landed, a periodic sweep, before reporting "everything's triaged").
---
# Forge Triage
Checking triage coverage doesn't need a bespoke script or a manual scan
of the tracker - the forge CLI's `lint` verbs already answer each
dimension directly.
## The checks
- **Unassigned items** - open issues or PRs with no assignee:
`hive-forge lint unassigned`
- **Missing labels by scope** - items missing any label in a given
scope (e.g. every issue should carry a `type/*` label, or an `area/*`
one): `hive-forge lint unlabeled --scope <scope>`. The scope name is
whatever your repo's own label taxonomy uses - there's nothing
hardcoded, so check `repo-labels` first if you don't already know the
scopes in use.
- **PRs with no formally requested reviewer** - `hive-forge lint
no-reviewer` flags PRs with zero requested reviewers at all; add
`--reviewer <name>` to instead flag PRs where that specific person
isn't among the requested reviewers. This checks the forge's actual
reviewer-request state, not a text `@name` mention anywhere in the
thread.
- **Assignment load** - `hive-forge lint assignments` groups open
issues + PRs by assignee, useful for spotting an overloaded or
neglected owner.
- **Stale branches** - `hive-forge lint stale-branches --days <n>`
finds remote branches with no recent commits (skips branches that are
heads of open PRs), useful for spotting abandoned work.
## Using them as a sweep
Run the checks relevant to what you're verifying rather than assuming
one covers everything - "is triage caught up" usually means unassigned
+ unlabeled at minimum, with no-reviewer added if reviews matter for
your workflow. Each verb supports `--json` if you want to fold the
results into something else instead of reading the human-readable output.
This is reactive/on-demand coverage checking, not a scheduled rollup or
historical trend - if you need to track compliance *over time* (was
triage worse last week than this week), that's a different, bigger
ask than running these checks - don't build that unprompted just
because the checks exist.