GitHub Issue 创建器

问题从哪来

日常排障和反馈往往落在 Slack 语音转写、随手粘贴的堆栈、或「部署又挂了但控制台啥也没有」这类半结构化碎片里。直接丢进 GitHub Issue 标题和正文，读者要自己猜复现路径、严重程度和是否涉及敏感信息，Issue 质量参差，也不利于后续检索。

技能如何整理输出

本技能把杂乱输入收敛成一份可执行的 Issue 草稿，并以 Markdown 文件形式写入仓库根目录的 issues/（命名：YYYY-MM-DD-short-description.md），而不是只在对话里给一段文字。

核心做法包括：

• 从口语里抽事实：听写里的「跑了三次、刷新才看见」会被整理成复现步骤与现象描述，去掉 filler。
• 补全隐含上下文：若提到「同一个项目」「那个仪表盘」，结合对话或记忆补全项目名、模块名（无法确认时用占位符）。
• 敏感信息占位：对可能泄露的内容使用 [PROJECT_NAME]、[USER_ID] 等，避免原样进仓库。
• 严重程度对齐影响：按 Critical / High / Medium / Low 与「宕机、数据丢失、安全」到「轻微 UI」的梯度匹配，而不是一律标 High。
• 错误块与附件：错误消息单独成块；截图/GIF 用行内附件引用格式，便于在 Issue 正文里对齐。

输出结构通常包含：标题级摘要、错误消息/代码（如适用）、复现或背景、期望与实际行为，以及已标注的严重级别。

适用边界

• 产出是本地/仓库内的 Issue 草稿文件，是否创建 GitHub 上的远程 Issue 仍取决于你的工作流（例如再粘贴或由其它工具提交）。
• 严重级别与占位符依赖模型对上下文的推断；涉及合规或生产事故时，提交前应由人复核。
• 图片/GIF 需要你在环境中具备可引用的附件路径或约定，技能只规范引用格式，不负责上传 GitHub Assets。