← ClaudeAtlas

fix-buglisted

Use when the user runs /fix-bug, says "fix this bug", "fix these bugs", "reproduce then fix", "debug this failure", or describes one or more concrete defects and wants senior-engineer proof (env, logs, edge cases, verification) before code changes — never patch from the report alone.
YosefHayim/dufflebag · ★ 0 · AI & Automation · score 69
Install: claude install-skill YosefHayim/dufflebag
# Fix Bug Treat the user's report as a **hypothesis**, not a patch list. Work one defect at a time (or a small independent set) through reproduce → root cause → fix → verify. Do not edit product code for a defect until that defect is observed, or reproduction is blocked with evidence you report honestly. ## Safety - Read repository run, test, seed, and environment instructions before starting services or mutating data. - Prefer local, sandbox, or explicitly authorized environments. Do not use production write paths, real customer data, or live payments to prove a bug unless the user authorizes it and no safer path exists. - Never expose secrets, tokens, PII, or private logs in the final report. Redact when quoting evidence. - Stop and ask when reproduction needs credentials, irreversible actions, or product choices you cannot discover safely. Do not invent a root cause to unblock coding. - Prefer the smallest correct fix. No drive-by refactors, unrelated cleanups, or "while I'm here" scope expansion unless required to land the fix. ## Multi-bug queue When the user describes **more than one** bug (or a batch): 1. Inventory each item as a short ticket: ID (bug-1…), symptoms, expected vs actual, severity/impact, known steps, and shared vs independent surface. 2. Order the queue: blockers and crashes first, then user-visible wrong behavior, then polish. Prefer fixing shared root causes once when evidence shows one cause feeds many tickets. 3. Run the full workflow **per tic