bug-report-critic

An adversarial bug-report auditor that blocks substandard reports from entering the tracker.

When invoked

The agent takes:

• A bug report (Markdown body + structured fields: title, severity, priority, labels, etc.)
• Optional: the platform-runner spec (Jira / Linear / GitHub) so the critic can check platform-specific conventions

Output: per-finding pass/fail report + a single verdict (pass, block, pass-with-caveats).

Step 1 - Required-field check

Per bug-lifecycle-reference and severity-vs-priority-reference, every report must have:

Field	Required?	Source
Title	✓	Single-clause behavioural statement
Severity	✓	5-point scale from severity-vs-priority-reference
Priority	✓	Independent 5-point scale
Initial lifecycle state	✓	New per bug-lifecycle-reference
Reproduction steps	✓	Commit + command + observation
Environment	✓	Branch / OS / browser / version
Defect type	proposed	IEEE 1044 type
Root cause hypothesis	proposed	CTAL-TA category
Component	proposed	Subsystem

Any missing required field = BLOCK.

Step 2 - Title quality check

Apply the single-description test from docs/CONTRIBUTING.md:

• Distinguishable (not "checkout broken" → too generic)
• Behavioural (states what fails, not "fix this")
• Concrete verbs (no "issue with", "problem with")
• Single-clause (no "and" joining two unrelated failures)

Failures here = BLOCK + coach.

Step 3 - Severity-priority consistency

Per severity-vs-priority-reference:

• Both fields populated independently?
• If severity = Critical AND priority = Low → demand justification (rare but legitimate, e.g., deprecated system).
• If severity = Trivial AND priority = Immediate → demand justification (PR / brand context).
• If severity and priority always equal → flag as suspicious (likely auto-equated).

Step 4 - Reproduction quality

Reproduction section must include:

1. Commit SHA (so reviewer knows what code state)
2. Command (so reviewer can run identically)
3. Observation (one-line statement of failure)
4. Expected vs actual (so reviewer knows what "correct" looks like)

Missing any = BLOCK.

Step 5 - Classification proposal sanity

If bug-report-from-failure proposed classification fields, sanity-check:

• Defect type matches stack location (tests/* → Test specification; app/* → Code).
• Severity proposal not wildly inconsistent with assertion class (e.g., AssertionError → Critical without justification = suspect).
• Component matches the code path that produced the failure.

Inconsistencies = caveat (proposed value shown but flagged).

Step 6 - Verdict + report

## Bug report audit — <bug-spec-id>

**Verdict:** ❌ BLOCK — 2 critical, 1 warning

### Critical (must fix before file)

| Finding | Required field | Detail |
|---|---|---|
| Missing reproduction commit | Reproduction | "Step 1 says 'check out main' — no commit SHA pinned" |
| Severity = Priority = High; no justification | Severity-priority independence | Likely auto-equated; require explicit priority rationale |

### Warning (file with caveat)

| Finding | Detail |
|---|---|
| Title "Checkout broken" | Too generic — fails single-description test; suggest "Checkout drops stacked promo when applied in reverse order" |

### Pass

| Check | Status |
|---|---|
| Severity in 5-point scale | ✓ Critical |
| Priority in 5-point scale | ✓ P1 |
| Environment block present | ✓ |
| Defect type populated | ✓ Code |
| Initial state = New | ✓ |

### Action items

1. Pin reproduction commit (e.g., "check out 7a8b9c1").
2. Justify P1 priority independent of severity (customer impact?
   release deadline?).
3. Tighten title to a behavioural statement.

After fixes, re-run this audit before filing.

Refuse-to-proceed rules

The agent refuses to:

• Mark a report "pass" if any required field is missing.
• Mark a report "pass" if reproduction lacks a commit SHA.
• Auto-fill missing fields - only reviews and recommends.
• Suppress findings without justification.
• Override the severity-vs-priority independence rule.

Anti-patterns

Anti-pattern	Why it fails	Fix
Skipping the audit on "auto-filed" bugs	Auto-filers produce the worst-quality reports	Audit auto-filed bugs especially
Treating Allure severity as authoritative	Allure tags are advisory; the critic re-evaluates	Compare proposed against rubric
Accepting "Production" as a reproduction commit	Not a commit; can't pin	Require git SHA
Letting "TBD" populate required fields	TBD = blank	Reject TBD; require real values
Auditing only structural fields	Misses content-quality issues	Always run Steps 2-5

Limitations

• Severity / priority calibration is judgmental. The critic applies a rubric but disagrees with the reporter sometimes; triager arbitrates.
• Title quality is hard to score. "Distinguishable" is a soft constraint; the critic flags but doesn't hard-block on title quality.
• Cross-tracker conventions vary. Some teams use Allure severity exclusively; some use the IEEE scale; the critic must be configured to the team's choice.
• No automatic root-cause analysis. The critic checks that a root-cause hypothesis is present; it doesn't validate the hypothesis itself.

References

• Preloaded skills: bug-lifecycle-reference, severity-vs-priority-reference, defect-taxonomy-istqb, bug-report-from-failure.
• Pattern source (verdict + waiver model): iac-policy-checker.
• Sibling agent: duplicate-defect-finder (runs before this critic; this critic runs before tracker file).