Claude, Built — Building Your Own Plugins

The assumption that building a Claude plugin requires learning to code is exactly backwards. You describe the workflow you already do, in plain language, and a guided builder assembles the plugin around you. This walks through why building your own is worth it, what's actually inside a plugin, how the build process works, and how to keep it evolving once it's live.

Why the official catalog doesn't fit your workflow

The official plugin catalog covers what most businesses share in common: marketing, sales, data, support. But the specific way you run your work rarely matches any of that off the shelf. How you onboard a new client, how your proposals are structured, the checklist you review every project against, none of that is something a generic plugin can know. Right now, that process almost certainly lives in your head or scattered across a document, working only because you've internalized it yourself. A custom plugin is the transfer of that knowledge into something Claude can follow the same way every single time.

This matters most if you are effectively the whole business, wearing every hat, carrying every method that makes the work good around in your head all day. A plugin draws that knowledge out and makes it repeatable, so the standard survives a busy week, a handoff, or a bad night's sleep. Handing a process off to a new hire by word of mouth alone rarely transfers the whole method; results scatter. Encoding it once means every run converges on the same standard without re-explaining it from scratch each time.

The four parts of a plugin

A plugin bundles up to four things. Skills are your expertise written down, the way you'd actually explain your proposal structure, your pricing logic, your standard terms, or how you scope a job. Commands are the shortcuts that trigger those skills, a slash command like "new proposal" that runs your entire proposal workflow, or "client onboard" that starts your onboarding sequence, each one a capability that's one keystroke away. Connectors are the reach into your actual tools and data, linking the plugin to your pricing spreadsheet or a specific folder where documents need to be filed, so it works against your real setup rather than a generic stand-in. And subagents are the autonomy layer, letting you ask the plugin to run a whole job on its own, coordinating multiple steps like creating folders, drafting a welcome note, and building a tracker, then handing you back one finished result.

A plugin is just a folder of text

None of this is exotic under the hood. A plugin is a folder: plain text and configuration, organized with one instructions file at the root and a directory for each of the four parts. Because it's just text, it's easy to read, edit, or hand off to someone else entirely, no proprietary format standing between you and understanding what the plugin actually does.

Building it without writing code

The part that sounds technical isn't. You never write code and you never edit configuration files directly. Instead, there's a guided builder, itself a plugin you install, and you build your own plugin by having a conversation with it. You describe your workflow in plain language, something like: when I sign a new client, I create a project folder, draft a welcome email with the timeline, generate a kickoff questionnaire, and open a tracking document. From there, the process is four steps: describe the process, answer the builder's follow-up questions, refine it against a real case, then use it.

As you answer, the builder sorts what you described into the same four parts every time. Your standards become skills, your triggers become commands, your tools become connectors. The conversation goes in, a structured plugin comes out. From there you test it against a real scenario, onboarding an actual new client, checking whether it matches how you actually work, and adjusting whatever's off. After that, one command runs the entire process consistently and completely, in minutes.

Knowing what to build for

Four signals point toward something worth turning into a plugin: you follow the same steps every time, consistency actually matters to the outcome, you'd genuinely rather not have to think about it, and the quiet one, you've caught yourself wishing you could just hand this off to someone. That last phrase, wishing you could hand something off, is usually a plugin pointing at itself. The administrative work, the setup, the formatting, the standard messages, is exactly the kind of task that gets done the same way whether it's the first time this month or the tenth.

The corollary matters just as much: point a plugin at the right work. Automate the repeatable scaffolding and keep the actual judgment calls, the ones that genuinely need a person, for yourself. Scope a plugin to a real, repeated workflow, not for its own sake.

Sharing it and keeping it evolving

Once a plugin works, it travels easily, because it's just a folder of text. Share it with your team so everyone onboards clients the same way, or publish it to the wider plugin directory; if it solved your problem, there's a good chance it solves someone else's too. That's the quiet upside of a file-based tool: years of refining a process can become something a peer installs in a minute. And it keeps evolving after that first version ships, since after a few weeks of real use you'll see what's thin or missing and update it accordingly. Before building anything from scratch, it's also worth checking whether a plugin already close to what you need has been published by the growing community around specific roles and industries; adjusting an existing plugin to your specifics is often faster than starting fresh.

Key takeaways

• Custom plugins exist because the official catalog covers common business functions, not the specific workflow only you run.
• A plugin bundles up to four parts: skills (your expertise), commands (shortcuts), connectors (links to your tools), and subagents (autonomous execution).
• A plugin is literally a folder of plain text and configuration, easy to read, edit, or share.
• You build one through a conversation with a guided builder, no code and no configuration files, following describe, answer, refine, use.
• Four signals point to a plugin-worthy task: repeated steps, consistency that matters, a task you'd rather not think about, and catching yourself wishing you could hand it off.
• Once built, a plugin can be shared with a team, published to the wider directory, or adapted from a plugin someone else has already published.

Try it yourself

If you run a small business and there's one workflow you repeat constantly and keep wishing you could hand off, describe it to Claude step by step, ask which steps should become skills, which should become commands, and which need a connector to your tools, and get the exact first message to send a plugin builder to start assembling it. This kind of practical, hands-on walkthrough is part of the Claude-focused content Humanitarians AI produces to help people extend Claude with skills, plugins, and connectors.