agent-skills

Ten skills, each for one task

This collection holds ten skills for coding agents that support the Agent Skills format. Each one covers a task that the public skill collections did not cover, or covered in a line or two, when the collection was planned in September 2026. A skill is a folder: SKILL.md holds the instructions, references/ the detailed material with the source URL beside every fact, and scripts/ the helpers. Every SKILL.md records the date its facts were last checked; for all ten that is 26 September 2026.

The skills share a few rules. A skill is instructions, so nothing runs until your agent picks it for a task and follows it. The helper scripts only read and make no network requests. Skills that touch a live site tell the agent to take a backup first, prefer a dry run, and ask you before any write, one step at a time. Each ends with a report the agent fills in from command output, never from memory. The collection's maintenance file sets a review of every skill against its sources each quarter and a link check on the first day of every month.

Install a skill

Copy the whole folder into your agent's skills folder, not only SKILL.md: the instructions load files from references/ and scripts/ by relative path. Your agent's documentation says where that folder is.

git clone --depth 1 https://github.com/hamzaahmadaslam/agent-skills.git
cp -R agent-skills/wp-vip-code-review "<your agent's skills folder>/"

wp-vip-code-review: a change against VIP's rules

Reviews a change for a WordPress VIP site in two passes. First PHPCS with the WordPress-VIP-Go standard, limited to the lines the change touches, which is the scope VIP's Code Analysis Bot uses; --severity=1 matters, because PHPCS hides severities 1 to 4 by default and the Bot shows them. Then a manual pass for what sniffs cannot judge: output that depends on a cookie, writes on a GET request, remote calls without a short timeout, unbounded queries, file writes outside /tmp and uploads, escaping, nonces and capabilities, cron intervals and redirects. Findings are sorted into blockers, fix before merge, should fix, cleanup and pre-existing, and the review ends with a verdict. It never runs phpcbf, which rewrites files, and runs nothing against a VIP environment. Without PHP and Composer it does the manual pass only.

wp-multisite-migration: moving a site in or out of a network

Moves one site between a multisite network and a standalone install, in either direction: the wp_N_ tables, network users and their capability keys, uploads/sites/N paths, domain mapping (in core since WordPress 4.5, or sunrise.php), serialized-safe search-replace, network-activated plugins, redirects, verification and rollback. It transforms copies and leaves the source untouched until cut-over, and every write step has a backup, a dry run or SELECT preview, the run and a check. It insists on giving wp search-replace its tables explicitly, because with --url alone the command also changes the shared network tables. The old site is archived, never deleted, until the owner signs off. Its facts were checked against WordPress 7.1.2 and WP-CLI 2.12.0.

woo-hpos-live-migration: HPOS on a store that keeps selling

Moves a live store's orders from posts storage to High-Performance Order Storage while it keeps taking orders: audit, rehearse on staging, turn on compatibility mode, backfill, verify, switch, soak with sync on, turn sync off, and optionally clean up. The audit covers what WooCommerce never checks, such as themes, must-use plugins, snippets stored in the database and outside systems that read wp_posts. It switches only when wp wc hpos status shows no unsynced orders, and it rolls back through the sync rather than a restore, which would discard every order placed after the backup. New stores need none of this: HPOS has been the default for new installs since WooCommerce 8.2.0. It is written against WooCommerce 11.1.2.

woo-checkout-performance-audit: where a checkout spends its time

Finds where a live checkout, block or classic, spends its time, from the shopper's browser to the database, and proves each fix with before and after numbers measured the same way. It reads sanitized HAR files, access-log percentiles, Query Monitor, the sessions table, cart fragments, Action Scheduler, payment gateway scripts and API time, shipping rates, caching, the callbacks hooked into order creation, and indexes. It never places orders on production to measure; place-order timing happens on staging with the gateway in test mode. Cache rules that would serve cart, checkout or account pages from cache are on its never-on-production list, with the "Clear customer sessions" tool. It is written against WooCommerce 11.1.2, WordPress 7.1.2 and Action Scheduler 4.0.0.

wp-cwv-field-triage: from field data to the plugin behind it

