09: Ship Updates to a Published FileMaker Skill

The Latin root of 'publish' is publicare : to make public, to hand something over to the people. Note the order. You make it fit for the public first. Then you hand it over.

More FileMaker Developers are building Skills, and most of those Skills live in a folder on one Mac. Getting them onto GitHub feels like a second job. Alex at RGC Data has written an easy beginner's guide to Git and GitHub for FileMaker Developers, and it's the place to start if Git itself is new to you. This post picks up where it leaves off: what changes when the thing you're publishing is a Skill. Every section below is a step the cadenceux-github Skill walks you through.

Why a FileMaker Skill Needs More Than a Git Primer

Git will happily push a folder. It won't tell you the folder still carries your client's server name, or that the zip GitHub offers your users won't install.

Example: Before writing the Skill, I asked Claude how to share a Skill on GitHub, with no Skill loaded. Sound advice on Git. Then it told users to grab the green Download ZIP button. That's the one route that fails.

Across six test questions, Claude alone passed three. With cadenceux-github loaded, Haiku, Sonnet and Opus each passed all six.

The Full Journey: From GitHub Account to Skill Update

Two Skills share the work. cadenceux-skill-creator builds and tests. cadenceux-github publishes and keeps it current. Each hands over to the other at the right moment.

1. Create a GitHub account. cadenceux-github: username, two-factor, private email.

2. Build the Skill. cadenceux-skill-creator: evals first, then the Skill, under your name, not mine.

3. Test it does what it's designed to. cadenceux-skill-creator: the same questions with and without the Skill, on Haiku, Sonnet and Opus.

4. Publish to GitHub. cadenceux-github: scrub, repo, release, install check.

5. Review your published Skills. cadenceux-github: what's changed, what's unreleased, what's out of date.

6. Update a Skill. cadenceux-skill-creator for the change and the retest, cadenceux-github to ship it.

What cadenceux-github Does When You Call It

It looks before it talks. In Claude Code it checks your folder: is there a SKILL.md, is Git set up, is there a remote or a release tag, are you signed in to GitHub? Then it tells you where you are and the next step, and asks before doing anything.

In chat it asks one question. First publish, shipping an update, a review, or fixing a problem? Then you run each command and paste back the output.

Create a GitHub Account and Sign In Without a Password

No account yet? You create it yourself, in your own browser. Pick the username with care: it lands in every install command people type. Turn on two-factor authentication, because GitHub requires it to publish code, and keep your email private.

Then tools and sign-in. gh auth login opens your browser, and gh auth setup-git hands that sign-in to Git. You never type a GitHub password at a terminal prompt. GitHub rejects it anyway.

The Skill also has you set your commit email to GitHub's noreply address, so your personal email stays out of public history.

Scrub Client Material Before the First Commit

Skills are born on client projects, and the examples carry their fingerprints. Anything you push stays in Git history, even after you delete it in a later commit.

So the scrub happens before the first commit. .fmp12 files, SaXML and DDR exports, Data API responses and .env files move out of the skill folder entirely. The .gitignore is your second line of defence, not your first. Then the Skill's scanner reads every file Git would commit, with your client's own names added as search terms:

bash scan_for_client_material.sh ~/skills/invoice-helper "ClientName" "client.local" --history

Example: Testing the scanner, I seeded a dummy Skill with a Re-Login step, an fmnet: address and a client email, then 'removed' the password in a second commit. The scan flagged all three in the current files, and found the password twice more in history.

One Repo, Three Ways to Install a Claude Skill

Put SKILL.md at the root of the repo, not in a skills/ folder. The same tree then serves every install route:

Claude Code plugin. .claude-plugin/plugin.json and marketplace.json make your repo its own marketplace.

Claude app on macOS. A .skill file, installed with a double-click.

Claude.ai, Desktop and Cowork. A .zip, uploaded under Customize → Skills.

The Skill carries templates for every file: both manifests, .gitignore, .gitattributes, the README install section and the CHANGELOG. Your users then install with two commands:

claude plugin marketplace add yourname/invoice-helper
claude plugin install invoice-helper@yourname

The name after @ is the marketplace name in marketplace.json, not the repo name. That one catches people.

Private First, Public Last

The Skill validates the manifests with claude plugin validate, then creates the repo private and pushes. You read it on GitHub as a stranger would. Only then does it re-scan the whole history and, with your yes, flip it to public.

Why GitHub's Download ZIP Breaks Skill Uploads

GitHub's Code → Download ZIP wraps everything in an invoice-helper-main/ folder and carries every file in the repo, .claude-plugin/ included. Currently, the Claude app's skill upload rejects an archive that carries a plugin manifest.

Which begs the question: what should people download? A release archive with one folder, named exactly as the Skill, and nothing else.

Build Skill Release Archives From the Tag

The Skill's release builder works from the tag, never your working folder:

git tag v1.0.0 && git push origin v1.0.0
bash build_release.sh 1.0.0 ~/skills/invoice-helper

Underneath, it's git archive. That only sees committed files, and it honours export-ignore in .gitattributes, so .claude-plugin/ and your evals stay out of the zip. It refuses to ship mismatched versions or a stray manifest, and writes unversioned copies so your README's releases/latest/download link always finds the newest release.

Shipping an Update to a Published Skill

The version lives in four places: SKILL.md, VERSION, plugin.json and the CHANGELOG heading. All four match, or the builder stops. A pushed tag is never moved. If a release is wrong, you ship the next patch.

Then you tell your users, both routes. Plugin users run claude plugin marketplace update, then claude plugin update. Zip users download the new archive.

Keep Your Published Skills Current

Ask "are my Skills up to date?" and the review script reads every Skill repo you name. Commits since the last tag. Versions that disagree. A release missing its zip. Open issues. An installed copy behind the release.

Example: The first run across four of my own published Skills found three clean and one with an open issue I hadn't read. That's the point. Not a crisis, just a nudge.

Whether the content itself has aged is a different question. That goes back to cadenceux-skill-creator for an audit.

When a Password Is Already in History

Change the password first. Rewriting history with git filter-repo, or starting a fresh repo, is cleanup. Rotation is the fix. The Skill also has you delete any release built from a commit that held the secret, because those archives keep their own copy.

Skill Publishing Vocabulary

Repo root. The top folder of the repository; for a Skill, the folder holding SKILL.md.

Marketplace. A marketplace.json listing plugins that Claude Code can install by name.

Release asset. A file attached to a GitHub release, downloadable from a stable URL.

export-ignore. A .gitattributes rule that keeps a path out of every archive Git builds.

Rotation. Replacing a leaked password or key so the leaked copy stops working.

Install the cadenceux-github Skill

I couldn't find a FileMaker-specific path for any of this, hence I'm sharing it here for the community. It starts with Skills. FileMaker scripts and code are next.

claude plugin marketplace add https://github.com/CadenceUX/cadenceux-skills.git
claude plugin install cadenceux-github@cadenceux

Or download cadenceux-github.zip and upload it under Customize → Skills. This is released under CC BY 4.0. Use it, fork it, adapt it. Attribute it.

Takeaway

Publicare. Make it public, but make it fit for the public first. Scrub before the first commit, keep the repo private until you've read it as a stranger would, and give people a release archive that actually installs. Then keep it fit: review, retest, ship the next version.

Your Skill is already useful to you. Let the rest of the community find out how useful.

More to come . . .