Sharing an AI skill gave me an "Aha" moment about the future of software architecture
By Mark Cohen
Last week a colleague asked me to for help with a competitor-intelligence skill. I’d originally built mine in Hermes Agent. It monitors competitors and sends me a report when it's found something notable. The workflow was very much tailored to me with everything hard-coded:
The companies I followed
What I considered significant
How I wanted the results delivered (WhatsApp, slack and teams).
My personal setup would have been useless to him, so I used Claude to rework it into a shareable skill and published it on GitHub as an open-source project (I'll share it soon, separately). I gave him two files to set it up:
The first serves as the data for the skill, describing the products, keywords, and competitors for his needs.
The second contained the prompt to get his agent to install the skill.
This brief exchange, coupled with a call for Maybe fifteen minutes, led me to a bigger thought: Much more of the way we work could become something users can adapt and share independently of the software that holds their data.
Much more of the way we work could become something users can adapt and share independently of the software that holds their data.
Customisation moves closer to the user(s)
The underlying software may already offer AI capabilities, APIs, or an MCP server. The shift I’m describing is where customisation happens and who owns it. As a customer, my primary motivators are needing the provider to deliver a dependable core, including:
Authoritative data
Useful capabilities
Enforceable permissions
Business rules - at least the basics
Compliance controls.
Then I can build workflows around how my organisation actually operates.
Historically, that tailoring might have required a professional services team, an implementation partner, or a team of embedded engineers who often ended up being a permanent team. Agent skills could move some of that work directly into the hands of customers and their teams. A person develops a workflow, tests it against their needs, and packages it as a skill. They can keep it personal or publish it for colleagues to adopt.
Those skills could extend one product or just as easily coordinate across several, including products from competitors. This might bother the vendors, but it would not bother the customer. The workflow follows the customer’s needs across product boundaries. The underlying systems still enforce what users and agents are allowed to do. Customers gain more control over the flexible procedures they've built on top.
The architectural shift is from vendor-delivered customisation towards customer-owned workflows at the edge.
Publishing could itself be a skill
Picture a small organisation with say twelve people, each using their own personal agent. Someone develops a skill that makes a recurring task easier. They use it, correct it, and refine it. Then they tell their agent to publish it.
Publishing would itself be a skill. It would prepare a reusable version, separate personal settings and credentials, package the supporting files, and create documentation and installation instructions. For an open source skill I would use GitHub and make it a public project. There are a number of ways this could be done for internal-only skills within one organisation though. Once published, your agent could then "advertise" the new skill by announcing it in Slack: who created it, what it does, and how to install it.
My agent Vector, announcing in Slack that a new skill was shared
Colleagues who find it useful could install it into their own agents, using their own accounts and preferences.
Build, use, refine, publish, discover, install.
That turns an individual improvement into something other people can adopt without copying the creator’s entire setup.
This works across agent platforms
My original workflow was built in Hermes, because that's what I run for personal use. I created the shareable open-source version in Claude, because thats what most of my colleagues use. The underlying idea extends beyond any one agent. This pattern can be implemented with ChatGPT or Claude as well as Hermes. There are nuances that differ - how they work, permissions needed, what they may have access to... But the underlying principle is portable.
ChatGPT supports reusable skills, with plugins providing an installable distribution mechanism.
Claude supports sharing skills with colleagues and publishing them to an organisation’s library on Team and Enterprise plans, subject to organisational settings.
Hermes supports personal skills alongside external skill directories, providing building blocks for a shared library. The publishing and update process would need to be designed around that setup.
A shared skill doesn’t automatically bring working connections with it (in fact, by default is should not). Each recipient still needs the appropriate tools, authorisation, personal API keys, and possibly other configuration elements.
An evolving place for workflow logic
This doesn’t mean every business process should move into a personal agent at all - quite the opposite. Mandatory controls need to remain enforceable regardless of which agent (or app, or person) calls an API. But it suggests an additional architectural layer: shared systems holding authoritative data and enforcing rules, with personal agents carrying adaptable procedures across them.
I’ve successfully taken a workflow from a personal Hermes setup to a shareable skill created in Claude. The next experiment is making the publishing process itself into a repeatable skill.
The question it leaves me with is this:
How much of the way we work needs to be embedded in a software product, and how much could (or should) become a portable capability that users can improve and share?