Structured Output
Every bug report follows this structure:
- Title — concise summary (max 8 words)
- What happens — description of the bug behavior
- Git context — current branch and recent changes
- Repro steps — inferred from description or placeholder steps
- Expected vs Actual — comparison format
Severity Auto-Detection
The system infers severity from your description:
| Severity | Trigger Words | Example |
|---|---|---|
| Critical | crash, data loss, security, down, blocks | ”App crashes on startup” |
| High | broken, fails, can’t, regression | ”Login form fails validation” |
| Medium | wrong, incorrect, unexpected, slow | ”API returns wrong data” |
| Low | minor, cosmetic, typo, alignment | ”Button misaligned on mobile” |
Git Integration
A single Bash call captures:
- Current branch name
- Summary of recent changes (last few commits)
- Modified files relevant to the bug area
This context is automatically included in the bug report, so the next developer can see what changed near the bug.
When to Use /note-bug
Use /note-bug instead of /note when you want:
- Automatic severity tagging
- Git context in the report
- Structured repro steps format
- Pink color coding for easy identification