用途：create-compelling-issues 用于在提交 GitHub Issue 时规范流程，避免重复、无效或指向已修复问题的工单。核心主张是：Issue 是对“需要工作”的声明，提交前必须证明缺口仍存在。
主要能力：1）先搜索再提交：检索开放与已关闭 Issue 以及已合并 PR，至少用症状与文件/函数名两组关键词，命令如 gh search issues --repo "$R" --limit 20 "<symptom keywords>"、gh search prs --repo "$R" --merged --limit 20 "<symptom keywords>"、gh search issues --repo "$R" --match title --limit 20 "<file or function>"。若已有开放 Issue 则补充证据评论；已关闭但仍复现则评论请求重开；已合并 PR 修复则直接报告；均无才提交并引用所执行的搜索。2）查阅仓库 playbook：标签语义属于各公司政策，技能自身不掌握；需读 playbook 或 CONTRIBUTING.md、.github/ISSUE_TEMPLATE/，确认哪些标签由自动化/分诊拥有、哪些标签可使 Issue 退出自动化、Epic 约定。无提交政策时不打工作流标签，照常提交并注明。3）正文与评论的持久性区分：正文可被自动化改写，需逐字保留的内容（清单、ID、版本、机器标记）应放在评论中。4）证据标准：每个断言需有代码阅读或探测依据，并附提交 SHA、命令输出、日志行、请求 ID 等凭据；避免“大概”“似乎”“应该”。5）合理拆分：一个 Issue 对应一个交付物，验收标准应可二元检查，跨仓库引用需带组织名（org/repo#N）。
提供正文模板：Problem、Evidence、Searched、Acceptance criteria、Out of scope。另有自审清单。
限制：技能不定义具体标签语义，需依赖仓库政策；未提供收费、价格、平台支持等信息；未提供安装命令或完整代码示例。