From product-ops
Scaffold a RIMGEN-validated bug report with reproduction steps, environment context, severity, and priority. Outputs named warnings for any missing or incomplete RIMGEN sections.
How this skill is triggered — by the user, by Claude, or both
Slash command
/product-ops:write-bugThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Scaffold a complete, RIMGEN-validated bug report ready to file as a GitHub issue or Jira ticket.
Scaffold a complete, RIMGEN-validated bug report ready to file as a GitHub issue or Jira ticket.
$ARGUMENTS = description of the bug — what broke, what you were doing, what you expected.
If $ARGUMENTS is empty or contains no actionable description, prompt the author for the minimum information needed to begin scaffolding. Present these questions in a single consolidated prompt:
Do not proceed to draft until the author has provided at least: a failure description, at least one reproduction step, and both expected and actual behaviors.
Before drafting, evaluate whether the input provides enough information across all six RIMGEN dimensions:
| Dimension | Sufficient when | Prompt if underspecified |
|---|---|---|
| R — Reproducible | Steps are present and specific enough to follow independently | "What are the exact steps to reproduce this?" |
| I — Isolated | A single, specific failure is described — not a cluster of related issues | "Is this one specific failure, or are there multiple separate issues to report?" |
| M — Minimal | The reproduction path is not bloated with unnecessary setup | No prompt needed — trim during drafting |
| G — Generalizable | Scope of impact is stated (all users? specific role? specific config?) | "Who else sees this — all users, or only in specific configurations?" |
| E — Expected vs. Actual | Both expected and actual behaviors are present and distinct | "What did you expect to happen?" and/or "What actually happened?" |
| N — Necessary Context | At least one environment detail is present (version, OS, or configuration) | "What version and environment are you running?" |
Outcome paths:
Title: Concise, describes the failure — not the fix. Prefer the format: [Component] verb + symptom.
Do not use "As a / I want / So that" framing. A bug title states what is broken.
Severity — the technical impact of the bug:
| Level | Definition |
|---|---|
| Critical | Data loss, security vulnerability, system crash, or complete feature failure with no workaround |
| High | Major functionality broken for most users; workaround is awkward or unavailable |
| Medium | Functionality impaired; a reasonable workaround exists |
| Low | Minor issue, cosmetic defect, or edge-case behavior with easy mitigation |
Priority — the urgency of the fix:
| Level | Definition |
|---|---|
| P0 | Fix immediately; ship a hotfix regardless of sprint cycle |
| P1 | Fix in the current sprint; cannot close sprint without resolution |
| P2 | Fix in the next sprint |
| P3 | Fix when bandwidth allows; no time pressure |
If severity or priority cannot be determined from context, emit a warning using the format defined in Step 4 and leave a [AUTHOR: specify] placeholder.
Reproduction steps — critical formatting rules:
After drafting, validate each dimension. For any dimension that is absent, blank, contains only a placeholder (e.g., "TBD", "N/A" with no further detail), or fails its criterion, emit a named warning before the report output.
This warning format applies to both RIMGEN dimensional failures and the severity/priority placeholder case from Step 3:
⚠ RIMGEN Warning — [Dimension Name]: [One sentence describing what is missing or insufficient and what the author should add.]
Validation criteria:
Do not block output for warnings. Present all warnings first, then present the complete report.
Construct the YAML frontmatter metadata block:
type: always bugtitle: the failure-description title from Step 3severity: critical, high, medium, or lowpriority: p0, p1, p2, or p3status: always draftlabels: prefix with area: for domain labels; always include type:bugenvironment: key details extracted from the Necessary Context sectionreproduction_steps: the same steps as in the body, as a structured listexpected_behavior: the expected behavior textactual_behavior: the actual behavior textBefore presenting the output, verify:
reproduction_steps matches the numbered steps in the Reproduction Steps section of the bodyPresent any warnings first, then the report in two separate sections under distinct headings.
Section 1 — Structured Metadata (for downstream tooling):
---
type: bug
title: "Payment form crashes on submit when amount field is empty"
severity: high
priority: p1
status: draft
labels:
- "type:bug"
- "area:payments"
environment:
version: "2.4.1"
os: "macOS 14.3"
browser: "Chrome 122"
reproduction_steps:
- "Navigate to the payment form at /checkout"
- "Leave the amount field empty"
- "Click the Submit button"
expected_behavior: "The form displays a validation error indicating the amount field is required."
actual_behavior: "The page crashes with an unhandled exception and the user loses their cart."
---
Section 2 — Bug Report Body (human-readable content for collaborators):
## Summary
[One-sentence description of the failure]
**Severity:** High — Major functionality broken; workaround unavailable
**Priority:** P1 — Fix in the current sprint
## Reproduction Steps
1. Navigate to the payment form at /checkout
2. Leave the amount field empty
3. Click the Submit button
## Expected Behavior
The form displays a validation error indicating the amount field is required.
## Actual Behavior
The page crashes with an unhandled exception and the user loses their cart.
## Scope of Impact
All users who attempt to submit the payment form without entering an amount.
Reproducible in Chrome 122, Firefox 123, and Safari 17.
## Environment & Context
- **Version**: 2.4.1
- **OS**: macOS 14.3
- **Browser**: Chrome 122
## Notes
[Additional context, links to logs, screenshots, related issues]
npx claudepluginhub cpliakas/claude-code-digital-coworkers --plugin product-opsDrafts, evaluates, enriches, and normalizes QA bug reports to RAVN standards. Supports multiple modes for writing new reports, scoring existing ones, filling in missing fields, or converting legacy formats.
Reproduces bug reports, assesses severity and priority, captures environment context, and assigns them before diagnosis begins.
Transforms error logs, screenshots, voice notes, and rough bug reports into structured GitHub issues with reproduction steps, impact, and evidence.