sun-sunshine06 Miniapp Devtools Gui Check
Overview
Use this skill when CLI preview is not enough and the user needs GUI-side runtime evidence. Prefer it for smoke coverage, not for full visual regression.
Quick Start
- Read
references/gui-check-playbook.md. - Confirm the run will happen on the real host, not inside a restricted sandbox.
- Start with one route or one user flow, not the full app.
- Run the local GUI checker if the repo provides one.
- Inspect the generated
report.jsonbefore claiming success or failure. - If
report.jsonis missing, inspecttrace.login the same run directory before blaming repo code.
Core Rules
- Treat the host environment as part of the system under test.
- Prefer narrow smoke checks over "all routes at once" until the session is stable.
- Trust runtime exceptions, console events, page path, and selector presence more than screenshots.
- Treat screenshots as best-effort evidence, not the primary signal.
- Keep the checker config-driven so route specs, backend prerequisites, and output locations are explicit.
- If the run directory contains
trace.logbut noreport.json, classify the failure by stage first:- launcher or websocket stage usually means DevTools session or host setup
- page stage usually means route-level runtime or state issues
- Separate repo bugs, DevTools session problems, local service blockers, and remaining visual-only questions.
Output Format
When answering, keep the result operational:
- which route or flow was checked
- whether automation really connected
- what runtime evidence was collected
- whether the issue is in repo code, session state, a local service dependency, or still needs manual visual confirmation
- the next command or user action
Resources
references/gui-check-playbook.md: host prerequisites, failure classification, and reporting guidance../../tools/wechat-gui-check/README.md: current extraction target for the public harnessreferences/example-prompts.md: reusable trigger examples and evaluation notes