mcpField
B
bug

bug

github.com/shipshitdev测试与质量3852 次安装2 天前更新
代码仓库

关于 bug

bug 将故障描述或错误整理为 GitHub 问题草稿，并结合仓库信息；缺失内容会标为未知，不会凭空补写。它用于提交缺陷，创建前会展示报告并要求确认。

主要功能

  1. 01生成结构化缺陷报告
  2. 02读取仓库与问题类型信息
  3. 03将缺失内容标为未知
  4. 04提交前要求确认
  5. 05支持标签、指派人与里程碑

适用场景

  1. 01根据简略描述提交缺陷
  2. 02将错误信息整理为报告
  3. 03仅起草报告而不创建问题

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/shipshitdev/skills --skill bug

安装后在 Claude Code 中输入/bug确认已加载。

附带文件plugin.json

详细介绍

Bug

将对故障的描述转化为 GitHub 的 Bug 类型 Issue。根据用户提供的信息（以及仓库上下文）起草报告，供用户审核；只有获得确认后才会创建 Issue——仓库支持 Issue 类型时将其设为 Bug，否则添加 bug 标签。

未经确认绝不创建 Issue，也绝不编造用户未提供的复现步骤或事实；未知信息会明确标注。

约定

输入：

  • Bug 描述（自由文本、错误信息／堆栈跟踪，或标题加详细信息）
  • 目标仓库（从当前目录的远程仓库自动检测）
  • 可选：用户指定的标签、受理人、里程碑或严重程度

输出：

  • 创建前展示的结构化 Bug 报告（标题 + 正文）
  • Issue 将设为 Bug 类型还是添加 bug 标签，以及原因
  • 创建后的 Issue 编号和 URL

创建／修改：

  • 通过 gh 创建一个 Bug 类型的 GitHub Issue（或添加 bug 标签）
  • 仅应用用户要求的标签／受理人／里程碑
  • 如果回退时使用 bug 标签且该标签尚不存在，则创建该标签
  • 不编辑代码、不关闭其他 Issue，也不修改仓库设置

外部副作用：

  • 从 GitHub 读取仓库、标签和 Issue 类型的元数据
  • 创建 GitHub Issue（所有有权访问该仓库的人都能看到）

需要确认：

  • 创建 Issue 前——始终先打印起草的标题 + 正文，并要求用户明确答复“是”
  • 回退路径中，如果 bug 标签尚不存在，则创建该标签前需要确认

委派给：

  • 当 Bug 是用户希望修复而非提交的失败 CI 检查时，交给 github-fix-ci
  • 当用户希望在提交前查明根本原因时，交给 debug（如果修复尝试已经失败，它会自行升级到四阶段循环）

适用场景

  • 根据粗略描述或错误信息撰写清晰的 Bug 报告
  • 在会话中途发现 Bug 时，无需离开终端即可记录
  • 用户说“提交一个 Bug”“提交这个问题”“创建 Bug Issue”或运行 /bug 时

不要使用此技能来修复 Bug、提交功能请求或任务（它们属于其他 Issue 类型），也不要用于整理现有 Issue。

阶段 1：检测仓库和类型

gh auth status -h github.com
gh repo view --json nameWithOwner,hasIssuesEnabled --jq '{repo:.nameWithOwner, issues:.hasIssuesEnabled}'

如果已禁用 Issue，则停止。检测仓库所有者是否定义了 Issue 类型，以及是否存在 Bug 类型：

gh issue create --help | grep -q -- '--type' && echo "type-flag: supported"
gh api "repos/{owner}/{repo}" --jq '.owner.type' 2>/dev/null

确定处理路径：

  • Bug Issue 类型——如果组织／仓库提供 Bug 类型，则优先使用。使用 --type Bug。
  • bug 标签——没有 Issue 类型时的回退方案。检查是否存在该标签，并仅在需要时创建：
gh label list --search bug --json name --jq '.[].name'

阶段 2：起草 Bug 报告

根据用户提供的信息组织报告。保持内容真实——绝不编造步骤、版本或行为。将未知信息标记为 _not provided_。

标题： 简短、具体地概括症状（不要写“bug”或“坏了”）。

正文（省略确实不适用的部分）：

## Summary
<one or two sentences: what is broken>

## Steps to Reproduce
1. …
2. …

## Expected
<what should happen>

## Actual
<what happens instead — include the error/stack trace verbatim if provided>

## Environment
<app/service, version or commit, OS/browser, anything relevant — or _not provided_>

## Notes
<links, related issues, suspected area — only if the user gave them>

如果用户粘贴了堆栈跟踪或错误信息，请在 Actual 下用围栏代码块逐字引用。只有在缺少该信息会导致报告无法使用时，才提出一个简洁的后续问题（例如，完全没有症状描述）；否则，根据现有信息起草，并标注缺失项。

阶段 3：预览并确认

打印完整的 Issue 草稿——标题、正文、类型／标签决定，以及要应用的任何标签／受理人／里程碑——然后停止并等待用户明确答复“是”。如果用户要求只读或试运行，到此结束，不提交任何内容。

阶段 4：创建 Issue

只有获得确认后，才将正文写入当前仓库的 .tmp/（以保留格式），并创建 Issue。

首选——Bug Issue 类型：

REPO_TMP="$(git rev-parse --show-toplevel)/.tmp"
mkdir -p "$REPO_TMP"
gh issue create --title "<title>" --body-file "$REPO_TMP/bug_body.md" --type Bug

回退——bug 标签（仅在标签缺失且用户同意后才创建该标签）：

gh label create bug --color d73a4a --description "Something isn't working" 2>/dev/null || true
gh issue create --title "<title>" --body-file "$REPO_TMP/bug_body.md" --label bug

只有对用户指定的值，才添加 --assignee、--label、--milestone 或 --project。如果 --type Bug 因类型不存在而失败，则回退到标签路径，并说明原因，不要让整个流程失败。

模式

  • bug / bug <description> — 阶段 1-4。起草、确认并提交问题。（默认。）
  • bug draft — 阶段 1-3。仅起草并打印报告；不创建任何内容。

如果用户指定了标签、受理人、里程碑或严重程度，请按其要求处理。如果 他们要提交的是功能或任务而非错误，请说明此技能用于提交错误，并指引 他们选择正确的问题类型。

最终状态

报告：

  • 仓库，以及问题的类型是否设为 Bug 或是否添加了 bug 标签
  • 创建的问题编号和 URL
  • 应用的任何标签、受理人或里程碑
  • 下一步该做什么——例如，使用 debug 查明根本原因，或使用 github-fix-ci 修复未通过的检查

评论

支持 Markdown