结构化输出
每份 Bug 报告都遵循这个结构：
- 标题 — 简洁的摘要（最多 8 个词）
- 发生了什么 — 对 Bug 行为的描述
- git 上下文 — 当前分支和最近的改动
- 复现步骤 — 从描述推断，或给出占位步骤
- 预期 vs 实际 — 对比格式
严重程度自动判断
系统会从你的描述推断严重程度：
| 严重程度 | 触发词 | 示例 |
|---|---|---|
| Critical | 崩溃、数据丢失、安全、宕机、阻塞 | 「App 启动时崩溃」 |
| High | 损坏、失败、用不了、回归 | 「登录表单校验失败」 |
| Medium | 错误、不对、不符预期、变慢 | 「API 返回错误的数据」 |
| Low | 小问题、外观、拼写、对齐 | 「手机上按钮没对齐」 |
git 集成
一次 Bash 调用就能抓取：
- 当前分支名
- 最近改动的摘要（最近几个提交）
- 与 Bug 区域相关的已修改文件
这些上下文会自动加进 Bug 报告里，下一个开发者就能看清 Bug 附近改了什么。
什么时候用 /note-bug
当你需要以下这些时，用 /note-bug 而不是 /note：
- 自动打上严重程度标签
- 报告里带 git 上下文
- 结构化的复现步骤格式
- 粉色配色，便于一眼认出