Repo Init

repo-init

Apply a canonical issue-label set to a GitHub repo. This file is the source of truth — edit it to evolve the scheme, then re-run on affected repos to bring them in line.

Scope

• Yes: issue labels (create/update the six canonical ones, remove the seven OSS defaults).
• No: issue templates. Those flow automatically from the owner's .github repo and need no per-repo action.
• No: repo creation itself. Run gh repo create first.

Usage

Inside a repo:

/repo-init

Target auto-detected via gh repo view.

Targeting another repo:

/repo-init owner/name

Canonical labels

| Name | Colour | Description | | ---------- | --------- | ------------------------------------------------------- | | bug | d73a4a | Something isn't working | | feature | a2eeef | A capability someone gains | | refactor | bfd4f2 | Internal quality — same behaviour, better shape | | chore | ededed | Mechanical maintenance — deps, config, infra | | afk | 0e8a16 | Agent can ship this end-to-end without human input | | hitl | fbca04 | Needs human judgement — architecture, design, or policy |

Type vs workflow. bug / feature / refactor / chore are mutually-exclusive types — one per issue. afk / hitl are orthogonal, tagging who can pick up the issue.

OSS defaults to remove

GitHub ships every new repo with these. Mostly noise for small-team / agent-driven workflows:

• documentation
• duplicate
• good first issue
• help wanted
• invalid
• question
• wontfix

Removing a label strips it from any existing issues that have it. For a brand-new repo there won't be any.

Process

1. Resolve target. If an argument was passed (owner/name), use it. Otherwise: gh repo view --json nameWithOwner --jq .nameWithOwner from the current directory.
2. Apply canonical labels. For each row in the table: gh label create -R --color --description "" --force. The --force flag updates colour/description if the label already exists.
3. Strip OSS defaults. For each: gh label delete -R --yes. Ignore not-found errors (label may already be absent).
4. Sibling check. Run gh repo view /.github >/dev/null 2>&1 — if absent, flag once that the owner has no .github repo and issue templates won't auto-populate. Don't create it; that's a separate decision.
5. Summary. Print one line: target repo, count of labels set, count of labels removed.

Reference implementation

TARGET="${1:-$(gh repo view --json nameWithOwner --jq .nameWithOwner)}"
OWNER="${TARGET%%/*}"

CANONICAL=(
  "bug|d73a4a|Something isn't working"
  "feature|a2eeef|A capability someone gains"
  "refactor|bfd4f2|Internal quality — same behaviour, better shape"
  "chore|ededed|Mechanical maintenance — deps, config, infra"
  "afk|0e8a16|Agent can ship this end-to-end without human input"
  "hitl|fbca04|Needs human judgement — architecture, design, or policy"
)
DEFAULTS=(documentation duplicate "good first issue" "help wanted" invalid question wontfix)

set_count=0; rm_count=0
for line in "${CANONICAL[@]}"; do
  IFS='|' read -r name color desc /dev/null && ((set_count++))
done
for label in "${DEFAULTS[@]}"; do
  gh label delete "$label" -R "$TARGET" --yes >/dev/null 2>&1 && ((rm_count++))
done

gh repo view "$OWNER/.github" >/dev/null 2>&1 || \
  echo "Note: $OWNER has no .github repo — issue templates won't auto-populate."

echo "$TARGET: $set_count labels set, $rm_count removed."

Notes

• Personal GitHub accounts have no org-level default-labels feature, so this skill is the only way to bootstrap them.
• Organisations do have native default labels (Settings → Repository defaults → Labels), but keeping the spec in this file avoids splitting it between an org-settings UI and a tracked file.
• The label scheme pairs with the AFK / HITL tag in tracer's vertical-slice template — applying the label promotes that body-level judgement into a board-filterable signal.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: steveu
• Source: steveu/skills
• License: MIT

Install and usage instructions live in the source repository linked above.