Doc location
.github/labels.yml or new docs/development/labels.md + one-line link in CONTRIBUTING
What kind of change?
Missing section
What’s wrong or missing?
Labels exist and sync via CI, but there is no short guide for when to use area:*, platform:*, needs design, needs info, etc. Some issues pick unrelated labels (e.g. agent-bus on a VRoid Hub UI item).
Suggested fix (optional)
Document in plain language:
- One primary
area:* per issue when possible.
platform:electron vs platform:browser vs installer.- When to use
needs design vs needs info.
- No
future:* / roadmap:* style labels; use neutral capability labels instead (for example: area:animations, keyword-triggers, keybindings, agent-bus) even before implementation lands.
good first issue criteria (scoped, no secrets, clear acceptance).
Optional: audit open issues and fix obvious label mismatches in a follow-up PR (separate from writing the guide).
Checklist
Doc location
.github/labels.ymlor newdocs/development/labels.md+ one-line link in CONTRIBUTINGWhat kind of change?
Missing section
What’s wrong or missing?
Labels exist and sync via CI, but there is no short guide for when to use
area:*,platform:*,needs design,needs info, etc. Some issues pick unrelated labels (e.g. agent-bus on a VRoid Hub UI item).Suggested fix (optional)
Document in plain language:
area:*per issue when possible.platform:electronvsplatform:browservs installer.needs designvsneeds info.future:*/roadmap:*style labels; use neutral capability labels instead (for example:area:animations,keyword-triggers,keybindings,agent-bus) even before implementation lands.good first issuecriteria (scoped, no secrets, clear acceptance).Optional: audit open issues and fix obvious label mismatches in a follow-up PR (separate from writing the guide).
Checklist