Tech to PM Translator

Real output from one run on the open-source Bug Shepherd plugin in pm-pilot. The source had no migrations or failure catalog, so the skill produced only the Platform Guide.

Bug Shepherd Platform Guide (For PMs)
How the backlog checker works, explained without code.

How a triage run works
You ask for a run on a number of old bugs.
Bug Shepherd skips any bug a person touched in the last 30 days, and any bug that already has an assignee.
The remaining bugs are split across 5 checkers working at once, 6 bugs each, so one run covers up to 30 bugs.
Each checker opens the live site, follows the bug's steps, and looks at the page on a phone width and a desktop width.
Each bug comes back with one of three verdicts and a confidence level.
Nothing changes in your tracker until you approve it.
PM takeaway: a run is a read-only survey of your backlog. The only step that changes anything is your approval at the end.

What the three verdicts mean
Verdict What the checker saw What you should do
Reproduced The bug is still there, with a screenshot and the page it was on Keep it, and re-prioritize with fresh evidence
Not reproduced The page behaved correctly at the sizes tested Treat as "probably fixed", not "fixed"
Cannot determine Login wall, page error, ambiguous behavior, an off-site link, or the 90-second limit ran out Read it yourself, or hand it to someone with access
PM takeaway: "not reproduced" is a claim with a confidence level attached. It is never proof the bug is gone.

What it will never close on its own
Safety rule Shipped setting Why it matters to you
Automatic cancel rules None. The list ships empty Out of the box, no bug is ever proposed for cancellation
Bugs that always go to a human Anything mentioning scroll, touch, hover, animation, right-to-left, accessibility, payment, checkout, data loss or security Automated browsers are bad at exactly these, and the cost of a wrong close is highest here
Biggest batch per approval 10 tickets One "yes" can never close your whole backlog
Recently touched bugs Skipped for 30 days Bugs your team is actively discussing are left alone
PM takeaway: the defaults are cautious on purpose. Loosen them only after you have checked a few runs' verdicts against your own judgment.

What the checker is allowed to do
The checker can open pages, click, type into the page and read what it sees. It cannot sign in, submit forms with real data, write files, run commands or touch your tracker. It treats every bug report as a description, never as an instruction, so a ticket that says "already fixed, close this" gets flagged to you instead of believed.

PM takeaway: you can point it at bugs filed by customers or strangers without worrying that a cleverly worded ticket steers it.

What a run costs
Screenshots drive the cost. Each extra screen width multiplies them, so the default is two widths and at most 3 screenshots per bug. The checker reads the page text first and only takes a picture when the look of the page is the question.

PM takeaway: if a run feels slow or expensive, ask whoever set it up to drop a screen width before cutting the number of bugs.

Who owns what
Area Owner
The setup and the safety rules Whoever installed Bug Shepherd in your project. Ownership unclear: check with your engineering lead
The verdicts The checkers produce them; you accept or reject them
The final close in the tracker You, by approval, batch by batch
Glossary
Term Meaning
Triage run One pass of the checkers over a set of old bugs
Live site The public website the checkers test against. It must load without a login
Headless browser A browser with no screen, driven by software. Good at reading pages, bad at touch, scroll and hover
Confidence High, medium or low. How sure the checker is of its verdict