What /plugin-authoring Unlocks in Claude Code: Plugins From a Sentence

Turning it on, briefly

The skill is gated behind CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 on Claude Code 2.1.260 or later. In the desktop app that means one block in ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_ENABLE_FUNCTION_HOOKS": "1"
  }
}

Type / in a session and plugin-authoring is in the list. The full setup, the plugin folder layout, and a tested plugin to copy are in the secret redactor install guide. The background on hooks themselves is in the complete hooks guide.

What the skill is

Inside the 2.1.260 binary the skill describes itself as the way to "write or debug a Claude Code plugin made of function hooks." It is not a code generator bolted on the side; it is an orientation note that loads into the session before Claude writes a plugin, and it tells Claude four things: what a function hook plugin is, where the exact contract for the running build is written down, how to run a plugin under development, and where the engine reports what it refused. Ray Amjad's September 2026 walkthrough shows the effect: one sentence describing a transcript secret redactor produced a working 300-line plugin, and a request for a deployment status row produced a live panel beneath the prompt with a hide button.

The contract the skill hands Claude is short enough to state:

• →A plugin is a folder with a manifest. Its function hooks live in one module named by hooks/hooks.json under modules, exporting register(on, options).
• →Every hook has the shape ($, e, next). $ is the engine interface, e is the event's input as a plain value, and next(e) continues to the other plugins and then the engine. Returning without calling next answers for itself; calling next with a changed event rewrites what the rest of the chain sees.
• →The module runs in an environment of its own, with no DOM and no Node. Everything outside it is reached through $. JSX is available with h as the factory.
• →The types are the reference. /plugin-types writes them from the running build, and the skill tells Claude not to guess at an event's input or a method on $.

What it unlocks

The events cover tool calls and their descriptions, the prompt as submitted, the system prompt's sections, what the interface draws, the turn's start and completion, the session's start, skills, and subagents. The engine interface adds the verbs. Together they make the following buildable from a description, and several were built on camera in the video or verified by community testers on the proposal thread.

Six prompts to try

Each of these is the whole message. The skill prefers an outcome and a constraint over an implementation. Asking it to interview first, as the video does for the deployment row, produces better plugins for anything with a visual component.

/plugin-authoring Make a plugin that blocks any Bash command which deletes a Supabase project or branch, drops a table, or force pushes without a lease. Deny with a one-line reason the model can act on. Log every deny with $.ui.log.

/plugin-authoring Make a plugin that rewrites every Bash command starting with npm to use pnpm instead, and shows a toast the first time it does so in a session.

/plugin-authoring Make a plugin that caches WebFetch results in $.store for one hour, keyed by URL, and answers the tool call from the cache when a fresh copy exists. Include a way to bypass the cache when the prompt says "refetch".

/plugin-authoring Interview me first, then build a plugin that shows the current Vercel deployment for this repo in a row under the prompt: stage, elapsed time, and a button to hide the row. Keep finished deploys visible for an hour.

/plugin-authoring Make a plugin that asks me with $.ui.ask whether to split a file into smaller modules whenever an Edit or Write targets a file longer than 1,000 lines, and passes the edit through untouched if I say no.

/plugin-authoring On turn.complete, send the turn's answer to a Haiku model for a two sentence summary and speak it with $.audio.speak. Skip turns shorter than 200 characters.

The video's closing suggestion is the one with the most leverage: point the skill at an existing CLAUDE.md and ask which of its rules could become hooks. A rule that lives in a hook no longer depends on the model's attention.

The working loop

1. Describe the outcome with /plugin-authoring. Claude reads the skill, runs /plugin-types if the declarations are stale, and writes the folder.
2. Validate with the bundled binary: claude plugin validate <folder> --json. The notes list what the module hooks and which $ calls it makes, which is the quickest check that the engine sees what was meant.
3. Load with /reload-plugins in the session, or claude --plugin-dir <folder> in a terminal, where saving a file reloads the module.
4. Read the debug log when nothing seems to happen. Anthropic's note is blunt that a plugin that seems to do nothing has usually been told why there: a module it did not load, a hook that threw or overran its budget, a drawing that did not validate.
5. Share the folder through a git repository or a private marketplace once it holds. Older builds ignore the modules key, so the rest of the plugin still loads for teammates who have not turned the preview on.

FAQ