CtrlK
BlogDocsLog inGet started
Tessl Logo

auditing

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

60

Quality

70%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

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

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

SKILL.md
Quality
Evals
Security

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.

DimensionReasoningScore

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.

DimensionReasoningScore

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%

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
Reviewed

Table of Contents

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.