DEV Community

Fernando Paladini
Fernando Paladini

Posted on

I Went From 1 GitHub Package to 13 in ~15 Minutes - With Cursor, AI Agents & MCPs

#productivity #ai #github #devops

I had a quiet inconsistency in my open-source footprint.

Across npm, RubyGems, PyPI, and Docker, I already had about 13 packages published and working.

But on GitHub - under the Packages tab - I only had one.

So if someone discovered me through GitHub, they saw a fraction of what I actually ship. The rest lived elsewhere: npmjs, RubyGems, Python indexes, container registries. Fragmented. Invisible. Easy to underestimate.

I didn't want to migrate away from those platforms.

I didn't want to break existing publish flows.

I didn't want to invent a paid setup.

I wanted one thing:

Also publish everything to GitHub Packages - for free - without touching the distribution channels that already work.

So I opened Cursor, connected MCPs, and asked the AI to automate the whole thing.

About 15 minutes later, my Packages tab went from 1 → 13.

The real problem (and why humans hate it)

Publishing "also to GitHub Packages" sounds simple until you do it across ecosystems:

  • npm packages need GitHub Packages registry config + auth patterns
  • RubyGems / Python packages have different packaging and publish conventions
  • Docker images need GHCR wiring without breaking existing tags/flows
  • Every repo has its own CI, secrets model, and release habits
  • You must add a destination, not replace the ones that already work

Doing that by hand means:

  1. Find all relevant repos/packages
  2. Clone each one
  3. Understand how it currently publishes
  4. Add GitHub Packages / GHCR support safely
  5. Avoid duplicate work, paid infra, or breaking npm/PyPI/RubyGems
  6. Open PRs, wait, merge, verify Packages tab

That's hours of repetitive maintainer work. Easy to postpone. Hard to justify when "the packages already publish somewhere else."

The stack I used

Cursor + AI agents

I didn't babysit one repo at a time. I prompted for an end-to-end automation: discover packages, update publish pipelines, open PRs, ship safely, verify outcomes.

GitHub MCP

So the agent could operate on GitHub itself - repos, workflows, PRs, package visibility - instead of me jumping between browser tabs and terminals.

MCP-me

This mattered a lot.

MCP-me helped surface my recent projects and packages across GitHub and package ecosystems (npm, RubyGems, and similar registries). The agent wasn't guessing what I publish - it could find the real inventory and work against it.

That's the shift:

From "AI writes a snippet" → AI runs a packaging ops workflow across my ecosystem.

Constraints I gave the AI (this is the important part)

I didn't say "just publish everywhere."

I said something closer to:

  • Find my packages across npm / RubyGems / Python / Docker
  • Make them also appear under GitHub Packages
  • Do it with no extra cost
  • Do not break or replace existing publish destinations
  • Prefer additive CI/config changes
  • Open PRs / ship changes carefully
  • Parallelize where possible

Those constraints are why the result felt useful instead of risky.

AI is dangerous when you ask for "make it better."

AI is powerful when you ask for a bounded ops outcome.

What changed

Before: GitHub Packages showed 1 package.

After (~15 minutes): GitHub Packages showed 13 packages.

Same body of work. Better discoverability. Existing npm / RubyGems / PyPI / Docker publishing still intact.

Why this is a better AI narrative than "it wrote code for me"

Most AI content online is:

  • autocomplete a function
  • generate a README
  • explain a stack trace

Useful. But small.

This was different:

  • inventory across platforms
  • multi-repo changes
  • CI/publish wiring
  • PR flow
  • verification against GitHub Packages
  • completed in the time I'd normally spend cloning the first few repos

That's the day-to-day leverage developers should be chasing.

Not replacing craft.

Removing the maintenance tax.

How other developers can use the same pattern

If you maintain more than a couple of libraries, try prompts like:

  • "Find every package I publish on npm/PyPI/RubyGems/Docker and also publish them to GitHub Packages without breaking current releases."
  • "Add GHCR publish to all my Docker repos, keep existing registries working, open PRs."
  • "Audit my GitHub Packages tab vs my public package registries and close the gap."
  • "Update release workflows across my repos in parallel; no paid services; no force-push."

Give the agent:

  1. Access (Cursor + GitHub MCP + inventory MCP like MCP-me)
  2. Constraints (no cost, no breakage, additive only)
  3. A definition of done (Packages tab reflects reality)

Then let it parallelize the long tail.

Closing

I didn't spend an afternoon doing packaging busywork.

I spent ~15 minutes supervising an AI workflow that:

  • discovered my packages across ecosystems
  • wired GitHub Packages support safely
  • opened / handled PRs where needed
  • left existing npm / RubyGems / Python / Docker publishing untouched

Result: GitHub Packages 1 → 13.

This is what "using AI as a programmer" should look like in 2026:

Automate the ops that make your work discoverable - across GitHub and every registry you already ship to.

If your Packages tab (or docs, or release pipelines) only shows a fraction of what you actually publish... you're not missing motivation.

You're missing leverage.

What's still missing from your GitHub Packages tab?

If you want the prompt pattern I used, drop a comment below.

Top comments (0)