Token导航 LogoToken导航TokenDH.com
研究检索只读github未标认证来源可访问许可证需确认审计通过

bug-triage错误分类

Agent Skill

bug-triage 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

494

周安装

21

GitHub Stars

16,607

下载量

173
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:bug-triage(错误分类)
来源仓库:https://github.com/donchitos/claude-code-game-studios
仓库路径:skills/bug-triage
安装命令:
npx skills add https://github.com/donchitos/claude-code-game-studios --skill bug-triage
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/donchitos/claude-code-game-studios --skill bug-triage

简介

该技能处理开放缺陷清单并按优先级分配至迭代周期。

  • 适用于敏捷团队启动新迭代时的缺陷管理场景。
  • 区分严重程度与优先级,识别系统性趋势。
  • 输出带分配建议和风险说明的行动列表。适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。
  • bug-triage 属于研究检索类 Skill,可作为该场景下的辅助能力补充。

SKILL.md

Bug Triage

This skill processes the open bug backlog into a prioritised, sprint-assigned action list. It distinguishes between severity (how bad is the impact?) and priority (how urgently must we fix it?), detects systemic trends, and ensures no critical bug is lost between sprints.

Output: production/qa/bug-triage-[date].md

When to run:

  • Sprint start — assign open bugs to the new sprint or backlog
  • After /team-qa completes and new bugs have been filed
  • When the bug count crosses 10+ open items

1. Parse Arguments

Modes:

  • /bug-triage sprint — triage against the current sprint; assign fixable bugs to the sprint backlog; defer the rest
  • /bug-triage full — full triage of all bugs regardless of sprint scope
  • /bug-triage trend — trend analysis only (no assignment); read-only report
  • No argument — run sprint mode if a current sprint exists, else full mode

2. Load Bug Backlog

Step 2a — Discover bug files

