Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Sun-sunshine06/miniprogram-skills --skill miniapp-devtools-gui-checkgit clone --depth 1 https://github.com/Sun-sunshine06/miniprogram-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/sun-sunshine06/miniprogram-skills/miniapp-devtools-gui-check)<a href="https://agentmods.dev/skills/sun-sunshine06/miniprogram-skills/miniapp-devtools-gui-check"><img src="https://agentmods.dev/badge/skills/sun-sunshine06/miniprogram-skills/miniapp-devtools-gui-check.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00083 | $0.00550 |
| Opus 5 | $0.00042 | $0.00275 |
| Sonnet 5 | $0.00017 | $0.00110 |
| Haiku 4.5 | $0.00008 | $0.00055 |
Grade A, and why
miniapp-devtools-gui-check scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 54 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 54 lines · 83 tokens per session scan A d091686e983a
miniapp-devtools-gui-check is a skill published in the GitHub repository Sun-sunshine06/miniprogram-skills (22 stars, last pushed 1mo ago), licensed MIT. It adds 83 tokens to every session and 550 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
browser-harness-agentloom
Use when working on AgentLoom browser-harness integration or debugging applications/browserharnessprobe: creating or updating the probe Application, installing the external browser-harness CLI, validating isolated or real Chrome browser control, and diagnosing browser-harness doctor, daemon, Chrome remote debugging…
browser-edge-cases
SOP for debugging browser automation failures on complex websites. Use when browser tools fail on specific sites like LinkedIn, Twitter/X, SPAs, or sites with Shadow DOM.
d3k
Use when the user asks to use d3k, run/dev/test/debug a web project with d3k, or reproduce a browser issue. Own the runtime: reuse or background-start d3k non-interactively, wait for readiness, use its project-stable managed Chrome profile, and inspect unified browser/server evidence.
manage-skills
A maintenance workflow for checking whether project verification skills still cover the code and rules that changed during a session.
systematic-debugging
Structured debugging methodology — use before proposing fixes for any error or failure. Covers: code bugs, build errors, deploy failures, config conflicts, dependency issues, infra problems. Also use when previous fix attempts failed or root cause is unclear.
eslint-fix
A project-aware assistant for finding and fixing ESLint errors, warnings, and configuration compatibility problems. ESLint is a tool that checks JavaScript and TypeScript code for style and common mistakes.