3 min readproductlaunch

First Sync: your organisation now starts set up, not empty

New organisations land in a five-step wizard that explains shareskills-start, asks how your team wants syncing to behave, and seeds the skill into your library with your answers in a config file — while the skill itself stays canonical and keeps receiving updates.

The shareskills team

Until this week, a brand-new organisation on shareskills started with an empty library and a line in the FAQ: search for a skill called shareskills-start and install it. That skill is the single entry point for everything here — first-time MCP setup, syncing local skill edits up, pulling team updates down, discovering skills teammates have published, flagging duplicates. Telling people to go and find the most important skill themselves was, in hindsight, a strange way to welcome them.

So now the welcome is a wizard. Create an organisation and you land in First Sync: five short steps that explain what shareskills-start does, ask how your team wants it to behave, and then seed it straight into your library — team-visible, ready for every member to install with one call.

Step 1 of the First Sync wizard: an introduction to shareskills-start listing two-way sync, the duplicate guard, discovery, and first-time setup.
Step 1 — before asking anything, the wizard explains what the skill actually does.

What it asks

The questions are the ones every team eventually answers anyway, usually by accident and one argument at a time. First Sync asks them up front:

  • Default visibility for new skills. When someone pushes a local skill up for the first time, does it start private, team-visible, or in the public directory? Most teams want team; the wizard defaults there.
  • Sync scope. Personal skills (~/.claude/skills/), project skills committed inside repos, or both.
  • The staleness nudge. An opt-in session hook that reminds people when their local skills have drifted more than a threshold — you pick the number of days — behind the library.
  • Discovery. Whether syncs should also suggest relevant skills from your own library, from the public directory too, or not at all.
  • The duplicates report. Whether each sync ends by flagging near-identical skills for an admin to merge.
Step 3 of the wizard: checkboxes for personal and project sync scopes, a staleness-nudge toggle with a days slider, and a locked rule stating conflicts are never auto-resolved.
Step 3 — sync scope and the staleness nudge. Conflicts stay human, and no setting changes that.

A copy that never goes stale

The obvious implementation was to stamp a copy of shareskills-start into every organisation and edit it to taste. We didn’t, and the reason is the same one this blog keeps returning to: the update is the attack surface. Stamp out editable copies and every fix we ship afterwards — and for a skill whose job includes handling your MCP credentials, some of those fixes are security fixes — reaches nobody. A hundred organisations, a hundred slowly diverging photocopies, no channel to recall any of them.

Instead, the wizard writes your answers into one small file inside the skill: config/org.json. The body of the skill — the instructions, the security rules, the sync procedure — stays canonical, maintained by us, versioned like any other skill. Your configuration is an overlay it reads at the start of every run. Re-run the wizard and only the config file changes; any edits your team has made to the skill’s other files are left exactly where they are. Customisation and updates stop being a trade-off.

The seeded shareskills-start skill page: team-visible, version 1, with config/org.json sitting alongside the canonical SKILL.md, references and scripts in the file tree.
The result: your library’s copy of shareskills-start, with config/org.json holding the org’s answers.

What you cannot configure

Two screens of the wizard show rules with a lock on them, and the lock is the point. No org setting can make shareskills-start ask for a token in chat, publish or overwrite anything without showing a diff and getting a yes, or auto-resolve a conflict when local and remote have both changed. The config file lists these invariants anyway — not because the skill needs reminding, but because the admin who completes the wizard has then seen, in writing, what the skill will refuse to do no matter who asks. When someone later wonders why it won’t “just sync everything”, the answer is on file.

Step 2 of the wizard: default visibility cards for private, team, and public, above two locked policy rules about change requests and confirmed publishing.
Step 2 — you choose the publishing default; the locked rules are shown, not offered.

Already have an organisation?

First Sync isn’t only for day one. Any owner or admin can open /first-sync at any time — to run it for an organisation created before this week, or to change the defaults later. Completing it again updates the config overlay, bumps the skill’s version with a proper change note, and leaves everything else untouched. Members then pick the new defaults up the way they pick up any skill update: through the sync they were already running.

It is a small feature by line count. But it moves the most load-bearing skill in the product from “go and find it” to “it was here when you arrived, configured the way your team decided” — which is rather the whole thesis of shareskills, applied to itself.

First Sync: your organisation now starts set up, not empty | shareskills blog