From magic-powers
Use when managing defects — writing effective bug reports, applying severity/priority matrix, tracking defect lifecycle, conducting root cause analysis, and measuring defect metrics for process improvement.
npx claudepluginhub kienbui1995/magic-powers --plugin magic-powersThis skill uses the workspace's default tool permissions.
- Writing a bug report that will actually get fixed
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
## [BUG] Checkout fails when applying 100% discount coupon
**Environment:** Production | Chrome 121 | Windows 11
**Severity:** Critical | **Priority:** P1
**Reproducibility:** 100% (reproduced 5 times)
### Steps to Reproduce
1. Add any item to cart (e.g., "Blue Widget" SKU-001)
2. Proceed to checkout
3. Apply coupon code: SAVE100
4. Click "Place Order"
### Expected Result
Order is placed successfully with $0.00 total, confirmation email sent.
### Actual Result
Error: "Payment required" displayed. Order not created.
Network tab shows 400 response from POST /api/orders with body:
`{"error": "amount_must_be_positive", "amount": 0}`
### Evidence
- Screenshot: [attached]
- Network HAR: [attached]
- Error ID: ERR-2026-04-12-001
### Impact
All users with 100% discount coupons cannot complete checkout.
Estimated affected: ~150 active promo codes distributed in last campaign.
### Workaround
None available. Users must contact support for manual processing.
Key elements: Environment, reproducibility, STR (Steps to Reproduce), expected vs actual, evidence, impact, workaround.
Severity = technical impact on system
Priority = business urgency to fix
| High Priority | Low Priority
---------+---------------+--------------
High | P1: Critical | P2: Major
Severity | Fix today | Fix this sprint
---------+---------------+--------------
Low | P2: Major | P3/P4: Minor
Severity | Schedule soon | Fix when possible
Examples:
High severity + High priority (P1):
- Payment processing failure in production
- Security vulnerability with active exploit
- Data loss scenario
High severity + Low priority (P2):
- Crash in rarely-used admin export feature
- Performance degradation in non-peak hours
Low severity + High priority (P2):
- CEO's name misspelled on homepage
- Wrong logo on marketing campaign page
Low severity + Low priority (P4):
- Tooltip text has typo in settings
- Minor alignment issue in footer
New → Assigned → In Progress → Fixed → Verification → Closed
↓ ↓
Reopened ←──── Failed Verification
States:
New: Bug reported, not yet triaged
Assigned: Assigned to developer for investigation
In Progress: Developer actively working on fix
Fixed: Developer marked as fixed, needs QA verification
Verification: QA retesting the fix
Closed: Fix verified by QA, defect resolved
Reopened: Fix verification failed, back to developer
Won't Fix: Acknowledged but decision made not to fix
Duplicate: Same defect already reported
Cannot Reproduce: Cannot replicate with given information
Production bug: Users cannot log in after midnight UTC
Why 1: Authentication service returns 401 after midnight
Why 2: JWT tokens with 24h expiry issued at midnight all expire simultaneously
Why 3: Token expiry was set to 24h from issuance time, not rolling window
Why 4: Requirement said "sessions expire after 24 hours" — implemented literally
Why 5: No specification for how to handle mass simultaneous expiry
Root cause: Ambiguous requirement + no testing of midnight boundary condition
Actions:
Immediate: Deploy fix to use rolling token refresh (30 min inactivity)
Short-term: Add test case for high-concurrency token expiry scenario
Long-term: Add requirement review checklist for time-based features
Weekly triage meeting agenda (30 minutes):
1. Review new defects since last triage (10 min)
- Confirm severity/priority
- Assign owner
- Set target sprint
2. Review in-progress defects (10 min)
- Any blockers?
- On track for target sprint?
3. Review aging defects (10 min)
- P1/P2 defects >5 days old: escalate
- P3/P4 defects >30 days: accept/defer/close
Triage criteria questions:
- Can users work around it? (reduces priority)
- How many users affected? (increases priority)
- Is there a security implication? (always high priority)
- Is it in a critical path? (increases priority)
qc-metrics — defect data feeds quality metricsqc-test-design — root cause analysis drives new test cases to prevent recurrencetest-strategy — defect density informs risk-based testing focus