From wp-agent-skills
Run a health check on the WordPress site — performance, broken links, security basics, plugin updates, and accessibility. Use before a site launch, after major changes, when something seems broken, or when the user asks to "check the site", "audit the site", or "make sure everything is working". Reports issues with severity levels and recommended fixes.
npx claudepluginhub antonysilverhand/wp-agent-skills --plugin wp-agent-skillsThis skill is limited to using the following tools:
Full site health audit. Reports issues by severity with recommended fixes.
Acquire memory dumps from live systems/VMs and analyze with Volatility 3 for processes, networks, DLLs, injections in incident response or malware hunts.
Provides x86-64/ARM disassembly patterns, calling conventions, control flow recognition for static analysis of executables and compiled binaries.
Identifies anti-debugging checks like IsDebuggerPresent, NtQueryInformationProcess in Windows binaries; suggests bypasses via patches/hooks/scripts for malware analysis, CTFs, authorized RE.
Full site health audit. Reports issues by severity with recommended fixes.
DEPTH — quick (home page only, ~30s) or full (all pages, ~5 min). Default: quick.Run all five checks in parallel using subagents — they are fully independent:
Collect all results, then compile the prioritised report. This turns a 5-step sequential audit into a single parallel sweep — typically 5× faster.
wp core check-update
wp plugin list --update=available --format=json | jq '[.[].name]'
wp theme list --update=available --format=json | jq '[.[].name]'
Flag security updates as CRITICAL. Feature updates as LOW.
# Measure TTFB and total load
curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s | Total: %{time_total}s | Size: %{size_download}B\n" \
"$WP_SITE_URL"
Thresholds:
Check for caching plugin:
wp plugin list --status=active | grep -E "litespeed|w3-total-cache|wp-super-cache|autoptimize"
No caching plugin on a live site → HIGH.
Quick: home page only. Full: all published pages.
# Extract all hrefs from a page
curl -s "$WP_SITE_URL" | grep -oP 'href="[^"]*"' | grep -oP '(?<=href=")[^"]*'
For internal links: check HTTP status. Expect 200 or 301. For external links: HEAD request, flag non-200. 404 on internal link → HIGH. 404 on external → MEDIUM.
wp config get WP_DEBUG # should be false on production
wp config get DISALLOW_FILE_EDIT # should be true
curl -s -o /dev/null -w "%{http_code}" "$WP_SITE_URL/wp-config.php" # expect 403
curl -s -o /dev/null -w "%{http_code}" "$WP_SITE_URL/?author=1" # expect 404 or 301
WP_DEBUG true in production → HIGHwp-config.php accessible → CRITICALFor each checked page:
curl -s "$URL" | grep -c 'alt=""' # images with empty alt
curl -s "$URL" | grep -c '<img ' # total images
curl -s "$URL" | grep -c '<main' # should be >= 1
curl -s "$URL" | grep -oP '<h[1-6]' | sort # check heading hierarchy
<main> landmark → MEDIUMcurl TTFB includes DNS lookup. Run twice and use the second result — DNS is cached on the second call.check-update pings WordPress.org. It will fail on servers with no outbound internet. Catch the error and note "update check unavailable".WP_DEBUG may be set in a .env file, not wp-config.php, in which case wp config get WP_DEBUG won't see it. If the site uses a .env loader, also check that file./?author=1: some themes redirect this to the author archive intentionally. Check the response body — if it's a profile page, enumeration is active. If it's a 404 page, it's blocked.Prioritised issue list:
CRITICAL — fix immediately (security, data loss risk) HIGH — fix before launch (performance, broken user flows) MEDIUM — fix soon (SEO, accessibility, minor UX) LOW — nice to have
Each issue: what it is, where it is, one-line fix.
End with: "X critical, X high, X medium, X low issues found."
Suggest wp-seo-pass all if SEO issues were found.