Skills Agentes

Bug Triage

Lee los bugs abiertos en production/qa/bugs/, reevalúa prioridad frente a severidad, los asigna a sprints, detecta tendencias sistémicas y genera un informe de triage.

Solicitareadglobgrepwriteedit
Estrellas
24.4k

en todo el repo

Actividad
43

0–100, la ruta de este skill

Actualizado
hace 3 meses

último commit aquí

Commits
0

últimos 90 días

Contexto
2k tok

58 tok en reposo

Paquete
1 archivo

8 KB

Instalar

Funciona con cualquier agente que lea SKILL.md

npx -y skills add Donchitos/Claude-Code-Game-Studios --skill bug-triage --agent claude-code

Se instala solo en este repositorio.

Este skill writes to your files.

Qué hace

  • Lee todos los bugs abiertos en production/qa/bugs/ y evalúa severidad (S1-S4) frente a prioridad (P1-P4)
  • Asigna bugs P1/P2 a sprints según capacidad disponible o marca overflow
  • Detecta patrones sistémicos: sistemas problemáticos, historias con regresiones, bugs sin asignar
  • Genera un informe de triage en production/qa/bug-triage-[date].md tras pedir aprobación

Úsalo cuando

  • Al inicio de un sprint, para asignar bugs abiertos al nuevo sprint o al backlog
  • Después de que /team-qa termine y se hayan reportado nuevos bugs
  • Cuando el número de bugs abiertos supera los 10

No lo uses cuando

  • No hay archivos de bugs en production/qa/bugs/ ni alternativas: no hay nada que triar

Qué lo activa

Di cualquiera de estas frases y el agente debería cargar este skill.

  • /bug-triage sprint
  • /bug-triage full
  • /bug-triage trend
  • Necesito priorizar los bugs abiertos antes del inicio del sprint

SKILL.md

En inglés

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)

Severity Definition
S1 — Critical Game crashes, data loss, or complete feature failure. Cannot proceed past this point.
S2 — High Major feature broken but game is still playable. Significant wrong behaviour.
S3 — Medium Feature degraded but a workaround exists. Minor wrong behaviour.
S4 — Low Visual glitch, cosmetic issue, typo. No gameplay impact.

Priority (urgency of the fix)

Priority Definition
P1 — Fix this sprint Blocks QA, blocks release, or is regression from last sprint
P2 — Fix soon Should be resolved before the next major milestone
P3 — Backlog Would be good to fix, but no active blocking impact
P4 — Won't fix / Deferred Accepted 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

Reproducido de Donchitos/Claude-Code-Game-Studios bajo licencia MIT. Leer esta página en markdown.

Archivos

1 archivo en el paquete. Solo se lee SKILL.md al activarse — las referencias se cargan si el skill decide que las necesita.

Antes de instalar

Requiere bugs registrados en production/qa/bugs/ (o bugs.md / qa-plan-*.md) y opcionalmente un plan de sprint en production/sprints/.

Detalles

Creador
Donchitos
Categoría
Testing y QA
Licencia
MIT
Recursos incluidos
Solo SKILL.md
Código fuente
Ver SKILL.md

Etiquetas

Más de Donchitos/Claude-Code-Game-Studios

Este repo incluye 73 skills. Si instalas uno, normalmente ya tienes los demás.

Adopt

24.4k

Onboarding brownfield: audita el cumplimiento de formato de los artefactos existentes, clasifica los vacíos por impacto y genera un plan de migración numerado.

Costo de contexto al activarse
4.5k tok
Tamaño del paquete
1 archivo
Última actualización
hace 3 meses
herramientas desarrollo

Crea un Registro de Decisión de Arquitectura (ADR) que documenta una decisión técnica importante, su contexto, alternativas consideradas y consecuencias.

Costo de contexto al activarse
4.8k tok
Tamaño del paquete
1 archivo
Última actualización
hace 3 meses
documentos

Valida que la arquitectura del proyecto cubra por completo los GDD: cruza requisitos con ADR, detecta conflictos entre decisiones y compatibilidad de motor, y da un veredicto PASS/CONCERNS/FAIL.

Costo de contexto al activarse
6.7k tok
Tamaño del paquete
1 archivo
Última actualización
hace 3 meses
herramientas desarrollo

Autoría guiada, sección por sección, del Art Bible. Crea la especificación de identidad visual que condiciona toda la producción de assets. Se ejecuta tras aprobar /brainstorm y antes de /map-systems o de redactar cualquier GDD.

Costo de contexto al activarse
3.7k tok
Tamaño del paquete
1 archivo
Última actualización
hace 3 meses
documentos

Audita los assets del juego según convenciones de nombres, presupuestos de tamaño, formatos estándar y requisitos de pipeline. Identifica assets huérfanos, referencias faltantes e infracciones de estándares.

Costo de contexto al activarse
697 tok
Tamaño del paquete
1 archivo
Última actualización
hace 3 meses
testing qa

Genera especificaciones visuales por asset y prompts de generación IA a partir de GDDs, docs de nivel o perfiles de personaje. Produce archivos de spec y actualiza el manifiesto maestro.

Costo de contexto al activarse
4.1k tok
Tamaño del paquete
1 archivo
Última actualización
hace 3 meses
documentos

Skills relacionados

Audita los assets del juego según convenciones de nombres, presupuestos de tamaño, formatos estándar y requisitos de pipeline. Identifica assets huérfanos, referencias faltantes e infracciones de estándares.

Costo de contexto al activarse
697 tok
Tamaño del paquete
1 archivo
Última actualización
hace 3 meses
testing qa

Crea un informe de bug estructurado a partir de una descripción o analiza código para identificar bugs potenciales, con pasos de reproducción, severidad y contexto completos.

Costo de contexto al activarse
1.5k tok
Tamaño del paquete
1 archivo
Última actualización
hace 3 meses
testing qa

Realiza una revisión arquitectónica y de calidad de un archivo o conjunto de archivos, evaluando estándares, principios SOLID, testabilidad y rendimiento.

Costo de contexto al activarse
1.9k tok
Tamaño del paquete
1 archivo
Última actualización
hace 3 meses
Permisos
testing qa