I Built a Tool That Does My Job (And I'm Giving It Away for Free)
Last month I caught myself explaining how to set up Kibana plugin authentication for the fourth time. Same patterns. Same mistakes the other developer was about to make. Same "oh wait, you also need to handle multi-tenancy" moment 20 minutes in.
I thought: what if I just... packaged everything I know into something reusable?
So I built a Claude Code plugin for Kibana development. It's on GitHub. It's free. And honestly, I'm not sure if this was smart or if I just automated myself out of a job.
Here's the story.
The Problem Nobody Talks About
Try Googling "how to build a Kibana external plugin."
Go ahead. I'll wait.
You'll find Elastic's official docs (sparse), a deprecated Yeoman generator from 2018, and a bunch of Stack Overflow posts from people who gave up. That's basically it.
When I started building Kibana plugins at UNIBERG, my main learning resource was... reading Kibana's source code. The actual Kibana repo. 200,000+ files. Searching for patterns. Hoping the internal plugin I was looking at was doing things the "right" way and not some legacy hack that hadn't been cleaned up yet.
There's no tutorial. No course. No "Kibana Plugin Development for Dummies." You just figure it out.
Which is fine — I actually enjoy that kind of thing. But after 6+ years of figuring it out, I had a lot of knowledge sitting in my head (and scattered across about 40 different notes.md files) that could save someone months of pain.
Why a Claude Code Plugin?
I'd been using Claude Code for a while. One day I looked at the plugin docs and realized the structure was weirdly similar to what I already knew from Kibana plugins. Manifest file. Directory structure. Configuration. Except way simpler.
Claude Code plugins are basically: a JSON manifest, some markdown files for commands/skills/agents, and that's it. No compiled code. No build step.
My first thought: "I could put my entire Kibana knowledge base into a skill file and Claude would just... know it."
My second thought: "That can't actually work."
It did.
What I Actually Built
Started on a Saturday afternoon. Figured it'd take a couple hours.
It took two full days. And then another week of adding stuff because I kept thinking "oh, and this pattern too."
The plugin has:
10 slash commands — /scaffold generates a full plugin skeleton (server + public + types + manifest). /route creates server routes with proper @kbn/config-schema validation. /component generates EUI-based React components. /security sets up RBAC. And a few more.
6 specialized agents — an architect that reviews your plugin structure, a security auditor that checks for auth bypass and data leaks, a migration assistant for version upgrades.
1 massive skill file — around 400 lines of concentrated Kibana plugin knowledge. Plugin lifecycle. Route patterns. ES client usage. EUI components. Auth middleware. Testing patterns. Common pitfalls.
The skill file is the part I'm most proud of. And also the part that took the longest because I kept going "wait, I forgot about saved object migrations" and adding another section.
The Stuff That Was Hard to Get Right
Route authentication patterns.
This sounds boring. It is boring. But if you get it wrong, you leak user data across tenants. I've seen it happen. I've caused it to happen. The plugin bakes security checks into every generated route by default, because I learned the hard way that "I'll add auth later" means "I'll discover the auth bug in production."
Every route the /route command generates starts with:
const user = security.authc.getCurrentUser(request);
if (!user) return response.forbidden();
Boring. But I have scars from the time it wasn't there.
EUI component patterns.
Elastic UI has maybe 80+ components. Some are well-documented. Some aren't. Some have props that don't do what you'd think. I spent a full day once debugging why an EuiBasicTable wasn't rendering pagination correctly — turned out I was passing totalItemCount as a string instead of a number. TypeScript didn't catch it because the prop type was any.
The /component command generates components that already handle the edge cases I've hit. Dark mode compatibility. Responsive layouts. Loading states. Error boundaries. Stuff I used to forget and then fix in production.
Elasticsearch client integration.
The Kibana ES client isn't the same as the regular @elastic/elasticsearch client. It's wrapped. It has different error types. It handles auth differently. And it changes between Kibana minor versions in ways that aren't always documented.
I wrote a service layer pattern into the skill that handles type coercion, error mapping, and defensive defaults for every ES response. It's about 200 lines of code I never want to look at again. But every plugin I build copies it.
The Part Where I Question Everything
Here's what's weird about open-sourcing your expertise: someone could install this plugin and skip years of learning.
The auth patterns I figured out through a security audit that almost gave me a heart attack? It's in there.
The EUI dark mode bug that cost me a full Wednesday? Handled automatically.
The Elasticsearch response transformation layer I wrote at 2 AM because production data had timestamps in three different formats? Built into the skill.
Am I devaluing my own experience by giving it away?
Maybe. Probably not. The plugin can scaffold code and teach patterns, but it can't debug your specific production issue at 11 PM on a Thursday. It can't look at your data model and say "this won't scale past 100k records." It can't sit in a meeting and explain to a product manager why multi-tenancy takes three weeks, not three days.
Tools don't replace experience. They just make the boring parts faster.
At least that's what I tell myself.
What Actually Happens When You Use It
Here's a real example. You type:
/scaffold
Claude asks what you're building. You say "user management plugin with RBAC."
Two minutes later you have:
- Plugin manifest with correct Kibana version targeting
- Server-side setup with route registration
- Public-side app mounting with React
- TypeScript types for your domain
- Basic EUI page layout with navigation
- Security configuration with feature privileges
- A working
kibana.jsonc
Before this plugin, that setup took me about 4 hours. And I'd still forget something — usually the kibana.jsonc configuration, because that file is easy to get wrong and hard to debug when you do.
Things That Are Still Missing
I'll be honest about what's not in there yet:
State management patterns — I have opinions (use React context + custom hooks, not Redux) but haven't formalized them into commands yet.
Logging and monitoring — This is important for production plugins and I keep putting it off because it's not the fun part.
Inter-plugin dependencies — This is genuinely complicated. Kibana's dependency injection system between plugins is powerful but also confusing. I've been working with it for years and still double-check the docs every time.
Real-time data patterns — WebSocket-style updates through Kibana. I've done it, but the patterns aren't clean enough to template yet.
The Open Source Anxiety
Publishing it was uncomfortable.
Not because of the code — the code is fine. But because it's basically my brain in a markdown file. Every pattern is something I learned through mistakes. Every anti-pattern check in the security agent is a bug I caused or caught.
What if someone finds something wrong? What if a pattern that works in my use cases breaks in theirs? What if an Elastic engineer looks at it and says "that's not how we do it internally"?
Then... they'll open an issue. And I'll fix it. Or learn something new.
That's kind of the point.
How to Actually Use It
If you're building Kibana plugins (or thinking about it):
/plugin marketplace add ch-bas/kibana-plugin-helper
/plugin install kibana-plugin-helper@kibana-plugin-helper
Then try /scaffold and see what happens.
If you're not building Kibana plugins — honestly, most people aren't — this post is really about something else: packaging your hard-won knowledge into something others can use.
Whatever your niche is, you have patterns and lessons that could save someone else months. The format doesn't matter. A plugin, a blog post, a markdown file in a GitHub repo. The point is getting it out of your head and into a place where it helps.
I just happened to pick a Claude Code plugin because the structure was familiar and I'm a developer, so of course I over-engineered it.
What I'd Like to Know
If you're doing Kibana plugin development: what's the thing you wish someone had told you on day one? I might add it.
If you've open-sourced your expertise before: did it help your career or hurt it? Genuinely curious.
And if you've used Claude Code plugins: are people actually discovering them through marketplaces, or is it still mostly word of mouth?
Drop your answers. I read everything.
GitHub: github.com/ch-bas/kibana-plugin-helper
License: MIT (do whatever you want with it)
Top comments (0)