用途：帮助用户创建、提交或登记 GitHub Issue，写作目标是让毫无上下文的读者在 30 秒内理解问题并着手修复。
主要能力与写作规则：标题一行、少于 10 个词，直接点明实际问题而非模糊症状；正文少于 150 词，使用平实语言，开头一句话说明问题，不写前言、不重复标题。只使用 What happens、Steps to reproduce、Expected 三个小节；仅在确有证据时各用一句话补充 Cause 或 Suggested fix。复现步骤编号、每行一个动作、不加评论。只保留关键证据，如一个数字、错误或日志行。除确实不确定外不做模糊表述，不确定时用一句话点明。不写背景、备选方案、影响推测和结尾总结。
使用方式：先搜索重复项，可用 gh issue list --search "<keywords>" --state all --limit 20 或 gh search issues，尝试错误文本、功能名、组件等两三种措辞，并包含已关闭 Issue。若找到可能重复项则停止提交，向用户报告编号、标题、状态、相似原因及建议下一步（补充评论、重新打开、仍提交或放弃），等待用户确认后再新建。若无相关结果，用一行说明后继续。写作前检查 .github/ISSUE_TEMPLATE/ 及旧版 .github/ISSUE_TEMPLATE.md，若有适用模板则遵循其结构并保持简洁；YAML 表单每个字段渲染为 ### 标签标题加答案，不省略小节，不适用写 N/A。若信息不足以填写复现步骤或预期结果，应向用户询问而非猜测或填充。提交前重读正文，删除不影响读者下一步行动的句子。提交后不要向用户回显 Issue 编号、URL 或正文。
适用场景：需要快速、清晰地记录 GitHub 缺陷、功能请求或任务时。
限制：依赖 create_issue 工具与 gh 命令行；模板与搜索行为取决于目标仓库配置；资料未提供具体安装、收费或平台信息。