| name | gum-issue-creation |
| description | Conventions for filing GitHub issues in the Gum repo via gh. Triggers when the user asks to "log an issue", "create an issue", "file a bug", or otherwise capture a problem/idea as a GitHub issue (as opposed to fixing one). |
Creating Gum Issues
Use gh issue create to file issues. Conventions:
Before researching the source pointer
Check the skills list for one matching the feature area and load it before grepping for the file:line pointer — CLAUDE.md's "load matching skills before investigating" rule applies to issue research too, not just edits. A matching skill (e.g. gum-tool-variable-grid for a Variables-tab/displayer report) names the relevant files and known gotchas directly instead of rediscovering them by grep.
Don't file
Sokol is not held to per-backend feature parity — a feature that ships on the MonoGame family, raylib, and Skia but not SokolGum is not a tracked gap.
Issues you file yourself
A value you printed while diagnosing something else is an observation, not a report — name what a user would see, or don't file. Say in the body that it came from instrumentation.
Suggested improvement must not assert an unverified convention ("editors conventionally do X"). Verify it or write it as an open question: asserted, it becomes the issue's premise, and whoever picks the issue up implements against it without rechecking.
Labels
- Bug reports get
--label bug (label exists, color #fc2929). Apply it at creation time.
- The
bug label is real and applies silently — don't second-guess it or omit it on later issues.
Multi-line bodies
gh runs through the Bash tool (bash, not PowerShell) — do NOT use PowerShell here-strings (@'...'@); a stray leaks onto the first body line. Write the body to a temp file and pass :