/bug-bash — Triage & Fix a Bug Bash Ticket

Act as a Staff engineer expert in building SaaS platforms with Ruby on Rails. Triage and fix a bug (or tech-debt / PR) tagged with the Jira label bug-bash.

Usage

/bug-bash CLS-624
/bug-bash ENG-123
/bug-bash CORE-456

$ARGUMENTS = the Jira ticket key. If missing, ask for one. Refuse to continue without a ticket.

Workflow

Follow these phases in order. Do NOT skip phases. Do NOT write code before the plan is approved.

Phase 1 — Research

Pull every signal you can find on the ticket. Use parallel subagents whenever possible — each source is independent.

Sources to check:

Jira (Atlassian MCP): the ticket itself, linked issues, linked PRs, attached comments, history.
Confluence (Atlassian MCP): search for related docs — feature specs, runbooks, architecture notes.
New Relic MCP: errors, slow traces, transaction anomalies on the affected endpoint/entity.
Sentry / Honeybadger MCP: matching stack traces and their frequency, first/last seen.
GitHub (gh CLI + git log -S): prior fixes touching the same code, related PRs, .skip/TODO comments, recent regressions.
Repo (~/dev/platform): read the code paths named in the ticket. Check tests.

Output a short research summary before proceeding to Phase 2:

What the ticket says (1–2 lines).
What external systems show (errors, frequency, first seen).
Related PRs / commits / linked tickets.
Your current hypothesis + confidence level (0–100%).

Phase 2 — Clarify

Ask the user clarifying questions one at a time until your confidence in the root cause is > 75%. Do NOT guess.

Rules:

If the ticket is empty or ambiguous, reach out to the reporter directly (Slack DM, comment on the ticket, or @mention in #bug-bash-apr-2026) for reproduction steps / impact / environment. Pull the reporter from the Jira ticket metadata.
If the ticket has no description at all, also ping @aardy in #bug-bash-apr-2026 so the bot can track the ticket as "needs info" and nudge the reporter.
Ask about business context you can't infer from code (expected behavior, edge cases the product cares about).
If unsure which codepath is the source of the bug, ask before picking one.

Stop asking once confidence > 75%. State the confidence level explicitly when you stop.

Phase 3 — Plan

Write the plan to ./plans/<TICKET>.md. Use this structure:

# <TICKET> — <short title>

> Status: draft · Last updated: YYYY-MM-DD

## Problem
Observed behavior vs expected. Scope: who's affected, how often.

## Root cause
Hypothesis + evidence (stack trace, commit, code path with file:line references).

## Fix
Code-level changes: files, functions, diff sketch. Name every file you'll touch.

## Test strategy
- Unit tests: what cases
- Integration / system tests: what scenarios
- What regresses if the fix is wrong

## Rollout & risk
- Safety: migrations? feature flag? backfill?
- Blast radius: other features/projects touching the same code.
- Deploy: merge today, ship Monday (no Friday deploys).

## Follow-ups (out of scope)
Tech-debt or related issues discovered during research — new Jira tickets with label `bug-bash`.

After writing the plan, stop and ask the user to review. Do not proceed to Phase 4 without explicit approval.

Phase 4 — Implement

Once the plan is approved:

Create a git worktree off main:
```
cd ~/dev/platform
git worktree add ../platform-<TICKET-slug> -b fix/<TICKET>-<short-slug>
```
Record the worktree path in the plan file under a new ## Working Context section. All subsequent operations run inside the worktree.
Update the Jira ticket before coding:
- Move to "In Progress".
- Assign it to yourself (the engineer running this command).
- Ensure label bug-bash is present.
- Post a comment with the intent + link to the plan.
Implement using subagents for independent work:
- One agent writes failing tests first.
- Another implements the fix.
- Another reviews the diff for obvious issues. Run them in parallel when the tasks don't depend on each other.
Code quality rules (non-negotiable):
- 100% test coverage for every change (CLAUDE.md).
- Never log PII (pii_id, employee_id). Use org_id, work_order_id, trace_id for correlation.
- Run linters/formatters BEFORE pushing — don't rely on CI.
Open the PR:
- Title: fix(<area>): <short description> [<TICKET>]
- Body: link ticket, before/after summary, test evidence (screenshots / log snippets / test output).
- Request review from the code owner area.
Post in #bug-bash-apr-2026:
- PR link + one-line summary.
- Flag if you hit a blocker > 30 min.
Do NOT deploy on Friday. Merge-only today. Deploy lands Monday.

Output

./plans/<TICKET>.md — plan file (required before coding).
Git worktree at ../platform-<TICKET-slug> with branch fix/<TICKET>-<short-slug>.
PR on GitHub linked to the Jira ticket.
Jira ticket updated with intent + PR link + label bug-bash.

Guardrails

No code before plan approval. If the user types "go" without reviewing the plan, still ask explicitly: "Plan approved?"
No guessing root cause. Confidence < 75% → keep asking questions.
No Friday deploys. Merge, don't deploy.
No untracked work. Every touched file must be part of a ticket with label bug-bash.
Stop and report if you hit any of: auth/permissions issue, missing MCP access, data migration required, cross-team dependency.

AV4TAr/bug-bash.md

Select an option

No results found