“I’m not technical: do every step yourself, and only ask me to click, sign in, or type my password in a system password box.” That’s the second sentence of the message you paste into the Claude desktop app to start the setup guide for my video and publishing skills, and I wrote the guide for the person who would say it.
The library is a private repository that works as a Claude plugin marketplace for a team. It holds ten plugins, among them email follow-up, a shared ledger of what people committed to on calls, video planning and editing, social posting and the recording exports I’ve written about separately, and I’ve made all 55 commits to it.
Setup by message
Pasting that message hands the work to Claude. It checks that git works and asks you to click Install for Apple’s developer tools if it doesn’t, signs you in to GitHub with a one-time code it shows you, installs the plugins and then tells you to restart the app. Your part comes to at most three things, which are clicking Install, signing in with the code, and quitting and reopening Claude. A second message, “set up the video skills”, installs the video toolkit, opens the pages for connecting your social accounts to Zernio, and reads the Zernio API key from your clipboard into the Mac’s Keychain before clearing the clipboard, so the key never shows up in the chat.
The guides also spell out the few things only a person can do. In each connector’s settings you set the send, share and delete tools to Never allow, as a second lock behind the skills’ own rules. On a Pro or Max plan you turn off “Help improve Claude”, since the email and meeting skills read other people’s messages and what they said on calls. Keys for the recording services go in a file and never in a chat.
What a release has to pass
No skill in the library sends an email or shares a document, even when asked, and you press Send in Gmail yourself. The one thing that can go out publicly is a scheduled social post, and only after you approve its preview in the conversation. I didn’t want that promise to rest on prose that could drift between versions, so every plugin that touches a real inbox or a shared sheet has a check script I run before each release, and it fails when a rule slips.
The email plugin’s checker fails if the plugin contains anything executable, any hooks or an extra server, because it’s meant to ship instructions and text only. It reads every line for the tool names that can’t be undone, the ones that send, forward, share, trash or delete, and fails any line that names one without also saying never or block. It also fails on an email address outside example domains.
The meeting plugin writes call content into a sheet the whole team reads, so its checker adds two rules. It fails on anything that looks like real call content, such as a link to a real recording or a real recording ID. It also insists that the shared reference files are byte-identical in every skill, because skills get zipped and installed one folder at a time, and a stale copy in one folder would quietly change the rules for that one skill.
Some apps take a skill file instead of a marketplace, so a builder script makes upload zips for Claude and for ChatGPT in the two shapes each one documents. It packs only files committed to the repository, which keeps caches, credentials and anything untracked out of the zip, and it refuses video, audio, model files, keys and any single file over 1 MB, since a skill should be instructions and small scripts. It also refuses two skills with the same name, because the second zip would silently overwrite the first. A manifest check I run before every push fails if a plugin’s name, version or description differs between its own file and the catalog.
What hasn’t been tested
The video setup has been tested on an Intel Mac, and Apple-chip Macs haven’t been tried yet. The README says plainly that nobody has set up the email or ledger plugins from the guides alone so far, so I do each person’s first install and first run with them.