Name: auditing
Rating: 60.8 (1 reviews)
Author: Automattic

auditing

Audit a Studio-backed WordPress site for performance, accessibility, and visible frontend quality issues, then recommend or validate improvements.

Quality

70%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./plugins/cline/.cline/skills/auditing/SKILL.md

The canonical home for this skill is auditing in Automattic/build-with-wordpress

Quality

Content

75%Weight 40%Scale 1-5

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 tight, actionable audit playbook: concrete tool names, numeric thresholds, a clear 7-step sequence, and honest caveats about synthetic measurements and visual-only accessibility review. Weaknesses are minor — no error-recovery guidance and exact tool invocation being delegated elsewhere.

Dimension	Reasoning	Score
Conciseness	The body is lean and operational — it never explains concepts Claude already knows (no "what TTFB is", no library tutorials) and every section carries instructions or concrete thresholds. Minor over-explanation exists (the `studio` pointer appears in both Ownership and Workflow, and "Report clearly"/"Important notes" could be tightened slightly), placing it just below the every-token-earns-its-place anchor 5.	4 / 5
Actionability	Concrete, executable guidance throughout: named MCP tools (`need_for_speed`, `take_screenshot`, `inspect_design`, `record_workflow_event` with exact `workflow`/`stage` parameters), a numeric threshold table for TTFB/FCP/LCP/CLS, quantified page-composition warning signs, and a default path (`/`). It falls short of anchor 5 only because exact tool invocation syntax is delegated to the `studio` skill rather than shown inline.	4 / 5
Workflow Clarity	A clearly sequenced 7-step workflow with explicit checkpoints: scope selection with user notification, `record_workflow_event` started/completed markers, and a re-test-and-compare-before-versus-after loop. It lacks error-recovery guidance (what to do when a tool fails or a fix regresses a metric), keeping it below anchor 5.	4 / 5
Progressive Disclosure	A single well-sectioned file with no bundle files, delegating tool-usage details to the external `studio` skill in a clearly signaled, one-level-deep way. Structure is good and navigation is easy, but the file runs ~145 lines with the threshold tables and WordPress-fix checklist inlined — content that could arguably split into a reference file — so it is not the clear-overview-with-well-signaled-references pattern of anchor 5.	4 / 5
	Total	16 / 20 Passed

Description

66%Weight 40%Scale 1-5

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 is specific and reasonably distinct, clearly stating what the skill does across three audit dimensions. Its main weakness is the absence of any explicit "when to use this" trigger guidance, which caps completeness and weakens natural trigger-term coverage.

Suggestions

Append a trigger clause such as: "Use when the user asks to audit, speed up, or QA an existing WordPress site, mentions slow pages, Core Web Vitals, contrast/readability issues, or wants before/after verification of fixes."

Include natural user synonyms ("slow site", "speed", "review my site", "QA") in the description to broaden trigger-term coverage.

Mention the WordPress-specific nature of the recommendations (plugins, theme CSS, block layouts) to further distinguish it from generic performance or review skills.

Dimension	Reasoning	Score
Specificity	"Audit a Studio-backed WordPress site for performance, accessibility, and visible frontend quality issues, then recommend or validate improvements" names the domain and several concrete actions across three audit dimensions plus recommendation/validation. It lists several specific actions with minor gaps in coverage rather than the comprehensive multi-action enumeration of anchor 5.	4 / 5
Completeness	The "what" is answered clearly (audit performance, accessibility, and visible frontend quality; recommend or validate improvements), but there is no "Use when..." clause or equivalent explicit trigger guidance anywhere in the description, which caps completeness at 3 per the judging guidelines.	3 / 5
Trigger Term Quality	Natural terms users would say are present ("audit", "performance", "accessibility", "WordPress"), giving good keyword coverage. Common variations a user might actually say — "slow site", "speed", "Core Web Vitals", "QA", "review my site" — are missing, keeping it below anchor 5.	4 / 5
Distinctiveness Conflict Risk	The "Studio-backed WordPress site" qualifier carves a mostly distinct niche with clear triggers, carrying only minor overlap risk with closely related general review/QA skills. Not anchor 5 because "audit...performance...quality" could still collide with generic site-review or code-review requests.	4 / 5
	Total	15 / 20 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: Automattic/build-with-wordpress
Path: plugins/cline/.cline/skills/auditing/SKILL.md
Commit: b4fc8b7

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.