$npx -y skills add warpdotdev/oz-for-oss --skill bootstrap-issue-configBootstrap the issue triage configuration for a repository by analyzing existing issues, labels, and contributors to generate .github/issue-triage/config.json and .github/STAKEHOLDERS. Use when setting up triage automation on a new or existing repository for the first time.
| 1 | # Bootstrap issue triage configuration |
| 2 | |
| 3 | Analyze the target repository and generate (or update) the issue triage configuration files used by the `triage-new-issues` workflow. |
| 4 | |
| 5 | ## Outputs |
| 6 | |
| 7 | This skill produces two files: |
| 8 | |
| 9 | 1. **`.github/issue-triage/config.json`** — label definitions used during triage. |
| 10 | 2. **`.github/STAKEHOLDERS`** — CODEOWNERS-style ownership mappings from path patterns to GitHub usernames. |
| 11 | |
| 12 | ## Workflow |
| 13 | |
| 14 | ### 1. Discover existing labels |
| 15 | |
| 16 | - Use `gh label list --repo <owner>/<repo> --limit 200 --json name,color,description` to fetch all labels currently defined on the repository. |
| 17 | - Classify each label into one of three categories: |
| 18 | - **area** labels — identify a component or subsystem (e.g. `area:api`, `area:docs`). |
| 19 | - **feature** labels — identify a capability or request type (e.g. `enhancement`, `bug`, `documentation`). |
| 20 | - **status** labels — identify workflow state (e.g. `triaged`, `needs-info`, `wontfix`). |
| 21 | - If the repository has very few or no labels, seed the config with sensible defaults: |
| 22 | - `triaged` (status), `bug` (feature), `enhancement` (feature), `documentation` (feature), `needs-info` (status), `duplicate` (status) |
| 23 | - `repro:high`, `repro:medium`, `repro:low`, `repro:unknown` (status) |
| 24 | |
| 25 | ### 2. Analyze recent issues |
| 26 | |
| 27 | - Use `gh issue list --repo <owner>/<repo> --state all --limit 100 --json number,title,labels,createdAt` to fetch recent issues. |
| 28 | - If issues use labels that are not yet captured, add them to the appropriate category. |
| 29 | - Look at `.github/ISSUE_TEMPLATE/` for template files — template names and labels referenced in templates can inform label discovery. |
| 30 | |
| 31 | ### 3. Generate or update `config.json` |
| 32 | |
| 33 | - Read any existing `.github/issue-triage/config.json`. |
| 34 | - Merge newly discovered labels into the existing `labels` object. Do **not** remove labels that already exist in the config — only add or update. |
| 35 | - The config must contain **only** the `labels` key. Do **not** include `stakeholders` or `default_experts`. |
| 36 | - Each label entry should have `color` (6-character hex without `#`) and `description` (one-sentence summary). |
| 37 | - Write the result to `.github/issue-triage/config.json`. |
| 38 | - Validate with `jq . .github/issue-triage/config.json`. |
| 39 | |
| 40 | ### 4. Generate or update `.github/STAKEHOLDERS` |
| 41 | |
| 42 | - Inspect `CODEOWNERS` if it exists for initial ownership hints. |
| 43 | - Use `git log --format='%aN <%aE>' --since='6 months ago' -- <path>` and `gh api` to identify recent contributors to major directories. |
| 44 | - Read any existing `.github/STAKEHOLDERS` file and merge new entries rather than overwriting. |
| 45 | - Write the file using CODEOWNERS conventions: |
| 46 | ``` |
| 47 | # Syntax follows CODEOWNERS conventions: later rules take precedence. |
| 48 | # NOTE: This file is advisory only — GitHub does not enforce it. |
| 49 | |
| 50 | # --- Section comment --- |
| 51 | /path/pattern/ @owner1 @owner2 |
| 52 | ``` |
| 53 | - Each line maps a path glob to one or more `@username` owners. |
| 54 | |
| 55 | ### 5. Create missing labels |
| 56 | |
| 57 | - For every label in the final `config.json` that does not already exist on the repository, create it: |
| 58 | ``` |
| 59 | gh label create "<name>" --color "<color>" --description "<description>" --repo <owner>/<repo> |
| 60 | ``` |
| 61 | - Skip labels that already exist (the `gh label create` command will error on duplicates — ignore those errors). |
| 62 | |
| 63 | ### 6. Note repo-local companion skills (do not scaffold) |
| 64 | |
| 65 | The reusable agent roles that support a repo-specific companion are: |
| 66 | |
| 67 | - `.agents/skills/review-pr-local/SKILL.md` |
| 68 | - `.agents/skills/review-spec-local/SKILL.md` |
| 69 | - `.agents/skills/triage-issue-local/SKILL.md` |
| 70 | - `.agents/skills/dedupe-issue-local/SKILL.md` |
| 71 | |
| 72 | Do **not** create these files during bootstrap. The prompt-construction layer treats a missing companion file and a body-only frontmatter stub the same way, so there is no value in materializing an empty file during bootstrap. Each file gets created on-demand by the matching `update-<agent>` self-improvement loop (or by a maintainer) the first time there is evidence-backed content to add. Bootstrap only needs to ensure the directory convention is documented; the files themselves stay absent until a real rule lands. |
| 73 | |
| 74 | If a companion file already exists in the repo, leave it untouched; bootstrap is additive. |
| 75 | |
| 76 | ### 7. Validate and summarize |
| 77 | |
| 78 | - Re-validate `config.json` with `jq`. |
| 79 | - Print a short summary of: |
| 80 | - How many labels were discovered vs. newly created. |
| 81 | - How many stakeholder entries were written. |
| 82 | - Which repo-local companion skills are already present in the repo (if any). |
| 83 | - Any warnings (e.g. no issues found, no CODEOWNERS file). |
| 84 | |
| 85 | ## Idempotency |
| 86 | |
| 87 | This skill is designed to be run multiple times safely. Re-running will: |
| 88 | - Merge new labels into the existing config without removing old ones. |
| 89 | - Merge new st |