Menu
在 GitHub/GitLab/Gitea 上创建格式规范的 Issue。优先使用仓库 Issue 模板，支持 Bug 报告、功能请求等类型，自动生成结构化描述。使用场景：用户要求提交 issue、报告 bug、提出功能需求
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
创建符合规范的 git 提交消息，并在提交前 review 将提交的变更。优先遵循项目现有提交规范，支持 Conventional Commits 格式。使用场景：用户要求创建提交、编写提交消息、提交前检查变更
使用 ddgr 在终端搜索 DuckDuckGo，返回结构化结果。支持站点限定、时间过滤、区域搜索。使用场景：用户要求搜索信息、查找文档、搜索特定网站内容
自动化 GitHub/GitLab/Gitea 发布流程。使用场景：发布新版本、创建版本标签、更新 CHANGELOG。自动分析 Git 提交、更新 CHANGELOG.md、确定语义化版本号、创建 Git 标签、推送到远程并创建 Release
将指定目录下的 skills 通过符号链接安装到目标目录。支持单 skill 目录和多 skill 父目录，自动校验 SKILL.md 存在性。使用场景：安装技能、链接 skills 到指定目录
自动化处理 GitHub/GitLab/Gitea Issue 的完整工作流：获取 issue → 分支管理（含 worktree）→ 代码实现 → 提交 → 创建 PR/MR。使用场景：用户要求处理 issue、解决 bug、实现功能、贴了 issue 链接
Tauri 框架最佳实践指南。使用场景：Tauri 应用开发、代码审查、架构设计
| name | git-issue-report |
| description | 在 GitHub/GitLab/Gitea 上创建格式规范的 Issue。优先使用仓库 Issue 模板，支持 Bug 报告、功能请求等类型，自动生成结构化描述。使用场景：用户要求提交 issue、报告 bug、提出功能需求 |
在 GitHub/GitLab/Gitea 上创建格式规范的 Issue，优先使用仓库已有的 Issue 模板，否则按内置类型生成结构化描述。
默认行为：用户直接调用本技能且未指定类型时，先检测仓库模板，有则展示模板列表，无则展示内置类型菜单。
如果对话中已通过任意 git 技能确定过平台信息（平台 + owner/repo），直接复用，跳过本步骤。
首次检测时执行：
git remote get-url origin
解析 URL 判断平台：
github.com 域名 → 提取 owner/repogitlab.com 或自托管 GitLab 域名 → 提取 owner/repo<域名>/api/v1/version 检测是否为 Gitea 实例
owner/repo检测完成后记住平台信息，供后续 git 技能复用。
如果对话中已通过本技能检测过仓库 Issue 模板，直接复用检测结果，跳过本步骤。
首次检测时，检查仓库中是否存在 Issue 模板：
| 平台 | 路径 | 格式 |
|---|---|---|
| GitHub | .github/ISSUE_TEMPLATE/*.yml / *.yaml | YAML 表单模板 |
| GitHub | .github/ISSUE_TEMPLATE/*.md | Markdown 模板 |
| GitHub | .github/ISSUE_TEMPLATE.md（单文件） | Markdown 模板 |
| GitLab | .gitlab/issue_templates/*.md | Markdown 模板 |
| Gitea | .gitea/issue_template/*.md | Markdown 模板 |
ls .github/ISSUE_TEMPLATE/*.yml .github/ISSUE_TEMPLATE/*.yaml .github/ISSUE_TEMPLATE/*.md 2>/dev/null
ls .github/ISSUE_TEMPLATE.md 2>/dev/null
ls .gitlab/issue_templates/*.md 2>/dev/null
ls .gitea/issue_template/*.md 2>/dev/null
解析模板文件，展示列表供用户选择：
📂 检测到仓库 Issue 模板：
1. 🐛 Bug Report — 报告一个 bug
2. ✨ Feature Request — 提出新功能
3. 📝 自定义（不使用模板）
请选择 (1/2/3):
选择模板后，跳转到步骤 3。
进入步骤 2。
如果用户已明确类型（如"报告一个 bug"），直接使用。否则提供选择菜单：
请选择 Issue 类型：
1. 🐛 Bug 报告
2. ✨ 功能请求
3. 🔧 改进建议
4. 📝 其他
请选择 (1/2/3/4):
Bug 报告 — 必填：标题、问题描述、复现步骤、期望行为、实际行为 | 可选：环境信息、截图/日志
## 问题描述
[简要描述问题]
## 复现步骤
1. [步骤 1]
2. [步骤 2]
## 期望行为
[应该发生什么]
## 实际行为
[实际发生了什么]
## 环境信息
- OS: [操作系统]
- 版本: [软件/浏览器版本]
功能请求 — 必填：标题、功能描述、使用场景 | 可选：期望方案、替代方案
## 功能描述
[描述想要的功能]
## 使用场景
[为什么需要这个功能，解决什么问题]
## 期望方案
[理想的实现方式]
## 替代方案
[是否考虑过其他方式]
改进建议 — 必填：标题、描述 | 可选：动机
## 描述
[详细说明改进内容]
## 动机
[为什么需要这个改进]
其他 — 必填：标题、描述
## 描述
[详细说明]
body 逐项收集，Markdown 按标题分段填写）如果用户已在对话中提供了部分信息，自动匹配到对应字段，仅询问缺失的必填项。
适用于所有路径（仓库模板和内置类型）：
生成 Issue 内容前，先在仓库中搜索是否已有相似的 Issue，避免重复创建。
使用平台 CLI 搜索（不限状态，open 和 closed 都看）：
# GitHub
gh issue list --state all --search "<关键词>"
# GitLab
glab issue list --all --search "<关键词>"
# Gitea
tea issues list --state all --keyword "<关键词>"
搜索关键词：从用户描述中提取 2-3 个核心关键词组合搜索。
结果处理：
🔍 搜索到 N 个可能相似的 Issue，较多，是否逐一查看确认？
1. 全部查看（逐一判断相似度）
2. 只看前 5 个
3. 跳过，直接创建新 Issue
确认真正相似时才提醒用户：
🔍 发现相似 Issue：
#45 登录页面在 Safari 下布局错乱（open）
摘要：...（Issue 的关键内容）
确认重复，是否：
1. 跳转到该 Issue 补充信息
2. 继续创建新 Issue
按仓库模板或内置模板格式生成 Issue 内容，直接展示最终将提交的标题和正文供用户确认。用户可要求修改，修改后重新展示。
必须在用户明确确认预览内容后，才执行创建命令。 如果用户要求修改，返回步骤 5 修改后重新预览，再次确认。
使用平台 CLI 工具创建 Issue。
可选参数（仅在用户明确要求时使用）：
--label：添加标签--assignee：指派给用户创建成功后展示：
✅ Issue 已创建
#128 登录页面在 Safari 中无法正常显示
🔗 https://github.com/owner/repo/issues/128
认证失败时：提供格式化的 Issue 内容（Markdown），供用户在 Web UI 手动创建。
# GitHub
gh issue create --title "..." --body "..."
# GitLab
glab issue create --title "..." --description "..."
# Gitea
tea issues create --title "..." --description "..."
| 场景 | 处理 |
|---|---|
| CLI 未安装 | 提示安装 gh/glab/tea |
| 认证失败 | 提示重新登录，提供 Markdown 内容供手动创建 |
| 无远程仓库 | 中止并提示配置 |
| 模板解析失败 | 提示模板格式异常，回退到内置类型流程 |
| 创建失败 | 展示错误信息，提供 Markdown 内容供手动创建 |
帮我提一个 bug我想提一个功能请求：支持暗色模式这个函数有问题，帮我创建一个 issue报告一个 bug：用户注册时邮箱验证失败