用途：把一段关于缺陷的对话转换为 GitHub issue，重点是让问题在经历重大重构后仍然读得懂，写法贴近维护者的语言风格。
主要流程与能力：
- 先听用户用自己的话描述问题，最多追问两个简短问题（预期行为与实际行为、具体复现步骤、出现频率是确定性、间歇性还是一次性）；若描述已覆盖则直接进入提交。
- 并行探索代码库相关区域，目的不是提出修复方案，而是吸收项目自身词汇（该功能使用的名词与动词）；如果仓库有术语表文件（常见名 GLOSSARY.md、UBIQUITOUS_LANGUAGE.md、docs/domain.md），先读它。
- 提交前查重，运行 gh issue list --search "<key phrase>" --state all --limit 10，若匹配到活跃或近期关闭的 issue，向用户展示并询问是否改为添加评论，不静默跳过提交。
- 判断单条 issue 还是拆分：当报告包含两个及以上可由不同贡献者并行修复的独立失败模式时拆分；所有症状都源于同一错误行为则保持单条。拆分时按依赖顺序提交，子 issue 可引用真实父编号，并诚实标注 Blocked by 链接，不凭空捏造依赖。
- 用 gh issue create 提交，不让用户审阅草稿，事后返回 URL。提供单条 issue 模板（What happened / What I expected / Reproduction / Context）与子 issue 模板（Parent / What is wrong / What I expected / Reproduction / Blocked by / Context）。
- 每个 issue 正文的通用规则：不写文件路径、行号、函数名或 PR 编号，这些会过期，描述行为而非代码；使用项目领域名词而非通用技术术语；复现步骤必填，无法推导时回去再问用户一次；控制为三十秒可读完，删掉无助维护者判断是否接手的内容。
- 每条 issue 完成后打印 URL 并询问是否还有下一条，不把多条报告合并为一次提交。
适用场景：用户报告缺陷、需要沉淀为可追踪 GitHub issue 的开发流程。限制：资料未说明具体安装命令、依赖环境、收费与平台要求，暂未提供；示例命令需在已配置 gh 的环境中使用。