mcpField
M
miniapp-devtools-gui-check

miniapp-devtools-gui-check

github.com/sun-sunshine06Testing & quality2838 installsUpdated 6d ago
Repository

About miniapp-devtools-gui-check

A skill for checking miniapp runtime behavior through the GUI when CLI preview is insufficient. It guides narrow smoke checks and evidence-based diagnosis of app, host, session, and local-service issues.

Key features

  1. 01GUI runtime smoke checks
  2. 02Route- or flow-scoped testing
  3. 03Report and trace inspection
  4. 04Failure-stage classification
  5. 05Host and session diagnosis

Use cases

  1. 01Check a miniapp route in the real host
  2. 02Diagnose a missing report using trace.log
  3. 03Separate app defects from DevTools issues
  4. 04Collect runtime evidence before reporting results

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/sun-sunshine06/miniprogram-skills --skill miniapp-devtools-gui-check

After installing, type/miniapp-devtools-gui-checkin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

agents/
openai.yaml
references/
example-prompts.md
gui-check-playbook.md

Details

From the project README

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

  1. Read references/gui-check-playbook.md.
  2. Confirm the run will happen on the real host, not inside a restricted sandbox.
  3. Start with one route or one user flow, not the full app.
  4. Run the local GUI checker if the repo provides one.
  5. Inspect the generated report.json before claiming success or failure.
  6. If report.json is missing, inspect trace.log in 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.log but no report.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:

  1. which route or flow was checked
  2. whether automation really connected
  3. what runtime evidence was collected
  4. whether the issue is in repo code, session state, a local service dependency, or still needs manual visual confirmation
  5. 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 harness
  • references/example-prompts.md: reusable trigger examples and evaluation notes

Comments

Markdown supported