label-systemlisted

A minimal, opinionated GitHub label taxonomy for OSS / internal projects covering priority, area, issue status, PR review state, and independent reproduction. Use when setting up labels for a new repo, when triaging a backlog, when asked "how should we label issues", when reviewing whether existing labels are coherent, or when applying labels to a batch of open issues. Five orthogonal axes, ~16 labels total, every label answers a specific filter query — designed against the open-source convention of `S-waiting-on-*` (Rust) and two-stage approval (Kubernetes), but kept small enough for a solo / small-team repo to actually maintain. Includes a bootstrap script (`scripts/bootstrap-labels.sh`) that creates the full label set in a target GitHub repo with one `gh` call per label.
bingran-you/bingran-you · ★ 2 · Code & Development · score 73

Install: claude install-skill bingran-you/bingran-you

# Label System — five-axis GitHub label taxonomy A small, opinionated label vocabulary for GitHub issues and PRs. Every label has to **answer a query**; otherwise it's noise and gets cut. Tested against benchflow's v0.5 backlog (31 open issues, ~3.5 labels/issue average). ## When to use this skill - Setting up labels for a new GitHub repo. - Triaging an issue backlog where labels have drifted into "kitchen sink" territory. - Helping a user audit whether their existing label set has clear, mutually-exclusive meanings. - Applying labels in bulk to many issues at once. - Designing a labeling convention that other contributors can reason about without a long Notion doc. If the user just asks "make me a label", you do not need this skill — `gh label create` is one line. ## Five orthogonal axes (~16 labels) Each axis answers exactly one question. **Don't add a sixth axis unless you can name the query it serves.** | Axis | Question it answers | Cardinality | |---|---|---| | **Priority** | "Should I work on this now?" | 1 of 3 (`P0` / `P1` / `P2`) | | **Area** | "Which part of the codebase?" | 1–2 of 4–8 (`area:*`) | | **Issue status** | "Where is this in its lifecycle?" | 1 of 4 (`status:*`) — issue only | | **PR review** | "Where is this in code review?" | 1 of 4 (`review:*`) — PR only | | **Reproduced** | "Has anyone else confirmed this is real?" | 0 or 1 (`reproduced`) — bug only | GitHub native fields handle the rest: - `assignee` → who's on it (no `status:claimed` label