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: