Three Months After Launch: What We Learned Running Our Own Claude Code Marketplace

Three months ago we set up our own Claude Code marketplace internally: a set of plugins, skills, and agents meant to orchestrate our agentic workflows around content and frontend operations. The idea was simple, turn recurring tasks into reusable, clearly scoped building blocks instead of improvising each time from scratch. What follows is not a success story with tidy numbers, because we simply do not have reliable installation, usage, or ROI figures for this period. It is a qualitative status check from day to day work: which plugins actually get used, which ones only sounded good on paper, where the real effort sits, and what we would now do differently. For anyone weighing whether to structure agentic workflows in their own content or frontend pipeline, this unpolished view is probably closer to reality than any launch announcement would be.

Which plugins actually get used, versus the ones that sounded good

At the start we had a long list of ideas: plugins for SEO audits, for competitor tracking, for automated changelog summaries, for asset curation, for brand checks. Almost all of them sounded convincing in concept, because each addressed a real problem. Three months in, though, a clear pattern has emerged: the plugins that get used are the ones embedded in an existing, daily step in the workflow, not the ones that would have required establishing a brand new process.

The brand review skill, for instance, now runs before practically every piece of content goes live, because it attaches to a step that already existed: the check before pushing. A skill built for proactive competitor research, by contrast, one that nobody had to actively trigger because it "might become relevant eventually", gets called noticeably less often than expected. It is not a bad skill, it just does not sit at a point anyone walks past every day.

A second observation: skills that deliver a clear before-and-after transformation, say markdown turned into a publishable blog node with asset references, get requested more often than skills that "only" research or suggest. Research output has to be evaluated and processed further by someone, which costs additional attention. A finished artifact, on the other hand, can be reviewed and approved or discarded right away. We clearly underestimated this friction gap at the start.

And finally: plugins built for a very specific, rare occasion, such as one-off locale repairs, are not perceived by most team members as standalone tools at all, more as an emergency drawer. That is fine, as long as you know while building it that you are serving a small, specialized audience, and you are not disappointed when the majority never touches it.

Why skills with clear trigger descriptions get found more reliably

A skill is only as useful as the likelihood it gets invoked at the right moment. This is exactly where we underestimated, in the first weeks, how much rides on how the trigger description is worded. Skills with vague, general descriptions like "helps with content tasks" were matched correctly noticeably less often in practice than skills with concrete triggers such as "update hero image on an existing blog post" or "CSV import for partner apps from HubSpot".

The reason is obvious once you say it out loud: an agentic instance has to infer from a natural language request which of several possible tools is meant. The more precisely a trigger description mirrors the actual language people use to describe the task day to day, the more reliably it gets matched. We repeatedly saw a technically sound skill simply go unfound because its description was written in a different vocabulary than the one the team actually uses.

That led to a working principle we now apply consistently: before building a new skill, we collect the actual phrasing colleagues would use to name the task, and build the trigger description around that, not the other way round. It sounds obvious, yet it has made more difference than any optimization of the skill's underlying logic.

Another effect worth naming: several very similar skills with slightly overlapping triggers do more harm than good. Instead of precision, you get confusion about which tool is responsible for which case. Over the three months we merged two originally separate skills for exactly this reason, because in practice nobody could cleanly tell their responsibilities apart, and matching reliability has noticeably improved since.

Why memory upkeep is the real effort, not writing the skills

When you set up a marketplace of agentic tools, most of the early energy goes into designing the skills themselves: which steps, which delegations, which output formats. Three months in, it is clear that this part is comparatively quick to finish. The effort that actually persists sits elsewhere, in the ongoing upkeep of the memory files these skills rely on.

A skill meant to check brand voice is only as good as the guidelines file it references. When tone evolves, a new forbidden buzzword appears, or a competitor repositions, that change has to flow into the memory file, otherwise the skill keeps working off stale assumptions and produces output that is formally correct but no longer current. That upkeep does not happen automatically, it requires regular, deliberate time from someone who actually knows the current state.

The same holds for Hygraph schema documentation: the moment a content model changes, a new required field appears, or a taxonomy expands, the corresponding memory file needs updating, otherwise downstream skills produce mutations against a schema that no longer exists in that form. We underestimated this more than once and then debugged errors that turned out to be simply stale reference data, not a logic flaw in the skill.

The honest observation after three months, then, is that agentic workflows do not remove effort from people, they shift it from execution toward maintaining the underlying knowledge base. That is not a downside in itself, but it is a different kind of work than before, and anyone who does not plan for it will be caught off guard by the ongoing maintenance.

Where agentic automation genuinely carries weight in the content and frontend pipeline

