amElnagdy Skills

Review generated or changed production code before it ships, using Clean Code, SOLID, DRY, KISS, YAGNI, and LLM-specific failure-mode checks in any programming language. Best used reactively after an agent writes, edits, refactors, or fixes code, before presenting, committing, or merging the result. Use when the user asks "review this PR", "is this safe to merge?", "make this cleaner", "audit this code", "refactor this", "fix this bug", or after a coding agent produced implementation code. Can also guide writing when explicitly invoked before a risky edit. Invoke it on your own initiative the moment you finish writing, editing, or refactoring non-trivial production code, before presenting or committing — don't wait to be asked. DO NOT USE for factual/conceptual questions, CI/tooling config, git workflow, running/debugging tests, pure architecture discussion, prose writing, data analysis, or test-code review (use test-guard).

Review generated or changed documentation before it ships — READMEs, API references, docstrings, PHPDoc/JSDoc, changelogs, tutorials, and doc sites. Best used reactively after an agent writes or edits docs, after code changes documented behavior, or before publishing docs. Use when the user says 'review the docs', 'is this documentation accurate', 'update the docs', 'write a README', 'document this API', 'add a docstring', or 'add a changelog entry'. Core job: verify every referenced function, flag, endpoint, config key, and code sample against the source; catch docs-vs-code drift; strip filler and unverifiable claims. DO NOT USE for production code review (use clean-code-guard), test review (use test-guard), marketing copy or blog posts, prose style editing of non-technical writing, or documentation site theming.

Review generated or changed test code against universal testing rules before it ships. Best used reactively after an agent writes, edits, generates, or refactors tests, before presenting, committing, or merging them. Use for pytest (test_*.py, *_test.py), PHPUnit/Pest (*Test.php), Jest/Vitest (*.test.ts, *.spec.js), Go (*_test.go), files under tests/, __tests__/, or spec/, and review requests like 'write tests for X', 'add tests', 'test this', 'review these tests', or PR diffs containing tests. Can also guide test writing when explicitly invoked before the work. This skill is the quality gate that prevents AI-generated test bloat. DO NOT USE for production or implementation code review (use clean-code-guard), CI or test-runner configuration, running or debugging tests, or general architecture discussion.

Review generated or changed WooCommerce code — extensions, payment and shipping integrations, checkout customizations, and order/product logic — before it ships. Best used reactively after an agent writes, edits, or reviews code touching WooCommerce APIs: wc_get_order, wc_get_orders, wc_get_product, WC() cart or session, woocommerce_* hooks, Store API endpoints, payment gateways, order or product meta, HPOS, subscriptions, or bookings. Use on 'review this Woo plugin', 'is this HPOS compatible', or after tasks like 'write a WooCommerce extension', 'add a checkout field', 'hook into the order flow', or 'update stock'. Enforces HPOS-safe order access, CRUD over direct meta, feature-compatibility declarations, server-side checkout validation, money-handling discipline, and hooks over template overrides. DO NOT USE for WordPress code without WooCommerce APIs (use wp-guard), generic code review (use clean-code-guard), test review (use test-guard), or store configuration and admin-screen questions.

Review generated or changed WordPress code — plugins, themes, and blocks — before it ships. Best used reactively after an agent writes, edits, or reviews code touching WordPress APIs: add_action/add_filter, shortcodes, meta boxes, AJAX handlers, REST routes, WP_Query or $wpdb, widgets, or WP-CLI commands. Use on 'review this plugin', 'is this safe to ship', 'make this translatable', 'speed up this query', or after tasks like 'write a plugin' or 'add an endpoint/shortcode/meta box'. Enforces escaping and sanitization, nonces plus capability checks, prepared database queries, core-API-first development, translation-ready strings, and query/caching discipline. DO NOT USE for WooCommerce-specific order, product, or checkout logic (use woo-guard), non-WordPress PHP, generic code quality review (use clean-code-guard), test code review (use test-guard), server or hosting configuration, or conceptual WordPress questions.

>- Delegate a coding task to the Google Antigravity CLI (`agy`) as a background implementer, then review its diff and land it yourself. Use this whenever the user wants to hand implementation work to Antigravity or agy - phrasings like "have Antigravity do X", "delegate this to agy", "run it through agy", or "use Antigravity to implement/fix/refactor" - or wants to run a queue of coding tasks through agy while staying the reviewer. DO NOT USE for tasks small enough to do inline, or when the user wants the code written directly without delegating.

