How to Make a Claude Plugin for a Repeatable Workflow

A Claude plugin is a packaged workflow: a set of instructions, tool definitions and context that Claude can load to handle a specific repeatable task. Instead of explaining the same task requirements every session, you write them once, package them, and load the plugin when you need that workflow. Tools like fenbs keep the approved instructions and the work records the plugin produces, so both the definition and the results are in one reviewable place.

The practical form this takes depends on the Claude interface you use. In Claude Code, a plugin is typically a CLAUDE.md section or a slash command definition. In Claude API clients, it is a system prompt and tool configuration. In both cases, the goal is the same: one definition that makes the workflow repeatable without re-explaining it.

What makes a task worth packaging as a plugin

A task is worth packaging when it meets two criteria: you run it often enough that re-explaining it is a real cost, and it is stable enough that one definition covers most runs without frequent editing.

Good candidates include code review workflows with a fixed checklist, documentation generation from a specific template, test generation for a particular pattern, and data transformation tasks with consistent input and output formats. Tasks that change significantly from run to run, or that require nuanced judgment at every step, are harder to package well.

For a broader view of how plugins fit into the Claude Code extension model, see the Claude Code plugins guide and the comparison of plugins, skills and subagents.

How to define the plugin

A plugin definition has three parts: the instructions, the tools and the expected output.

Instructions say what the plugin does, in what order and under what constraints. Write them as imperatives, not descriptions. "Check each function for missing error handling before reporting any style issues" is better than "the plugin reviews code." The more specific the instructions, the more consistent the output.

Tools say which capabilities the plugin may use. If the workflow involves reading files and running tests but not writing to external APIs, list only those. Minimum tool access means fewer unexpected actions and a smaller blast radius if something goes wrong.

Expected output says what a completed plugin run should produce: a list of findings, a modified file, a summary document, a set of new tasks. Clear expected output makes it easier to verify whether the run succeeded.

How to test the plugin before sharing it

Test the plugin on at least two real tasks before treating it as ready. Use tasks that are different from the one you used to write the definition. A definition written around one specific case often has implicit assumptions that break on a second case.

For each test, check whether the output matches the expected output. If the plugin produces the right result for the wrong reasons, correct the instructions. If it produces a wrong result that looks plausible, that is the most important case to fix before others use it.

Also test the edge cases: what happens when the input is empty, when a required file is missing, when the task scope is ambiguous. A plugin that fails gracefully and reports a clear error is more useful than one that fails silently.

Approving and versioning the plugin

Before sharing a plugin with teammates, have someone else review the instructions. Fresh eyes catch assumptions the author missed. Approval means someone has run it, checked the output and confirmed it is ready for wider use.

Keep the approved definition in version control. When you update it, note what changed and why. A plugin that changes silently confuses the people who use it and makes it hard to debug unexpected output. Treat plugin definition changes as decisions: record them where teammates can find the reasoning.

When a plugin is not the right solution

A plugin adds overhead: it needs documentation, testing, version management and a review process. For a task you run once a month, typing a slightly longer prompt each time may be faster than maintaining a plugin definition. Reserve plugins for tasks you run often enough that the consistency and time savings justify the maintenance.

A plugin also cannot adapt to unusual inputs the way a direct conversation can. If a task requires judgment at nearly every step, packaging it as a plugin may produce a definition so hedged with conditions that it is harder to use than no plugin at all. Start with a well-written prompt before deciding it needs to become a plugin.

How to do this with fenbs

1. Create a free account and add a project for the plugin or for the codebase it serves. Write the approval criteria and any standing rules as Decisions and rules.
2. Add the plugin instructions to fenbs as a Skills and prompts entry. Any connected Claude Code session can read the current approved definition without requiring a copy in every configuration file.
3. Connect Claude Code over MCP from Integrations. Run the plugin and ask it to read the project context first. It sees the approved instructions and any rules before it starts.
4. After each plugin run, update the task with what was produced and any deviations from expected output. Record significant findings as Lessons learned.
5. When you update the plugin definition, record the change as a Decisions and rules entry. Teammates can look up why the behavior changed without asking you.