Bootstrap a GitHub repo for gh-pms — detects available native features (Issue Types, Projects v2, Milestones), provisions what's missing, drops in issue templates and a PR template. Run this once per repo before using gh-pms. Idempotent. Auto-invoke when the user is in a repo without the gh-pms project, or when they say "set up issues", "init pms", "bootstrap this repo".

Bootstrap the current repo so the rest of gh-pms can run with full GitHub-native primitives.

When to use

User is in a fresh repo and says "set up", "init", "bootstrap"
A gh-* skill reports missing infrastructure (no project, no labels, no milestones)
User explicitly invokes /gh-pms:gh-init

Step 1 — Verify location

Run gh repo view --json nameWithOwner -q .nameWithOwner (via Bash). If it fails, fail with: gh-init: not in a GitHub repo. Run from inside one.

Step 2 — Detect native features

bash

This returns JSON like:

json

Use this to decide which primitives to provision.

Step 3 — Provision Issue Types (if available)

If issue_types: true AND the org has at least Feature/Bug/Task: nothing to do — types are already at org level. Just remember the IDs for later steps.

If issue_types: false: skip; we'll use type:* labels.

Step 4 — Provision Projects v2 (opt-in)

If the user passed --with-project (or said "create a project too"):

a. Check token scope: gh auth status | grep "'project'". If missing, run:

gh auth refresh -s project

and ASK the user to complete the browser flow before continuing.

b. Create or find the project:

bash

c. Ensure the required fields exist (idempotent):

bash

If the user opts out: skip; status lives on labels only.

Step 5 — Provision labels (always)

Even with native types + projects, labels are the visible-at-a-glance signal in the issue list. Always create the full label set:

bash

Step 6 — Drop in templates

Copy from this plugin's templates/ to the active repo's .github/:

text

If a target already exists, ASK before overwriting.

Step 7 — (optional) Drop in a per-repo config skeleton

If the user passed --customize (or said "I want to override severities/services/gates"):

bash

The example is fully commented — every section is opt-in. Skipping --customize is fine for teams running with the canonical defaults; the loader gracefully falls back when no override file exists.

Verify the merged result anytime:

bash

Step 8 — Commit templates

bash

Do NOT add Co-Authored-By trailers. Use the user's git config.

Step 9 — Report

text

Notes

Re-running is safe end-to-end
--with-project requires project token scope — user must run gh auth refresh -s project once
Issue Types are an org-level setting; can't be created from the plugin. If you want them on a user repo, the only path is to move the repo to an org first.