メニュー
Turns a WordPress Site Health report into a risk-tiered, backup-first fix plan with exact WP-CLI/PHP snippets. Use for site health, recommended improvements, or critical issue reports.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/canar1406/thaytrieu --skill wp-site-health-auditorコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Security audit, hardening, threat modeling (STRIDE/PASTA), Red/Blue Team, OWASP checks, code review, incident response, and infrastructure security for any project.
Design frictionless signup experiences for developers including GitHub OAuth, API key generation, and onboarding personalization. Trigger phrases: developer signup, dev registration, OAuth flow, API key onboarding, reduce signup friction, developer authentication, signup conversion,...
Delegate tasks to OpenAI Codex CLI and Google Antigravity CLI from Claude Code with topic-aware sessions
SOC 職業分類に基づく
SKILL.md を表示中
| name | wp-site-health-auditor |
| description | Turns a WordPress Site Health report into a risk-tiered, backup-first fix plan with exact WP-CLI/PHP snippets. Use for site health, recommended improvements, or critical issue reports. |
| category | development |
| risk | critical |
| source | self |
| source_type | self |
| date_added | 2026-07-03 |
| author | whoisabhishekadhikari |
| tags | ["wordpress","site-health","wp-cli","seo","performance","security","hardening"] |
| tools | ["claude","cursor","codex","gemini"] |
Tools > Site Health), as text or screenshotTools > Site Health > Info) and asks what's wrongTurns a WordPress Site Health report (Critical issues / Recommended improvements / Passed tests) into a prioritized, risk-tiered fix plan — then executes the safe fixes and hands off the rest with exact commands or code.
This skill edits wp-config.php, .htaccess, and php.ini-equivalent settings, and deletes plugins and
themes. All three are one bad edit away from a white-screen-of-death or a broken upload path. Never skip
this section, even for a one-line change, even if the user is in a hurry.
Before any edit or deletion, in this order:
cp wp-config.php wp-config.php.bak-$(date +%Y%m%d-%H%M%S)
cp .htaccess .htaccess.bak-$(date +%Y%m%d-%H%M%S)
wp search-replace. If the user doesn't have one and has a backup plugin active (UpdraftPlus, etc.),
trigger a backup first: wp updraftplus backup or the plugin's own WP-CLI command, or tell them to
click "Backup Now" and wait for confirmation before continuing.wp search-replace without --dry-run first, and always show the dry-run output to the
user before running it for real. This command rewrites the database in place — a wrong pattern can
corrupt serialized data across every table it touches.php -l wp-config.php
.htaccess changes, run apachectl configtest if available, or check the site immediately.
A syntax error in wp-config.php takes the entire site down immediately. Do not skip the lint check to
save a step.cp wp-config.php.bak-<timestamp> wp-config.php
If the user says "just do it, skip the backup" — still create the backup silently as part of the edit
sequence and tell them you did. Refuse to skip step 1 or step 4 entirely; those two are non-negotiable
regardless of urgency, since the failure mode (corrupted wp-config.php, dead site) is worse than the ten
seconds a backup costs.
The Site Health screen is diagnostic, not prescriptive. It tells the site owner that something is wrong (e.g. "you should use a persistent object cache") but not how to fix it, and it mixes items that are one-click-safe (deactivate a plugin) with items that require host-level changes (php.ini, object cache backend) or are purely informational (SQL server version — no action needed). This skill sorts that out — safely.
Input is usually one of:
Tools > Site Health (Status tab)Tools > Site Health > Info (the debug data export)wp site-health check is not a core command; note that up front, don't invent one — see Phase 4)Extract three buckets exactly as WordPress labels them:
If the report is a screenshot, transcribe item titles + category tags (Security/Performance/SEO/Privacy) verbatim before triaging — don't paraphrase the WordPress-generated title, it's used for the fix lookup in Phase 3.
If no report was pasted and the user just says "audit my site health," ask them to paste the Status tab text (fastest) rather than guessing — Site Health results are host- and config-specific and guessing wastes a turn.
Classify every non-passed item into one of three tiers before touching anything. Present this triage table to the user first for anything above Tier 1 count of 3+ items — don't silently start deactivating plugins.
Tier 1 — Safe, reversible, auto-fixable in wp-admin or via WP-CLI No data loss risk, no downtime, fully reversible. Still back up per the Safety section before deleting anything. Fix directly once the user confirms the item list.
WP_DEBUG display in production (WP_DEBUG_DISPLAY, not WP_DEBUG itself if the user still
wants logging)Tier 2 — Requires host/server-level access — Claude drafts the change, user or host applies it Cannot be fixed purely from wp-admin; needs php.ini, .htaccess, wp-config.php, or hosting panel access. Draft the exact snippet, explain where it goes, remind the user of the backup + lint steps above, and flag that a server restart or host support ticket may be needed.
post_max_size < upload_max_filesize mismatchTier 3 — Informational / host-dependent, no fix exists or none needed Report as informational only. Do not attempt a fix, do not suggest one unless directly asked.
Match the WordPress-generated item title (case-insensitive substring match is fine) to a recipe below.
Every recipe below assumes the Safety section has already been followed for that file. If an item doesn't
match anything here, say so explicitly rather than fabricating a fix — Site Health's item set changes
across WP core versions and this list isn't exhaustive (see references/catalog.md for the fuller list
including rarer items).
# confirm full site backup exists first (Safety step 2)
wp plugin list --status=inactive --field=name
wp plugin delete <plugin-slug>
wp theme list --status=inactive --field=name
wp theme delete <theme-slug>
Never delete the currently active theme's parent if the active theme is a child theme. Never delete Twenty Twenty-Five (or the current default core theme) if it's the only fallback theme — WordPress needs at least one broken-theme fallback; recommend keeping one bundled default even if inactive. Confirm the exact plugin/theme names with the user before deleting — inactive isn't the same as unused; some plugins are intentionally kept inactive as a staged rollback.
This breaks large file uploads (post data gets truncated before the file size limit is even reached).
Fix by raising post_max_size to be >= upload_max_filesize, typically with headroom for form overhead.
Where to set it (pick whichever the host supports, in this order of preference):
php.ini (if the user has server access) — back up first (cp php.ini php.ini.bak-<timestamp>):
upload_max_filesize = 64M
post_max_size = 128M
.htaccess (Apache + mod_php only, not on PHP-FPM/nginx) — back up first:
php_value upload_max_filesize 64M
php_value post_max_size 128M
.htaccess directive can 500 the entire site. Run apachectl configtest if available
before reloading, or check the live site immediately after saving..user.ini (CGI/FastCGI hosts; not mod_php) — back up first, create or edit .user.ini
in the WordPress root:
upload_max_filesize = 64M
post_max_size = 128M
ini_set() in wp-config.php for these directives — upload_max_filesize
and post_max_size are PHP_INI_PERDIR, which means they can only be set before the
request starts (php.ini, .htaccess, .user.ini). ini_set() calls silently fail for both,
leaving the problem unfixed.Always set post_max_size strictly greater than upload_max_filesize. Confirm the current values first
(wp cli info doesn't show these — check phpinfo() or the host panel) rather than assuming defaults.
Requires a caching backend (Redis or Memcached) installed at the server level — this is not something a plugin alone can create out of nothing.
wp plugin install redis-cache --activate then wp redis enable. This writes
an object-cache.php drop-in to wp-content/ — confirm no existing object-cache.php is being
overwritten (check first with ls wp-content/object-cache.php); if one exists, back it up before enabling.wp plugin install wp-super-cache --activate then enable caching from its
settings screen (no reliable WP-CLI toggle across cache plugins — flag manual step to user)..htaccess — back it up
first per the Safety section before activating.Back up wp-config.php first, lint after editing:
// wp-config.php
define( 'WP_DEBUG', false ); // set to true only while actively debugging
define( 'WP_DEBUG_DISPLAY', false ); // never show errors to visitors
define( 'WP_DEBUG_LOG', true ); // logs to wp-content/debug.log instead
Usually a security plugin, firewall, or .htaccess rule blocking internal requests. Steps:
wp-config.php doesn't have define('DISALLOW_FILE_MODS', true) set incorrectly for background
updates specifically, if that's the failing item. Back up before removing/editing that line.wp option get siteurl
wp option get home
Both must be https://. Also check for mixed-content (http:// hardcoded in content/theme). Confirm a full
database backup exists, then dry-run before applying for real:
wp search-replace 'http://olddomain.com' 'https://olddomain.com' --dry-run
Only remove --dry-run after the user has reviewed the dry-run output and confirmed the replacement count
and matched rows look correct.
wp site-health WP-CLI command in WordPress core as of this writing — don't fabricate one.
Fixes are applied via the specific commands above, not a single audit-and-fix CLI call.upload_max_filesize, cache backend availability, etc.) — ask or
have the user check phpinfo() / host panel rather than assuming common defaults are in place.wp-config.php is as fatal
as a large edit.Give the user:
Keep the whole response scannable — this is a punch list, not an essay. Use the table + short recipe blocks above, not prose paragraphs, unless the user asks for more explanation on a specific item.
wp plugin install redis-cache --activate
wp redis enable
ls wp-content/object-cache.php existswp-config.php:
cp wp-config.php wp-config.php.bak-$(date +%Y%m%d-%H%M%S)
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
php -l wp-config.php passescp takes seconds, restoring a dead site takes hoursphp -l after editing wp-config.php before reloading the sitewp search-replace with --dry-run first and show the output to the userreferences/catalog.md — extended list of less-common Site Health items (SEO category items like llms.txt
generation, Privacy items, rarer Security items) with the same tier classification, for reports that
include items not covered above.
ini_set() for upload limits — upload_max_filesize and post_max_size are PHP_INI_PERDIR; ini_set() silently fails. Use php.ini, .htaccess, or .user.ini instead.wp search-replace — A wrong pattern can corrupt serialized data. Never run it without --dry-run first.phpinfo() or their host panel.references/catalog.md) reflects WordPress core's Site Health checks as of
mid-2026 — item titles/wording can change across core versions, so an unmatched item should be reported
as unmatched, not force-fit to the closest recipe.@security-hardening — For deeper WordPress security audits beyond Site Health's surface checks@wp-performance — For targeted performance optimization after Site Health flags are resolved