Sharing code between Agent Skills

[hlineholm-teledyne]

I've been thinking about how teams share code and dependencies between Agent Skills in monorepos and would love practical tips.

Problem in one line

• Related skills often duplicate small shared utilities (env, API helpers, error handling). At scale this becomes a maintenance burden.

Common approaches

• Vendored copy per skill (portable, no setup)
• Org-scoped/private packages (centralized maintenance, requires auth/setup)
• Build-time bundling (CI/bundler complexity)
• MCP/registry experiments

Short questions

1. Do you publish org-scoped packages for skills? How was onboarding (auth, .npmrc)?
2. Repo layout: ./packages/ vs ./skills/packages/ — which worked for you?
3. Naming: how do you name packages to avoid clutter in org package lists?
4. Heuristics: simple thresholds (skill count / LOC / security) for when to extract?
5. Tooling: bundlers, CI patterns, or simple scripts you recommend?

Examples, links, or short anecdotes much appreciated — thank you!

[aaronpowell]

@hlineholm-teledyne I've converted this to a discussion as I think it better fits this format than an issue.

What you raise is a very real challenge which I don't think we have any "good" answer to just yet as we're still very much trying to figure this out as we go 😅.

Personally, I think of the code side of skills as mini applications that the agent can leverage, and as such, design them self-contained. Where there is shared stuff, treat it the same as any other shared thing that we have in our codebase so it's a case-by-case basis. I also keep skills very tightly constrained, so the potential of shared code is somewhat lower because they don't have that much code to begin with.

[hlineholm-teledyne]

I completely agree—skills work best as self-contained mini applications. 🎯 That said, I explored several approaches to handle the shared code that does emerge:

I first considered CLI tools (curl + jq for read operations) since they're portable and eliminate scripts entirely. But Windows compatibility became a blocker—most Windows developers need WSL or alternatives, which adds friction. ❌

I looked at MCPs (Model Context Protocol servers) for centralized logic, but for ad-hoc workflows like "create a Jira ticket," they add subprocess management overhead that skills don't need. Skills just work inline. ❌

That left npm packages. I settled on org-scoped packages (@org/packages) for a few reasons: 📦

• Cross-platform consistency: Node.js ESM behaves predictably on macOS and Windows. Python has path handling quirks; bash requires WSL on Windows. Node just works.
• Aligned with the stack: All our build scripts are .mjs files anyway—it's the natural fit.
• Security-sensitive code centralization: Credential handling and auth logic should have a single source of truth for patching. Small duplication is fine; auth bugs aren't.

On thresholds: I extract to packages when code crosses practical boundaries—5+ skills sharing code, or 500+ lines duplicated total—but I first ask: can the skill be simpler? Push logic to instructions, consolidate workflows, question whether duplication actually matters. ⚖️

That design-first mentality keeps portability as the default. Packages are the exception, not the rule.