If you’re managing a bunch of internal packages and the knowledge is spread across people’s heads, a web UI nobody enjoys using, and a wiki that’s perpetually outdated. Keeping track of what’s in each one, which version has that fix, what config rotates the earth by 45 degrees, what changed last week, these are not something you can just keep in your head. Or at least you need a few minutes to click around to get the info.
And it’s not just developers who need this information. Our support team fields questions from customers all day, everything from “what does this configuration option do?” to “will this plugin solve world hunger?” They shouldn’t have to tap a developer on the shoulder every time someone asks about a package detail.
So I thought: what if everyone could just ask Slack? Turns out, with a sprinkle of Claude magic, a working POC took about 3 hours.
Note: A lot of scenarios in this post are totally hypothetical and you will know when you read them 😀
The Problem
With 60+ packages, the mental overhead is real. For developers, you’re debugging something, you vaguely remember a fix landed in some payment package last month, but was it 3.1 or 3.2? The answers exist in the code itself! package manager has shippable code, composer.json has all the basic metadata, and git history has all commit history you need. But getting to them means switching context, leaving whatever you’re doing and clicking through to find and answer.
For support, it’s worse. A customer asks “does your checkout plugin support guest orders from across the world just from 1200 to 0200 in the morning ?” and the support team have two options: dig through documentation that may or may not be up to date, or ping a developer and wait. Neither is great. The developer gets interrupted, the customer gets delayed, and the support agent feels stuck in the middle.
Nobody has all the packages on top of their head and nobody should have to.
Summing up the problems:
- Docs are always outdated, almost as soon as the next commit is added in.
- There is no good way for support to understand the workings except reading through changelog and manuals to figure out the workings.
- Context switching for developers is not mentioned much but it is always a problem.
The Idea
We use Slack for daily comms, what if someone could just @mention a bot in Slack and ask “what does the enableGuestCheckout config do in the checkout plugin?” and get an answer right there in the thread? Someone notices a sentry error log ? paste it in slack and the bot tells where the problem probably is. A support agent asks “does this plugin handle multi-currency?” and gets an answer based on the actual source code not a wiki page someone forgot to update six months ago.
I gave myself an afternoon to see if it was even possible. It was.
3 Hours to a Working POC
The trick is that you don’t need to build a search engine or a fancy UI. You define a handful of tools: search packages, get metadata, list versions, read source files, compare releases and let Claude figure out which ones to call and in what order.
Ask “which of our packages is not Shopware 6.7 ready yet?” and the bot chains together multiple lookups on its own. Ask “What does a config option that was built 5 years ago with zero context around it do?” and it reads the actual config files and writes back what it does. That orchestration would’ve taken weeks to build manually. With tool-use, it just works.
The bot always queries against the latest package versions or the version you refer to, and there’s a caching layer so repeated lookups are fast. Support can ask the same question five times in a day and it doesn’t hammer the registry. The package archive is already extracted and cached locally. When a new version gets published, the cache refreshes automatically.
For Slack connectivity I chose Socket Mode to keep things simple; no public URL needed, no reverse proxy and no SSL cert setup. The bot just opens an outbound connection. That alone saved a couple hours.
Why This Project Matters More for “Non-Devs”
This is where it gets interesting. Developers can navigate a registry, check commits understand the changelogs. It’s annoying, but they know how. Support and Product Managers can’t and shouldn’t have to go through. They deal with customer questions that range from very specific (“what does this setting do?”) to very broad (“can your plugin handle our use case?”). The bot lets them have an interactive conversation about a package without needing to understand Composer, JSON files, or PHP code.
They ask in plain English, the bot reads the source, and answers in plain English. If the first answer isn’t enough, they ask a follow-up in the same thread. The bot remembers the context. It’s like having a developer on standby, except the developer doesn’t get interrupted and the answer comes back in seconds.
And because it’s always reading from the latest published version, support never accidentally gives a customer outdated information. That alone is worth it.
Not Without Its Rough Edges – The Tricky Parts
Thread memory. Slack conversations have follow-ups. “What about version 2.0?” only makes sense if the bot remembers you were asking about a specific package two messages ago. I store conversation history per thread, but it grows fast.
- The Fix: when history gets too long, a smaller model summarizes the older messages while keeping the last few exchanges intact.
Thread context. Slack conversation can quickly diverge and change directions where 5 different people might join the conversation with a weekend plan discussion and then mention the bot to continue. By then there would be a lot of things in the thread that is most likely not needed unless you want the bot to join the weekend plan.
- The Fix: Get the parent message and the last three message in context without summarizing them. Works surprisingly well for a quick hack. Worstcase is that the user has to prompt with better context (that works for us)
Version matching. People type “3.0” when they mean “3.0.0”, or “v3.0” when there’s no “v” prefix in the registry.
- The Fix: I added fuzzy matching that normalizes inputs and tries prefix matches. Small thing, but without it the bot felt broken half the time.
Source browsing safely. Letting an AI read arbitrary package source files needs guardrails.
- The fix: I added a vendor whitelist so only known namespaces can be browsed, plus path traversal checks to prevent
../../etc/passwdnonsense. Even for a POC, you don’t skip this stuff.
and many more..
What I am looking forward to
I built this thinking that it will mostly help developers but now, I am looking forward for this being part of support teams go-to tool. Going from “let me check with a developer and get back to you” to answering questions on the spot. Customer response times drops, developer interruptions drops, and nobody had to write and maintain more documentation to make it happen.
This should be helpful for new developers onboarding too. “Do we have a package for X?” is a lot easier to ask a bot than to bother someone who’s heads-down in code.
Five files of plain JavaScript. Slack handler, Claude client, Packeton HTTP client, security layer, and an entry point is what it took. Four npm dependencies. About 1500 lines total. No framework, no ORM, no abstraction layers. For a 3-hour POC, that felt right.
What I Learned
Managing a large number of internal packages is one of those problems that creeps up on you. At 10 packages, you remember everything. At 30, you start forgetting. At 60+, you need tooling — and not just for developers.
The knowledge about what your packages do lives in the code. It’s always there, always up to date. The problem was never missing information, it was that the information was locked behind tools only developers use. Put a conversational layer on top and suddenly support, product, and new hires can all access it.
Road ahead
- Integration with the installation itself
- Equip the bot with tools to fetch the latest configs from installations that use these packages.
- Integrate with github so that bot has context on where the packages is installed in.
- use tools like claude-mem for memory
If you reached here, and wonder if I can share the code? Of course, let me know in the comments in you are interested.