QA and testing
Testers pin bugs on the element that broke, and Skyelight records where it happened. Fixes are reported and verified on the same thread.
The problem
A good bug report takes work: steps to reproduce, the URL, the browser, a screenshot, and which element. Most reports skip half of that, and the engineer spends the first twenty minutes working out what the tester saw.
In a big test pass, the same bug gets logged four times by four people. Someone fixes one copy and the other three stay open. A bug that was fixed last month comes back and gets filed as new.
By launch week, nobody trusts the bug list.
Where Skyelight fits
Testers work on the real build and pin bugs on the element that’s broken. Skyelight records the page URL, the element and its page context, plus a screenshot if your workspace has turned screenshots on. The tester adds what happened and what they expected.
Tip: Write bug comments in two lines. “I did X. I expected Y, but got Z.” The page context covers where it happened.
The fix loop
- Testers walk the build and pin everything that’s off.
- Triage the threads: assign owners, defer the non-blockers, and merge duplicates through a connected agent or the API.
- Engineers, or a coding agent connected through the MCP server, open each thread with its replies and page context.
- The fix is posted as a reply on the thread, with a link to the pull request or deploy.
- The tester reopens the page, checks the element they flagged and resolves the thread.
What you get
- Context is captured with every thread, so reports take less effort.
- The bug count stays accurate: duplicates are merged into one thread and deferred threads are kept apart from open ones.
- Engineers start fixing instead of asking questions.
- At launch, you know what’s open, what’s deferred and what’s resolved.