wp-plugin-hooks

WordPress plugin: custom hooks (the ones YOU emit)

This skill is about hooks the plugin emits as its public extension surface — the actions and filters other developers wire into to modify or react to the plugin's behavior. Using core WP hooks (init, wp_enqueue_scripts, the_content, etc.) is basic WP and out of scope; designing your own hooks well is what separates a plugin people can extend from one they have to fork.

A custom hook is part of your plugin's API contract. Once a third party builds on it, breaking the signature in a minor release is a backwards-incompatibility bug — same as renaming a public PHP method.

When to use this skill

Trigger when ANY of the following is true:

• Adding a do_action or apply_filters call that other plugins / themes will hook into.
• Reviewing a PR that introduces or modifies a custom hook.
• Evolving a hook signature across plugin versions (adding parameters, renaming, deprecating).
• Removing or renaming an existing hook — read the deprecation section before doing this.
• The diff contains: do_action, apply_filters, apply_filters_deprecated, do_action_deprecated, or a docblock starting with Fires / Filters above a hook call.

Action vs filter — pick by semantics

Both are events your code emits during execution. The semantic difference:

Concrete examples:

// ACTION — "the user just submitted the form"; downstream side effects
do_action( 'myplugin/form_submitted', $form_id, $submission );
// Listeners: send Slack notification, log to audit table, dispatch webhook.

// FILTER — "here's the response message; anyone want to override?"
$message = apply_filters( 'myplugin/response_message', $default_message, $form_id );
// Listeners: replace the message based on form_id, append "(internal)" prefix.