module-userscript

Build a Greasemonkey/Tampermonkey userscript module

Quality

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./app/src/main/assets/skills/module-userscript/SKILL.md

Quality

Content

87%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is a lean, highly actionable reference — a complete executable template plus concrete grant and match guidance — with clean single-level organization, but its workflow lacks explicit validation/checkpoint steps for a reviewed, file-producing task, which caps workflow clarity.

Suggestions

Add an explicit validation checkpoint to the workflow, e.g. "After writing the file, re-read the metadata block to confirm every @grant is actually called in the IIFE and @match is scoped (not *://*/*)."

Surface a short error-recovery loop for rejected grants (declare only what you use -> if a grant is unused, remove it before finishing).

Optionally split the longer @grant / @match reference and Panel UI detail into a one-level-deep reference file with a signaled link, which would keep the overview even tighter without losing detail.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes Claude's competence — a compact executable metadata-block template, a flat @grant list, and terse bullet rules — with no padding explaining what a userscript is or how GM_ APIs work.	3 / 3
Actionability	It gives a copy-paste-ready ==UserScript== template, an exhaustive concrete @grant value list, real @match glob examples, and exact registration calls (window.__wta_module_action_<name>), all executable rather than pseudocode.	3 / 3
Workflow Clarity	The Workflow section lists five sequenced steps, but for a build task involving file writes and reviewed grants it has no validation checkpoint (e.g. verify the metadata block parses, confirm granted APIs are all used) and the destructive/anti-pattern 'Don't' list lacks a feedback loop, capping it at 2 per the batch/destructive-operation guideline.	2 / 3
Progressive Disclosure	For a skill well under 50 lines with no external bundle files, the body is cleanly sectioned (Output, @grant, @match, Workflow, Don't, Panel UI, Working with the user) with no nested references, satisfying the simple-skill allowance for a 3.	3 / 3
	Total	11 / 12 Passed

Description

57%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description marks a clear, distinct niche and surfaces a few natural trigger terms, but it relies on a single vague action ("Build") and parks the explicit usage trigger in a separate when_to_use field phrased in second person rather than folding an explicit 'Use when' clause into the description itself.

Suggestions

Expand the description to list concrete actions (e.g. author the ==UserScript== metadata block, declare @grant APIs, set @match patterns, write the IIFE body) instead of the single verb "Build".

Fold an explicit 'Use when...' trigger into the description text itself (e.g. "Use when the user asks for a Greasemonkey/Tampermonkey userscript or mentions .user.js files, GM_ APIs, or site tweaks") and phrase it in third person.

Add more natural trigger variations users actually say ("monkey script", "userscript", "browser userscript", "tampermonkey script") to broaden keyword coverage.

Dimension	Reasoning	Score
Specificity	"Build a Greasemonkey/Tampermonkey userscript module" names the domain and a single concrete action (build), but does not enumerate multiple specific actions like authoring metadata blocks, declaring grants, or matching URL patterns.	2 / 3
Completeness	The "what" is stated (build a userscript module), and when_to_use gives an explicit trigger ("User wants a .user.js style script"), but it lives in a separate field rather than the description and is phrased in second person; the anchor for 3 requires both what and an explicit 'Use when...' trigger, which is borderline but here the trigger is explicit so it caps at 2 due to the split-field phrasing.	2 / 3
Trigger Term Quality	It surfaces natural terms users say ("Greasemonkey", "Tampermonkey", "userscript", ".user.js") via when_to_use, but misses common variations like "monkey script", "browser extension script", or "GM_* APIs" appearing only as jargon.	2 / 3
Distinctiveness Conflict Risk	The userscript/Greasemonkey/Tampermonkey niche with a .user.js trigger is sharply distinct from generic coding skills and unlikely to fire for the wrong skill.	3 / 3
	Total	9 / 12 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: shiaho777/web-to-app
Path: app/src/main/assets/skills/module-userscript/SKILL.md
Commit: fc7af6a

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.