github-issue-creator

GitHub Issue Creator 是一款专注于提升缺陷报告效率的文档整理工具，旨在将非结构化的原始输入——包括语音听写、错误日志粘贴、截图描述或随手笔记——转化为符合 GitHub 标准的专业 Issue 报告。

核心用法围绕"混乱到秩序"的转换流程。用户只需将任意形式的 bug 描述、系统报错或功能反馈以自然语言提供给 Skill，系统会自动提取关键信息并套用标准化模板。模板涵盖问题摘要、环境信息、复现步骤、预期与实际行为对比、错误详情代码块、视觉证据引用以及影响等级评估等完整字段。特别值得注意的是，该工具支持多媒体证据处理，能够内联引用截图和 GIF 动画，并自动识别敏感数据建议使用占位符（如 [PROJECT_NAME]）进行脱敏处理。输出结果以 Markdown 文件形式存储在仓库的 /issues/ 目录下，采用 YYYY-MM-DD-short-description.md 的命名规范，便于版本控制和后续追踪。

显著优点体现在标准化与效率提升方面。首先，它强制实施 GitHub Flavored Markdown 规范，确保团队成员提交的 Issue 格式统一，大幅降低沟通成本。其次，智能推断能力可以从口语化的语音输入或碎片化的聊天记录中自动提取结构化要素，减少人工整理时间。再者，本地文件生成机制避免了直接操作远程 API 可能带来的权限风险，同时支持离线使用。

潜在缺点在于明显的功能边界。最大的局限性是仅生成本地模板文件，无法直接调用 GitHub API 创建远程 Issue，用户仍需手动复制内容或提交文件。此外，输出质量高度依赖输入信息的完整度，若用户提供的关键上下文（如浏览器版本、错误代码）缺失，生成的报告可能仍需二次补充。来源可信度为 T3 级（个人开发者），虽经安全审计无代码风险，但长期维护稳定性存疑。

适合的目标群体主要包括软件开发团队的工程师、质量保证人员以及产品经理。特别适合那些在移动端或会议场景下通过语音快速记录 bug，后续需要整理为正式文档的敏捷开发团队。对于需要严格合规审计的企业环境，该工具的透明文档特性也颇具吸引力。

使用风险方面，尽管 Skill 本身无恶意代码，但用户需警惕敏感数据泄露风险——若未遵循占位符建议，直接将包含 API 密钥、用户 ID 的日志粘贴至输入框，生成的 Markdown 文件将以明文形式保存。此外，频繁的本地文件写入可能导致 /issues/ 目录管理混乱，建议配合 Git 版本控制使用。性能上，处理超长日志文件（如数万行堆栈跟踪）时可能存在上下文窗口限制。

核心用法

GitHub Issue Creator 是一款纯文本转换工具，专为开发者设计。用户可粘贴任何非结构化输入——包括语音转录文本、控制台错误日志、崩溃截图或随手记的 Bug 描述——Skill 会自动提取关键信息，输出符合 GitHub 标准格式的 Markdown Issue 文档。

输入处理流程：
1. 解析用户原始输入，识别环境信息（产品名称、版本、浏览器等）
2. 从非正式语言中抽取结构化要素：问题摘要、复现步骤、预期/实际行为
3. 自动推断缺失上下文（如"这个项目"指代当前对话中的仓库）
4. 敏感数据自动脱敏（[PROJECT_NAME]、[USER_ID] 等占位符）
5. 按预设模板组装输出，支持图片引用内嵌

显著优点：

• 零配置即用：无需连接 GitHub API，纯本地文本处理，即开即用
• 智能结构化：擅长从口语化描述（"it just failed silently no error nothing"）中提炼技术要素
• 隐私安全：本地处理，不传输用户数据至外部服务
• 上下文感知：结合对话历史补全"same dashboard"等模糊指代
• 视觉证据友好：原生支持 ![Description](attachment.png) 图片引用格式

潜在局限：

• 无法自动创建真实 GitHub Issue（需用户手动复制粘贴至 GitHub）
• 依赖用户输入质量，极端模糊的描述可能导致信息提取不完整
• 无版本控制集成，不支持自动关联 commit 或 PR
• 严重级别判断基于文本模式匹配，复杂场景需人工复核

适合人群：

• 需要快速记录 Bug 的开发者、测试工程师、产品经理
• 习惯语音/速记捕捉问题的敏捷团队
• 非技术用户需要向开发团队提交结构化反馈的场景

常规风险：

• 极低。纯 Markdown 技能，无代码执行、无外部网络请求、无持久化存储。用户需注意：敏感信息脱敏为占位符后，仍需在最终提交前人工审查确认。