Automation carries the most weight where a task is repetitive, clearly structured, and has unambiguous success criteria. Pushing finished markdown drafts into Hygraph, including asset upload, localization linking, and the publish step, is exactly that kind of case: the steps are always the same, the order is known, and errors show up clearly in status codes and query results. This is precisely where a single, unified push path has noticeably replaced the earlier collection of one-off scripts.

Automation also holds up well in pre-publish quality checks: a deterministic check for relative links, missing locale prefixes, or too few hub links is exactly the kind of rule a script checks more reliably than a person under time pressure at the end of a long day. That is not a substitute for editorial judgment, but a sensible earlier stage that filters out obvious mistakes before a human even looks.

The apps registry sync between HubSpot, Supabase, and Hygraph belongs in this category too: the data structure is stable, the transformation is rule based, and the results can be spot checked without anyone having to review every single row by hand. Automation genuinely saves attention here, because it takes over a task that nobody enjoyed doing before, necessary but never particularly demanding.

What all these cases share is a clear definition of "right" and "wrong" that can be encoded. Wherever that clarity is missing, say whether a piece of copy is actually convincing or whether a topic is strategically worth pursuing, automation carries noticeably less weight.

Where automation just shifts manual work around

The picture is less convincing where a task gets formally automated but the actual decision still rests with a person. A good example is topic selection for content: an agent can summarize research, scan trends, and draft suggestions, but the decision of which topic is genuinely relevant for your audience and positioning remains a strategic call no skill should make. When that gets attempted anyway, you get a misleading efficiency gain: the groundwork is done faster, but the actual check of whether the suggestion holds up still needs just as much attention as before.

Something similar happens with image selection for the apps registry: automated logo sourcing finds usable results in the majority of cases, but it regularly also delivers marketing mockups or mismatched images that only surface once a human actually looks. The manual work does not disappear, it shifts from "find the image" to "check the image", and that check is hard to delegate, because it requires a feel for brand consistency that is difficult to codify into rules.

The same shift shows up with brand voice: a skill can reliably filter out forbidden terms, but the subtler question of whether a piece of copy actually sounds like the brand, or merely satisfies the rules on paper, remains a judgment call a person has to make in the end. Anyone who believes that judgment can be fully outsourced is simply postponing the manual work, usually to a later point, right before publication, when corrections become more expensive.

What did not work

Honesty belongs in this recap too: not everything held up. An early attempt to build a skill that would independently suggest new content topics based on competitor activity fell out of use fairly quickly, because the suggestions sounded plausible but rarely matched actual strategic priorities. The problem was not the skill itself but the fact that we tried to automate a decision that simply is not rule based enough.

Trying to run locale repairs fully automatically, without a prior diagnostic step, also turned out to be risky. A single misinterpreted record could do more damage at scale than a targeted, manually reviewed fix ever would. Every repair now runs through a diagnostic query first, followed by targeted, individual mutations, never a blanket re push.

A third lesson concerns expectations around speed: the assumption that more automation automatically means less total time did not hold up in this form. Where automation saves time, it often shifts that saved time into additional care elsewhere, such as the memory upkeep already mentioned. That is not a reason to abandon automation, but it is a reason not to sell it as pure time savings, rather as a shift of effort to a place where it can be controlled more effectively.

Takeaway: what this means for your own agentic pipeline

Anyone weighing whether to structure agentic workflows for content or frontend operations should take one main expectation from our three months: the effort does not disappear, it relocates. From executing repetitive steps toward maintaining the underlying knowledge base, from searching for information toward reviewing suggestions, from scattered one-off scripts toward a single, auditable path. That is a worthwhile trade, but only if you enter it deliberately, rather than assuming an empty promise of saved time behind it.

The best entry point is where tasks are already clearly structured, recurring, and tied to unambiguous success criteria today, such as the push path between editorial and the content management system. This is exactly where our agentic Frontend Management Platform (FMP) helps teams keep content operations structured and traceable instead of scattering them across ad hoc scripts.

Less worthwhile is trying to fully automate strategic or taste based decisions. Anyone who stays responsible for tone, prioritization, and quality in their own role as a content manager will find a good starting point in our overview of content management, to see where structured tools support that role without replacing it. And if you are wondering how a composable, headless frontend architecture technically supports these workflows, you will find that context in our overview of the composable headless frontend.

Three months is short enough that nothing here is a final verdict, but long enough for an honest interim conclusion: the tools that stick around are the ones that fit into existing work, not the ones that impose a new process from outside. Anyone who keeps that distinction in mind from the start will avoid some of the detours we took in our first three months, and will find further pointers in our role overview for content managers on where the next sensible step lies.