setup-github-labels

Apply and document a canonical GitHub issue and pull-request label set in a repository.

Updated Aug 6, 2026
One-click install
npx skills add https://github.com/wkentaro/skills --skill setup-github-labels-wkentaro
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: setup-github-labels
Source: https://github.com/wkentaro/skills/tree/main/skills/in-progress/setup-github-labels
Command: npx skills add https://github.com/wkentaro/skills --skill setup-github-labels-wkentaro

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Repositories accumulate inconsistent label vocabularies that break triage workflows and confuse automation. This Skill applies one canonical label manifest to a GitHub repo, renames legacy labels without losing issue history, and documents the label contract for agents. ## Core Features & Use Cases - Manifest-driven label sync: Reads labels.json as the single source of truth and previews creates, updates, and renames before applying anything with gh label commands. - History-preserving renames: Runs gh label edit --name before gh label create --force so existing issues keep their labels through a rename. - Contract documentation: Creates or updates docs/agents/triage-labels.md mapping /triage roles to issue and PR labels, and adds a minimal pointer in AGENTS.md. - Use Case: You adopt an agent-driven triage workflow and need every repo to share the same type:*, triage-state, and recommend-* verdict labels. Run the skill to preview the diff, confirm, apply, and document the contract in one pass. ## Quick Start Use the setup-github-labels skill to preview, apply, and document the canonical labels in this repository.

Frequently Asked Questions about setup-github-labels

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I apply a standard set of GitHub labels to a repository?▼

Run the skill in the target repo: it detects the repo with `gh repo view`, previews creates, updates, and renames from `labels.json`, then applies them with `gh label create --force` after you confirm. Repeat with another repo to set up several.

How do I rename a GitHub label without losing it on existing issues?▼

Set `renamed_from` in `labels.json` and the skill runs `gh label edit <old> --name <new>` before creating the new label. Renaming keeps the label attached to every issue and PR, whereas creating a new label would leave them on the old one.

Does this delete labels that are not in the manifest?▼

No. Labels on the repo that are not in `labels.json` are left untouched. Deletion is a separate deliberate step using `gh label delete`, because it strips the label from every issue and PR.

What tools are required to run the GitHub label setup?▼

The workflow uses the GitHub CLI (`gh`) for label operations and `jq` to read the `labels.json` manifest. Both must be installed and `gh` must be authenticated against the target repository.

Why use recommend-merge instead of ready-to-merge for PR labels?▼

Merge bots such as Kodiak, Mergify, bors, and GitHub auto-merge watch the `ready-to-merge` string, so using it would turn an agent recommendation into an actual merge. The `recommend-*` family records a verdict while the maintainer still merges.