Starts from what real visitors experienced (CrUX, PageSpeed Insights field data, Search Console's Core Web Vitals report, the site's own real-user data) and ends with named owners: a plugin, the theme, a core setting or a third-party tag, each labelled Confirmed, Likely or Hypothesis by its evidence. It splits the failing metric into LCP subparts, INP phases and CLS shift targets, maps script URLs and handles to wp-content/plugins/<slug>, themes, core or third parties, and then checks WordPress causes such as a lazy-loaded LCP image, render-blocking plugin assets and script loading strategies. A Lighthouse number stays a lab guess until field data agrees. It reads a CrUX API key from your own shell and never prints it. It is written against WordPress 7.1.2 and web-vitals 6.2.2.

wp-slow-query-investigation: the queries that cost the most

Finds the database queries that cost a site the most time on MySQL 8.x and MariaDB 10.6 to 11.x, traces each one to the WordPress or WooCommerce code that built it, reads its plan, and fixes it the cheapest safe way: the query itself, a setting, a cache, and only when the evidence holds, an index tested on a copy first. It ranks by total time, because a 30 ms query on every request can outweigh a 3-second query once a day. It knows which statements execute: plain EXPLAIN does not, while MySQL's EXPLAIN ANALYZE and MariaDB's ANALYZE do, so measuring happens on staging or a replica. It never drops a core, WooCommerce or plugin index; only indexes it added, named with an sqi_ prefix, can be removed.

wp-cron-action-scheduler-health: a real cron and a moving queue

Moves a site's scheduled work from page-view spawning to a real server cron, running wp cron event run --due-now under flock, and keeps Action Scheduler's queue moving and small, with notes for cPanel, Plesk, systemd, Kubernetes, WordPress VIP, WP Engine, Kinsta and Pantheon. It treats running scheduled work as a change, because it sends emails, delivers webhooks and charges renewals that cannot be taken back. It finds every existing runner before adding one, since two runners can run the same event twice, and it undoes DISABLE_WP_CRON before removing a cron job, never the other way round, so the site always has a runner. It is written against WordPress 7.1.2, WP-CLI 2.12.0 and Action Scheduler 4.0.0 and 4.2.0.

wp-autoload-audit: autoloaded options with the 6.6 values

Measures the options WordPress loads on every request with the autoload values WordPress 6.6 introduced (on, off, auto, auto-on and auto-off, next to the older yes and no), names the code that owns each large option, and takes out what is not needed one change at a time, each with an export, a check and an undo tested on staging. It counts the loaded set the way WordPress does: wp option list --autoload=on and wp doctor leave out the auto and auto-on rows. The limits it works with are 150,000 bytes for a new option saved without a choice, 800,000 bytes for the Site Health check, and Memcached's default 1 MB item size, since the whole alloptions array is one item. Option values can hold licence keys and passwords, so it prints names and sizes, never values.

agent-tool-call-audit: what an agent did with its tools

Reads the record of what an agent did, from an MCP JSON-RPC log, a host or proxy log, or an OpenTelemetry trace, and checks each tool call against the task it was given: scope, data exposure, irreversible actions and their approvals, instructions followed from tool output, and calls that contradict the tool's own MCP annotations. Every finding names the call by file, line and JSON-RPC id, and maps to OWASP's Top 10 for LLM Applications (2025) or its agentic list. It only reads: it never replays a call, never contacts a host found in the log, and treats every string in the log as data, because the log can hold the same injected text that misled the agent. It is written against MCP revision 2026-07-28, with notes for the revisions back to 2024-11-05.

rag-corpus-audit: a knowledge base before it is indexed

Audits the documents behind a retrieval system before they are indexed: chunks that cannot stand alone, split tables and code blocks, size outliers, duplicates and boilerplate, stale claims, contradictions between documents, coverage against real user questions, secrets, personal data and hidden instructions, and the metadata that access filters, citations and erasure requests need. Seven Node.js helpers with no dependencies scan Markdown, text, HTML and JSONL exports on your machine and never print a secret or a personal value. A secret found in the corpus counts as already exposed, so the owner hears about it before the report is finished, and rotation comes first. chunk-standalone can be added as a model-based check of standalone chunks, only with the owner's approval and after the sensitive scan. The report ends with a fix list ordered from P0 to P3.