running-bug-review-boardlisted

Runs a real-user manual QA pass against any web/mobile/desktop app and turns the results into a Bug Review Board (BRB) feedback loop. Use whenever the user says "QA this", "test phase N", "run a manual test plan", "act as a real user", "find UX bugs", "sign off this build", "file a bug report", or "is this ready to ship?" — even if they only describe the symptoms ("the signup flow feels broken", "check what's wrong before we move on", "we finished feature X"). Drives the trifecta: PM (verifies user-promise), QA (executes scenarios from a real user's perspective), and Engineer (flags invalidated assumptions). Repo-agnostic, browser-tool-agnostic, scaffolds folders for bug reports + run reports + coordinator merges with P0/P1/P2 priorities. Works alongside cursor-ide-browser, browser-use, Playwright, manual driving, or any future browser tool.
RayFernando1337/rayfernando-skills · ★ 5 · Code & Development · score 77

Install: claude install-skill RayFernando1337/rayfernando-skills

# Running the Bug Review Board (BRB) QA pass This skill runs a **real-user QA pass** on an app and feeds the output into a Bug Review Board: a folder of structured bug reports, per-pass run reports, and a final YES/NO sign-off the team can act on. It generalizes a battle-tested workflow that already shipped phase QA on Mokuhoe — the techniques are repo-agnostic. ## Why this exists Most engineers test their own code. They confirm what they wrote works. That misses the bugs **real users hit first** — stale state across flows, mobile overflow, copy that lies, paths that 404 mid-onboarding, race conditions between auth and routing. This skill simulates a real user. The QA agent acts like a careful, mildly unforgiving customer who does not read the source code. ## The trifecta — three hats, one pass For every pass, wear all three hats: - **Product Manager.** Confirm the build delivers the user-visible promise documented in the product spec or phase doc. If it does not, that is a product gap, not a bug — flag it in the run report. - **QA.** Execute every scenario from a real user's perspective on the primary supported viewport(s). Capture evidence (snapshot, console, server data when relevant). Pass / Fail / Blocked. - **Engineer.** Watch for invalidated assumptions: phase doc says "X uses function Y" but Y was renamed; new client orchestration appeared in a flow the docs say is server-driven; fields exist in UI that aren't in the spec. **Finding gaps is the po