github-create-issue

用途

github-create-issue 是一个智能体技能，用于帮助用户创建维护者能够实际处理的 GitHub Issue。它的核心目标是让提交的 issue 经过验证、不重复、符合仓库约定（模板/标签/前缀），并在发布前经过预览和用户确认。

客观性优先：避免“看起来不错”这类模糊表述，要求以具体方式展示影响范围和预估难度。
发布前必须确认：在发布前展示最终形态（标题、正文、标签、仓库），并获得用户明确批准。
利用仓库上下文：通过 git log、分支名、已有 issue、标签来推断仓库约定，包括语言、前缀风格、正文结构、标签词汇。
去重检查：先检查是否已有类似 issue，若有则建议评论或引用，而非新建。
事实验证：按 issue 类型（bug、改进/功能、文档/UX）验证用户所述是否属实。
价值与难度评估：以具体数字估算受影响用户比例、量化影响、变更行数、涉及文件数等。
分类与前缀：根据情况选择 bug:、improve:/enhancement:、feat:、docs:/chore:/discuss: 等前缀，并优先遵循仓库已有约定。
模板选择：优先使用仓库的 .github/ISSUE_TEMPLATE/，其次参考已有 issue，最后回退到内置模板。
篇幅控制：提供 short、medium、long 三档正文长度建议。
双版本撰写：生成两个有实质差异的标题和正文版本（如问题导向与方案导向）供用户选择。
发布与报告：使用 gh issue create 发布，正文通过 heredoc 传入，成功后报告 URL。

该技能以工作流形式运行，步骤之间存在需要用户输入的决策点，不应一次性完成所有操作。

确认意图：确认问题/请求是什么、在哪里发现、期望结果、正文语言。若有歧义则先追问最关键的一项。
验证：先检查重复 issue，再验证事实。若验证困难或依赖环境，应明确说明，不要猜测填充。
评估价值与难度：用具体数字估算，数字小就如实报告，不夸大。
决定分类：先检测项目约定，扫描 git log --oneline -20 和近期 issue 标题。若用户直接指定前缀则无条件使用。
选择模板：优先仓库 .github/ISSUE_TEMPLATE/，YAML 表单转为 markdown 标题，Markdown 模板照用；无模板则参考已有 issue；都没有则回退到 references/issue_templates.md。同时检查标签是否存在。
选择篇幅：推荐默认值并询问用户。
撰写正文（两个版本）：两个版本必须有实质差异，并各附一行“为什么选这个版本”。
上传预览 + 确认：展示最终形态，确认仓库，模板自动附加的标签照用，额外标签需征得同意。未获同意不得上传。
发布 + 报告 URL：使用 gh issue create 命令，正文用 heredoc 传入。成功则一行报告 URL，失败则展示原始错误并与用户决定下一步。