用途：当用户要求创建 GitHub issue、报 bug、提功能请求、开追踪 issue，或把一个大功能拆成多个子 issue 时，这个技能引导生成结构清晰的 issue。
主要能力
- 自动检测当前仓库：GitHub 用 gh repo view --json nameWithOwner -q '.nameWithOwner'，GitLab 用 glab repo view -F json | jq -r '.path_with_namespace'，检测失败则询问目标仓库。
- 创建前先澄清：功能类问题询问用户目标、验收标准、UI/UX 影响、关联功能、优先级与范围；缺陷类问题询问复现步骤、期望与实际行为、环境、严重程度、错误日志。每轮问 2-3 个聚焦问题。
- 按功能/缺陷模板起草 issue，包含摘要或复现步骤、需求或期望/实际行为、测试要求（测试用例文档、单元测试、E2E 测试）、带复选框的验收标准、依赖关系等必需章节。
- 对每条验收标准判断是否可在合并前验证：可用 CI 任务、PR 预览地址、预发命令或本地复现提供证据的优先；只能在部署/生产、真实用户、时间浸泡、外部审批、生产遥测或缺少凭证的情况下验证的，建议拆为非阻塞、非自动化的后续 issue。
- 检测并附加工作区本地改动：运行 git status --short，按差异大小选择内联（小于 500 行）、推送分支（大于等于 500 行）或文件清单策略，在正文加 Pre-existing Changes 章节，可选清理本地改动。
- 确认后创建：展示标题、正文、建议标签，询问是否加 autonomous 标签，并可继续询问 no-auto-close；用 GitHub MCP 工具或 gh CLI 创建并回报 issue URL。
- 标签：bug、enhancement、autonomous、no-auto-close、documentation、good first issue。autonomous 表示 AI 自动开发、测试、审查并在通过后合并；autonomous 加 no-auto-close 表示完成开发/测试/审查后停在合并前等待人工确认。
- 多 issue 拆分时按依赖顺序创建，依赖章节只列真正阻塞项，用 #N 或 owner/repo#N，无阻塞时写 None。
使用方式：按检测仓库、澄清、起草、确认、创建流程执行；模板、验收标准分类与工作区改动细节见技能内 references 文档。
限制：技能本身针对 GitHub/GitLab issue 工作流；实际创建依赖 gh CLI、GitHub MCP 或 glab 等工具与相应权限。资料未提供收费、价格、效果或平台信息。