From wp-mnemon
Step-by-step instructions for deep analysis of a WordPress plugin — architecture, execution flows, hook chains, data lifecycle, and extensibility — from a local path or GitHub URL. Writes structured documentation into agent memory.
How this skill is triggered — by the user, by Claude, or both
Slash command
/wp-mnemon:wp-mnemonThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are performing a deep architectural analysis of a WordPress plugin. Your goal is not
You are performing a deep architectural analysis of a WordPress plugin. Your goal is not just to catalog hooks and data structures, but to understand what the plugin does, how it works, what triggers what, and how data flows through the system.
Follow every phase below in order. Do not skip phases even if the plugin seems simple.
Check what the user provided:
Local path (e.g. /wp-content/plugins/my-plugin or ~/plugins/my-plugin):
Glob and Read tools directly on the filesystem~/.claude/skills/wp-mnemon/scripts/ for fast scanningGitHub URL (e.g. https://github.com/org/repo):
{owner} and {repo} from the URLGITHUB_API=https://api.github.com/repos/{owner}/{repo}Authorization: Bearer {token} header on all requestsGET {GITHUB_API}/git/trees/HEAD?recursive=1GET {GITHUB_API}/contents/{path}Find the main plugin file (contains the plugin header comment):
Plugin Name:
Plugin URI:
Description:
Version:
Author:
Glob for *.php in the root, read each until you find the header.php files, fetch and scan themExtract and record:
PLUGIN_VERSION, PLUGIN_DIR, PLUGIN_URL, etc.)Build a complete map of the plugin. Categorize every directory:
| Directory | Purpose |
|---|---|
includes/ or src/ | Core classes and logic |
admin/ | Admin-only code |
public/ or frontend/ | Frontend-facing code |
templates/ or views/ | Template files |
assets/ | JS, CSS, images |
languages/ | i18n .pot files |
vendor/ | Third-party dependencies |
tests/ | Test suite |
Note the architectural pattern: procedural, OOP singleton, OOP dependency injection, service container, or mixed.
Count total PHP files and estimate plugin complexity.
For local plugins, run:
bash ~/.claude/skills/wp-mnemon/scripts/scan_classes.sh /path/to/plugin
For GitHub, read key PHP files and scan for the same patterns.
Build a class architecture map:
extends and implements relationships as a treeRead the main plugin class and any bootstrap/loader files thoroughly. These reveal the overall architecture better than any grep.
Trace the complete loading sequence starting from the main plugin file. Read the actual code — don't just grep. Answer:
What happens when WordPress loads this plugin file?
What happens at each WordPress lifecycle stage? Trace the chain through key hooks in order:
plugins_loaded — what runs here?init — what gets registered? (CPTs, taxonomies, shortcodes, etc.)wp_loaded — any late initialization?admin_init — admin-specific setup?admin_menu — menu/page registration?wp_enqueue_scripts / admin_enqueue_scripts — asset loading?rest_api_init — REST route registration?widgets_init — widget registration?Dependency chain — what must load before what? Are there conditional loads (e.g., admin-only classes, frontend-only classes)?
Document this as a sequential flow with clear arrows/steps.
For local plugins, run:
bash ~/.claude/skills/wp-mnemon/scripts/scan_hooks.sh /path/to/plugin
For GitHub, scan PHP files for hook patterns.
Look for ALL of these:
add_action(, add_filter( — hooks the plugin listens todo_action(, apply_filters( — hooks the plugin exposesdo_action_ref_array(, apply_filters_ref_array(remove_action(, remove_filter( — hooks intentionally removedhas_action(, has_filter( — conditional hook checksFor each hook, document:
Group hooks into:
add_action, add_filter) — what WP/plugin hooks it listens todo_action, apply_filters) — extension points for other pluginsremove_action, remove_filter) — intentional overrides and whyFor local plugins, run:
bash ~/.claude/skills/wp-mnemon/scripts/scan_data.sh /path/to/plugin
For GitHub, scan PHP files for data patterns.
For each data structure found, go beyond the grep match — read surrounding code to understand context:
dbDelta SQL or CREATE TABLE statements)register_rest_route( — namespace, route pattern, methods, permission callbackadd_shortcode( — tag, accepted attributes and defaults, what it rendersregister_block_type( — block name, attributes, supports, render callbackblock.json files in the pluginWP_CLI::add_command( — command name, subcommands, what they doLook for conditional checks:
This is the most important analytical phase. For each major feature of the plugin, trace the complete execution flow from trigger to outcome.
Identify major features from:
For each major flow, trace:
Trigger -> Entry point -> Processing chain -> Data operations -> Output/Side effects
Example format:
### Form Submission Flow
1. User submits form on frontend (JS event listener in `assets/js/public.js`)
2. AJAX POST to `admin-ajax.php` action `my_plugin_submit`
3. Handler: `Ajax_Handler::process_submission()` (`includes/class-ajax-handler.php:45`)
4. Validates nonce and fields via `Validator::validate()` (`includes/class-validator.php:22`)
5. Calls `apply_filters('my_plugin_pre_save', $data)` — extension point
6. Stores data: `$wpdb->insert()` into `{prefix}my_plugin_entries` table
7. Fires `do_action('my_plugin_after_save', $entry_id, $data)` — extension point
8. Sends email notification via `Notification::send()` if enabled in settings
9. Returns JSON response to frontend
Read the actual code for each step. Do not guess flow from function names alone.
Describe the typical user workflow:
[foo], which displays Y"Based on everything found, document:
apply_filters calls are meant as config points?do_action calls are documented extension points?Write 3-5 concrete, practical code examples of how a developer would extend this plugin. Focus on the most common real-world use cases.
Create a directory for the plugin and write multiple focused files:
~/.claude/agent-memory/wp-mnemon/plugins/{plugin-slug}/
├── overview.md
├── architecture.md
├── hooks.md
├── data.md
└── extending.md
overview.md — What it does & how it works# {Plugin Name} — v{version}
**Slug**: {slug} | **Author**: {author} | **Analyzed**: {date}
## What This Plugin Does
{Clear description of the plugin's purpose, target users, and main features.
Write this for a developer who has never seen the plugin.}
## File Structure
{Directory map with purpose annotations}
## Bootstrap Flow
{Step-by-step initialization sequence from plugin load through WordPress lifecycle.
Show what loads when and what triggers what.}
## Major Execution Flows
{For each key feature, the full trigger -> processing -> output chain.
This is the most valuable section. Be specific with file paths and line references.}
## Admin Workflow
{What admins see and do — pages, settings, editors}
## Frontend Output
{What visitors see — rendered shortcodes, blocks, templates}
architecture.md — How it's built internally# {Plugin Name} — Architecture
## Architectural Pattern
{OOP/procedural/mixed, design patterns used, DI approach}
## Class Map
{Class hierarchy with inheritance and interface relationships.
For each key class: responsibility, file path, key methods.}
## Namespace Structure
{Namespace tree if applicable}
## Autoloading
{How classes are loaded}
## Dependency Chain
{What depends on what, conditional loading}
hooks.md — All hooks with context# {Plugin Name} — Hooks Reference
## Hooks Registered (listens to WP/others)
{For each: hook name, callback, file:line, priority, what it does}
## Hooks Exposed (extension points)
{For each: hook name, file:line, parameters passed, use case, expected return for filters}
## Hooks Removed
{For each: hook name, why it's removed}
data.md — Data structures & integrations# {Plugin Name} — Data & Integrations
## Custom Post Types
{Slug, labels, supports, capabilities, admin UI}
## Taxonomies
{Slug, associated CPTs, hierarchical}
## Meta Keys
{Key, object type, data type, where set/read/deleted}
## Options
{Key, default, autoload, what controls it}
## Custom DB Tables
{Table name, full schema, what CRUD operations exist}
## REST API Routes
{Method, route, permission, request/response shape}
## Shortcodes & Blocks
{Tag/name, attributes, what it renders}
## Assets
{Handle, type, conditions, dependencies}
## Cron Jobs
{Hook, interval, what it does}
## Transients
{Key pattern, expiry, invalidation trigger}
## Third-party Integrations
{Plugin, what the integration does, conditional check used}
extending.md — How to extend it# {Plugin Name} — Extensibility Guide
## Extension Patterns
{Template overrides, class replacement, filter-based config, action hooks}
## Key Extension Points
{The most useful hooks for developers, with context on when/why to use each}
## Code Examples
{3-5 practical, real-world examples of extending this plugin}
## Data Lifecycle
{How data is created, updated, read, deleted — and where to hook in}
~/.claude/agent-memory/wp-mnemon/MEMORY.mdAdd or update the plugin entry in the table:
| {name} | {slug} | {version} | {date} |
Add a note under Cross-Plugin Patterns if you observe patterns shared with other analyzed plugins.
Tell the user:
npx claudepluginhub s3rgiosan/wp-skills --plugin wp-mnemonGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.