Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →superset-sh/cdp-verification
Verify UI behavior end-to-end by driving the running desktop app over the Chrome DevTools Protocol.
Passed 12 of 17 test cases with the skill, and 6 of 17 without it.
and 12 more in the full report
10 fixed6 passed either way4 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
In a non-local desktop deployment where bearer tokens are stored in memory, a cookie-only endpoint check fails. What path should be evaluated inside the renderer to verify session validity?
| Checked | Without skill | With skill |
|---|---|---|
| Instructs evaluating the authentication client module from the renderer dev server to request session details | Missed | Passed |
| Prohibits calling or displaying the raw authorization bearer token string | Missed | Passed |
The instructions your model reads when the skill loads.
"Rules" below is what counts as valid evidence. "Mechanics" is how to attach to the right renderer
and repair auth. apps/desktop/scripts/cdp-smoke-integrations.ts is a working example script.
Target the correct app instance. Confirm and report the worktree, renderer URL/port, and active route before testing. Follow any task-provided CDP/auth guidance and verify the expected signed-in session. Another running desktop instance is not equivalent.
Reproduce the exact user journey. Use real browser input and visible UI navigation for the steps the user performs. Assigning DOM properties, invoking internal app APIs, or running component-only scripts is diagnostic support, not proof of end-to-end behavior.
Capture visual and numeric evidence. Take before/after screenshots paired with relevant CDP
measurements (scrollTop, focused element, route, persisted state). Confirm the screenshot and
the measured state agree.
Exercise the relevant lifecycle. Include the actual route change, workspace/pane/file switch, remount, or close/reopen from the report. A narrower synthetic flow cannot substitute for the reported interaction.
Treat a mismatch as an incomplete reproduction. If the test passes but the user still observes the bug, re-check the target instance, exact steps, input method, persisted keys, and lifecycle timing. Reproduce the failure before changing code; a synthetic smoke test does not disprove the report.
Use an evidence gate. For a reported bug or regression, do not claim verification until the original interaction demonstrably fails before the fix and passes after it under the same observations. For a new feature, record equivalent baseline evidence and demonstrate the expected behavior. State clearly which checks were end-to-end, which were synthetic, and whether screenshots were actually captured.
Test in the real layout, not a staged one. Do not rearrange the UI to make coordinates convenient (e.g. moving a target project next to the section under test) and then generalize from that pass. Layout-dependent failures live exactly in the configurations a staged setup removes: elements far apart, ambiguous zones between valid targets, scrolled containers, collapsed/empty states. Verify in the user's actual data shape; if a mutation was needed for setup, rerun the key journey in the unstaged arrangement too.
test cases passed, vs 6 / 17 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.