Glob for bug reports in priority order:

  1. production/qa/bugs/*.md — individual bug report files (preferred format)
  2. production/qa/bugs.md — single consolidated bug log (fallback)
  3. Any production/qa/qa-plan-*.md "Bugs Found" table (last resort)

If no bug files found:

"No bug files found in production/qa/bugs/. If bugs are tracked in a different location, adjust the glob pattern. If no bugs exist yet, there is nothing to triage."

Stop and report. Do not proceed if no bugs exist.

Step 2b — Load sprint context

Read the most recently modified file in production/sprints/ to understand:

  • Current sprint number / name
  • Stories in scope (for assignment target)
  • Sprint capacity constraints (if noted)

If no sprint file exists: note "No sprint plan found — assigning to backlog only."

Step 2c — Load severity reference

Read .claude/docs/coding-standards.md for severity/priority definitions if they exist. If they do not exist, use the standard definitions in Step 3.


3. Classify Each Bug

For each bug, extract or infer:

Severity (impact of the bug)

SeverityDefinition
S1 — CriticalGame crashes, data loss, or complete feature failure. Cannot proceed past this point.
S2 — HighMajor feature broken but game is still playable. Significant wrong behaviour.
S3 — MediumFeature degraded but a workaround exists. Minor wrong behaviour.
S4 — LowVisual glitch, cosmetic issue, typo. No gameplay impact.

Priority (urgency of the fix)

PriorityDefinition
P1 — Fix this sprintBlocks QA, blocks release, or is regression from last sprint
P2 — Fix soonShould be resolved before the next major milestone
P3 — BacklogWould be good to fix, but no active blocking impact
P4 — Won't fix / DeferredAccepted risk or out of scope for current product scope

Assignment

For each P1/P2 bug in sprint mode:

  • Identify which story or epic the fix belongs to
  • Check whether the current sprint has remaining capacity
  • If capacity exists: assign to sprint (Sprint: [current])
  • If capacity is full: flag as Priority overflow — consider pulling from sprint

For full mode: assign all P1 to current sprint, P2 to next sprint estimate, P3+ to backlog.

Deviation check

Flag bugs that suggest systematic problems:

  • 3+ bugs from the same system in the same sprint → "Potential design or implementation quality issue in [system]"
  • 2+ S1/S2 bugs in the same story → "Story may need to be reopened and re-reviewed before shipping"
  • Bug filed against a story marked Complete → "Regression in completed story — story should be re-opened in sprint tracking"

4. Trend Analysis

After classifying all bugs, generate trend metrics:

Volume trends

  • Total open bugs: [N]
  • Opened this sprint: [N]
  • Closed this sprint: [N]
  • Net change: [+N / -N]

System hot spots

  • Which system has the most open bugs?
  • Which system has the highest S1/S2 ratio?

Age analysis

  • How many bugs are older than 2 sprints?
  • Are any S1/S2 bugs un-assigned (sprint = none)?

Regression indicator

  • Any bugs filed against previously-completed stories?
  • Count: [N] regression bugs (story reopened implied)

5. Generate Triage Report

# Bug Triage Report

> **Date**: [date]
> **Mode**: [sprint | full | trend]
> **Generated by**: /bug-triage
> **Open bugs processed**: [N]
> **Sprint in scope**: [sprint name, or "N/A"]

---

## Triage Summary

| Priority | Count | Notes |
|----------|-------|-------|
| P1 — Fix this sprint | [N] | [N] assigned to sprint, [N] overflow |
| P2 — Fix soon | [N] | Scheduled for next sprint |
| P3 — Backlog | [N] | Deferred |
| P4 — Won't fix | [N] | Accepted risk |

**Critical (S1/S2) unfixed count**: [N]

---

## P1 Bugs — Fix This Sprint

| ID | System | Severity | Summary | Assigned to | Story |
|----|--------|----------|---------|-------------|-------|
| BUG-NNN | [system] | S[1-4] | [one-line description] | [sprint] | [story path] |

---

## P2 Bugs — Fix Soon

| ID | System | Severity | Summary | Target Sprint |
|----|--------|----------|---------|---------------|
| BUG-NNN | [system] | S[1-4] | [one-line description] | Sprint [N+1] |

---

## P3/P4 Bugs — Backlog / Won't Fix

| ID | System | Severity | Summary | Disposition |
|----|--------|----------|---------|-------------|
| BUG-NNN | [system] | S4 | [one-line description] | Backlog |

---

## Systemic Issues Flagged

[List any patterns from Step 3 deviation check, or "None identified."]

---

## Trend Analysis

**Volume**: [N] open / [+N] net change this sprint
**Hot spot**: [system with most bugs]
**Regressions**: [N] bugs against completed stories
**Aged bugs (>2 sprints old)**: [N]

[If N aged S1/S2 bugs > 0:]
> ⚠️ [N] high-severity bugs have been open for more than 2 sprints without
> assignment. These represent accepted risk that should be explicitly reviewed.

---

## Recommended Actions

1. [Most urgent action — usually "fix P1 bugs before QA hand-off"]
2. [Second action — usually "investigate [hot spot system] quality"]
3. [Third action — optional improvement]

6. Write and Gate

Present the report in conversation, then ask:

"May I write this triage report to production/qa/bug-triage-[date].md?"

Write only after approval.

After writing:

  • If any S1 bugs are unassigned: "S1 bugs must be assigned before the sprint can be considered healthy. Run /sprint-status to see current capacity."
  • If regression bugs exist: "Regressions found — consider re-opening the affected stories in sprint tracking and running /smoke-check to re-gate."
  • If no P1 bugs exist: "No P1 bugs — build is in good shape for QA hand-off." Verdict: COMPLETE — triage report written.

If user declined write: Verdict: BLOCKED — user declined write.


Collaborative Protocol

  • Never close or mark bugs Won't Fix without user approval — surface them as P4 candidates and ask: "Are these acceptable as Won't Fix?"
  • Never auto-assign to a sprint at capacity — flag overflow and let the sprint owner decide what to pull
  • Severity is objective; priority is a team decision — present severity classifications as recommendations, not mandates
  • Trend data is informational — do not block work on trend findings alone; surface them as observations

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

35.37%
按下载量换算61

Claude

28.72%
按下载量换算50

Cursor

19.27%
按下载量换算33

Gemini CLI

8.82%
按下载量换算15

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

只读

该 Skill 主要提供规则、说明或参考内容,本身偏只读;真正读写文件、联网或执行命令仍取决于宿主 Agent 的任务。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills