How we get every company skill onto every employee's Claude with a one-time install, then push every future update from a single edit. No more reinstall campaigns.
Skill distribution today is a manual campaign, and it repeats on every update.
Today, sharing a skill means zipping it, posting install instructions in Slack, and waiting for 30 to 40 people to each run the install. History shows that takes weeks. Then the first time the skill needs a fix or a new feature, the entire campaign repeats from zero.
The fix is the same move we already made with data tools on the Emazing Group MCP: centralize the source, automate the delivery. Skills just need a different delivery channel than tools, and that distinction is the whole design.
One decision: how do company skills reach, and stay current on, every employee's machine? Three ways to do it.
No new infrastructure, but every update restarts a 40-person manual campaign. No audit trail, no way to revoke a copy, no rollback. This is the problem, not an option.
Tempting because tools already auto-update there, and it is what we planned to test on the June 2 call. But the MCP cannot write files to anyone's machine or run anything on a schedule, so skills would never land. The test would fail. Detail in Two Channels below.
Employees install once from a single Slack paste. Their machines auto-pull the latest skills daily and before every scheduled run. One edit updates the whole company within 24 hours, with a full change log and one-click rollback.
Option 3. It is the only channel that physically delivers files to machines, supports scheduled runs, and removes the reinstall campaign permanently. Tools keep riding the MCP gateway exactly as today; skills get their own purpose-built lane. The rest of this page is the detail behind this call.
This is the question we left open on the June 2 call ("is it the MCP, or the MCP plus a GitHub for skills?"). The answer is both, kept separate.
Carries: tools. Meta, GA4, Shopify, Klaviyo, Google Ads, Sheets.
Everyone connects to one hosted gateway. When we update the server, every connected person has the new version instantly, because nothing lives on their computer.
What it cannot do: it never writes files to anyone's machine, and it cannot run anything on a schedule. So it physically cannot deliver or update a skill.
Carries: skills. Skill optimizer, Claude usage reporter, every future company skill.
Skills are files that live on each person's computer. To update files on 40 machines, each machine has to fetch the new version. A tiny scheduled "pull" does that automatically every day, plus right before any scheduled run.
One edit on GitHub, and every machine self-updates. Nobody reinstalls anything, ever.
On the call we planned to attach a skill to the Amazing Group MCP and test whether it auto-updates like the tools do. It will not. The MCP protocol only hands clients tools to call. It has no mechanism to install or update skill files on a machine, and no way to schedule a Friday run. The test would burn a weekend proving a no. This page is the alternative that delivers exactly the outcome we wanted from that test.
One repo, one installer, one daily pull. Everything else is automatic.
We ship a skill that runs every Wednesday at noon on each machine and writes a few data points to a company spreadsheet. A month later we want two more data points and a second sheet. Old world: re-zip, re-Slack, 40 reinstalls, weeks of chasing. New world: one edit to the skill on GitHub. The Wednesday trigger on each machine never changes; the instructions it runs are refreshed automatically. Next Wednesday, all 40 machines report the new data.
This is the natural question, so here is the short version. Capability is identical either way: skills work the same in one repo or two. The split comes down to two different keys for two different jobs.
A second repo costs us nothing: Claude builds and maintains both, employees still do one install, and the split is invisible to them. So we get a clean boundary (MCP infrastructure stays private, skills are company-readable) for free. Same outcome, safer default.
| eg-mcp-tools | eg-skills (new) | |
|---|---|---|
| What it holds | MCP server code (tools) | Company skill files |
| Where it runs | Hosted gateway (Render) | Each employee's machine |
| How updates reach people | Instantly (live server) | Daily pull + pull-before-run |
| Can schedule runs | No | Yes (set up once at install) |
| Install per person | Once (done for pilot users) | Once (3-minute paste) |
Two questions: what can employees see, and what could go wrong.
Everything committed to eg-skills is readable by every employee with access, forever, including the full edit history. GitHub never forgets: deleting a secret in a later commit does not remove it from history. So the repo carries exactly one kind of content: instructions, never secrets, never personal context.
| Risk | Mitigation |
|---|---|
| Someone malicious pushes a bad skill that 40 Claudes then execute | This is the real risk in any central-update system. Write access is limited to Anthony and Brian, both with two-factor enabled. Everyone else is read-only. One unreviewed commit cannot come from anyone outside the two of us. |
| A well-intentioned edit breaks a skill for everyone | Test on Anthony's machine first, then the pilot machines pull before the company does. If something slips through, one-click revert on GitHub rolls every machine back at their next pull. Central rollback is a feature the zip-file world never had. |
| A secret accidentally gets committed | Prevention stack above (no-secrets rule + per-machine credentials + automatic scan). Worst case the repo is private and read-only, and we rotate the leaked key immediately. |
| Repo access leaks outside the company | Repo stays private. Employees get read-only access scoped to this one repo. Offboarding = remove their access in one click, same as Google Workspace. |
| A scheduled skill does something unintended on a machine | Scheduled skills are scoped narrowly (read the agreed data, write to the agreed sheet) and reviewed before they enter the repo. Claude's own permission system on each machine is still the final gate. |
This is materially safer than today's zip-and-Slack flow. Zips are uncontrolled copies: no audit trail, no revocation, no rollback, and stripped-of-secrets only if someone remembered. The repo gives us one reviewed source, a permanent change log of who changed what and when, instant rollback, and one-click offboarding.
Same crawl-walk-run we used for the MCP gateway.
Create the eg-skills repo, the one-paste installer, and the daily pull. Load the first skill (emazing-skill-optimizer). Run the full loop on Anthony's own machine: install, edit, confirm the update lands, confirm a scheduled run picks up an edit.
The same early adopters already on the MCP gateway. Verify install friction, the daily pull, and one scheduled skill writing to a sheet from every pilot machine. Fix what surfaces.
One Slack post with the single paste block. From then on, every new skill and every update flows automatically. Brian owns rollout and adoption tracking, per the gatekeeper model we agreed on the call.
eg-mcp-tools stays the tools layer. A new eg-skills repo becomes the skills layer. Nothing about the current MCP gateway changes. The split keeps your MCP infrastructure private while skills stay company-readable, at no extra cost or install friction.
Option A: each employee gets a GitHub account with read-only access to this one repo (clean audit and one-click offboarding, but 40 accounts to manage). Option B: a single shared read-only key baked into the installer (zero friction for employees, but one shared credential whose worst case is someone outside reading our skills repo).
Proposed first three: emazing-skill-optimizer, the Claude usage reporter (Jose's), and skills-sync. Pilot group: the people already on the MCP gateway.