>- Delegate a coding task to a separate Claude Code CLI process or another Claude session as an implementer, then review its diff and land it yourself. Use only when the user explicitly asks to delegate implementation to Claude Code, another Claude session, or the `claude` CLI — for example, "have another Claude implement this", "delegate this to Claude Code", or "run this queue through a separate Claude session." Do not trigger merely because the current orchestrator is Claude, and do not use when the user asks the current Claude to implement directly without delegation.

>- Delegate a coding task to the OpenAI Codex CLI as a background implementer, then review its diff and land it yourself. Use this whenever the user wants to hand implementation work to Codex — phrasings like "have Codex do X", "delegate this to Codex", "run it through Codex", or "use Codex to implement/fix/refactor" — or to run a queue of coding tasks through Codex while staying the reviewer. Prefer it over a one-shot Codex forwarder (such as the codex-rescue agent) when the user will review the diff and commit it themselves. DO NOT USE for tasks small enough to do inline, or when the user wants the code written directly without delegating.

>- Delegate a coding task to the Cursor Agent CLI (`cursor-agent`) as a background implementer, then review its diff and land it yourself. Use this whenever the user wants to hand implementation work to Cursor — phrasings like "have Cursor implement X", "delegate this to Cursor", "run it through Cursor Agent", or "use Cursor to implement/fix/refactor" — or wants to run a queue of coding tasks through Cursor while staying the reviewer. DO NOT USE for tasks small enough to do inline, or when the user wants the code written directly without delegating.

>- Delegate a coding task to the Grok Build CLI as a background implementer, then review its diff and land it yourself. Use this whenever the user wants to hand implementation work to Grok — phrasings like "have Grok do X", "delegate this to Grok", "run it through Grok", "use Grok Build to implement/fix/refactor", or "have grok CLI do this" — or to run a queue of coding tasks through Grok while staying the reviewer. Prefer it when the user will review the diff and commit it themselves. DO NOT USE for tasks small enough to do inline, or when the user wants the code written directly without delegating.

>- Delegate a coding task to the Kimi Code CLI (`kimi`) as a background implementer, then review its diff and land it yourself. Use this whenever the user wants to hand implementation work to Kimi - phrasings like "have Kimi implement X", "delegate this to Kimi", "run it through Kimi Code", or "use Kimi to implement/fix/refactor" - or wants to run a queue of coding tasks through Kimi while staying the reviewer. DO NOT USE for tasks small enough to do inline, or when the user wants the code written directly without delegating.

>- Delegate a coding task to the OpenCode CLI as a background implementer, then review its diff and land it yourself. Use this whenever the user wants to hand implementation work to OpenCode — phrasings like "have OpenCode do X", "delegate this to OpenCode", "run it through OpenCode", or "use OpenCode to implement/fix/refactor" — or wants to run a queue of coding tasks through OpenCode while staying the reviewer. Prefer it when the user will review the diff and commit it themselves. DO NOT USE for tasks small enough to do inline, or when the user wants the code written directly without delegating.

>- Delegate a coding task to the Pi coding agent CLI (`pi`) as a background implementer, then review its diff and land it yourself. Use this whenever the user wants to delegate implementation work to Pi - phrasings like "have Pi implement X", "delegate this to pi", "run it through Pi", or "use pi to implement/fix/refactor" - or wants to run a queue of coding tasks through Pi while staying the reviewer. DO NOT USE for tasks small enough to do inline, or when the user wants the code written directly without delegating.

>- Delegate a coding task to the Qoder CLI (`qodercli`) as a background implementer, then review its diff and land it yourself. Use this whenever the user asks to have Qoder implement, fix, refactor, or run a queue of coding tasks while the orchestrator remains the reviewer. DO NOT USE for tasks small enough to do inline, or when the user wants code written directly without delegation.

>- Delegate a coding task to the Mistral Vibe CLI (`vibe`) as a background implementer, then review its diff and land it yourself. Use this whenever the user wants to hand implementation work to Vibe — phrasings like "have Vibe implement X", "delegate this to Vibe", "run it through Mistral Vibe", "use vibe to implement/fix/refactor" — or wants to run a queue of coding tasks through Vibe while staying the reviewer. DO NOT USE for tasks small enough to do inline, or when the user wants the code written directly without delegating.