| name | ship-robin |
| description | Package the user's whole AI Personal OS ("Robin") into a portable, shareable plugin — a `.claude-plugin/plugin.json` manifest plus their identity files, best skills, and one scheduled loop, bundled into a folder and a `.zip` that installs on any machine with `claude --plugin-dir` (or the Codex equivalent). Turns "a pile of dotfiles" into "infrastructure you can hand to a teammate." Inventories what Robin is made of, lets the user pick what ships, runs a hard secrets scan so no token/.env/key ever gets bundled, writes a clean manifest, zips it, and test-loads it. Auto-detects Claude Code vs Codex. Use for "/ship-robin", "ship my OS", "package Robin", "export my Chief of Staff", "make my setup a plugin", "share my Robin", "bundle my skills as a plugin". Always shows the file list and asks before zipping. Never bundles secrets. |
| license | MIT |
ship-robin
You are packaging the user's Robin into a portable plugin — the Workshop-5
proof that "your OS is infrastructure, not folder cruft." Outcome: a
my-cos-v0.1/ folder + my-cos-v0.1.zip that a teammate can install with one
command and run one task through.
Do the work; they only pick what ships and paste a name. Two hard rules, stated
up front and never broken: (1) show the exact file list and get a yes before you
zip; (2) never — under any circumstance — bundle a secret. The manifest format,
the zip recipe, and the secrets exclude-list live in reference.md.
<ROOT> = CLAUDE.md (Claude Code) or AGENTS.md (Codex). Match the user's
language in conversation; the manifest + filenames stay English.
Say this first (the mental model):
"Everything that makes Robin yours — how he talks, what he knows, what he can
do, what he runs on a schedule — is just files. We're going to wrap those files
in a manifest so they become one installable thing. Then you (or a teammate) can
drop it on any machine and Robin shows up already knowing the job. We will NOT
pack any password, token, or key — those stay on your machine."
Step 0 — Detect platform (don't ask)
You know if you're Claude Code or Codex. CC → manifest at .claude-plugin/ plugin.json, install via claude --plugin-dir. Codex → also write
.codex-plugin/plugin.json, install via the Codex plugin flow. Write both
manifests so the bundle installs on either — it's two tiny files.
Step 1 — Inventory Robin (show them what he's made of)
Scan and present a checklist of what exists, grouped by layer. Look in ~/.claude/
(or ~/.codex/) and the current project:
- Identity —
<ROOT>, SOUL.md, user-profile.md, course-goals.md,
goals-2026.md, achievements.md, MEMORY.md.
- Skills — every dir under
~/.claude/skills/ and project skills. Mark which
are self-built vs course-bundle.
- A loop — a Routine / Codex Automation / the
/give-robin-a-voice listener /
a LaunchAgent / cron entry.
Present it as a list with sizes. This inventory is itself a lightweight /cos-review
— if there's almost nothing to ship, say so gently and point at /cos-review to
plan what to build first.
Step 2 — Who is this for? (ASK — it decides what's in the box)
Two shapes, and you MUST ask which before assembling:
- For yourself (full) — the whole OS: identity (
<ROOT> + SOUL + user-profile)
- 3 best skills + 1 loop. A backup / a new-laptop restore.
- For a partner (share-safe) — skills + loop + a README stub, NO
context/.
Your identity files (SOUL.md, user-profile.md, <ROOT>) were built by
extracting your private AI history — they carry your goals, employer, voice, and
sometimes personal detail. They are NOT for a classmate's disk. The Workshop-5
pair-swap uses the share-safe shape.
Say it plainly: "секреты (токены) не уезжают никогда. Личные identity-файлы — по
умолчанию тоже: для обмена с партнёром берём share-safe вариант — только навыки и
луп, без вашей 'души'."
Never bundle MEMORY.md in either shape unless the user explicitly asks — it's
the deepest personal store.
Then pick the payload. The Workshop-5 target is deliberately small: 3 best skills +
1 loop (+ identity only in the full shape). Ask which 3 skills they're proudest of
(or use daily) and which loop defines their mornings. Power-users can ship more — but
push for a coherent bundle, not a dump. A tight plugin someone can read beats a
40-skill archive.
Step 3 — 🔒 SECRETS SCAN (do this before assembling — non-negotiable)
Before copying a single file into the bundle, scan every candidate for secrets and
exclude anything matching the list in reference.md (.env, *.conf,
~/.robin/, *token*, *secret*, *.pem/*.key, id_*, Railway/Anthropic/
OpenAI/Slack key patterns, anything git-ignored). Then grep the files you WILL
ship for inline key patterns (sk-…, xoxb-…, AAH… bot tokens, long base64).
If you find a secret inside a file that would ship (e.g. a token hard-coded in
a skill), STOP, show the user the file + line, and offer to ship a redacted copy or
skip that file. Never zip a live secret. State the rule out loud — this is the
InfoSec trust contract; a shared plugin is auditable and must be clean.
Step 4 — Assemble the bundle
Build the staging folder (recipe in reference.md):
my-cos-v0.1/
├── .claude-plugin/plugin.json # + .codex-plugin/plugin.json
├── skills/ # the chosen skills, copied in
├── context/ # FULL shape ONLY — <ROOT>, SOUL, user-profile. OMIT for share-safe.
├── loop/ # the chosen loop (Routine def / bridge.py / cron line) + how to arm it
└── README.md # what this is, how to install, how to arm the loop
Share-safe shape omits context/ entirely and the README says "bring your own
identity (/init-robin)." Never copy MEMORY.md into either shape by default.
Fill the manifest fields from reference.md (name, description, version 0.1.0,
author, MIT). The skills are what CC/Codex load automatically from a plugin;
the identity + loop travel as bundled files that the README explains how to
place/arm (be honest that installing the plugin makes the skills live, and the
identity/loop are a copy-in step) — don't overclaim that a plugin auto-installs a
CLAUDE.md.
Step 5 — Confirm the file list, THEN zip
Show the full tree + a one-line size. Ask: "Ship these?" On yes, zip it
(reference.md → "Zip it"). On any hesitation, adjust the selection — never zip
past a maybe.
Step 6 — Test-load it (prove it installs)
Load the bundle back to prove it's real:
- Claude Code:
claude --plugin-dir ./my-cos-v0.1 → confirm the shipped skills
appear (e.g. /personal-os:<skill> or the plain name).
- Codex: the equivalent plugin-add flow from
reference.md.
If a skill doesn't show, fix the manifest/paths and re-load before declaring done.
Never end on an untested zip.
Step 7 — Pair-swap (make "I have an OS" real)
Walk the Workshop-5 pair exercise:
- Send your
.zip to your partner (and get theirs).
- Unzip +
claude --plugin-dir ./their-cos (isolate it — a fresh folder, so their
identity doesn't clobber yours).
- Run one task through their Robin.
- File one issue — the smallest thing that broke or confused you — back to them.
Fallback if a partner isn't ready: install the instructor's sample plugin
(demos/sample-cos-plugin.zip) and run a task through that. Same lesson: your OS
is portable, and installing someone else's is one command.
Notes for you (the assistant running this)
- Secrets rule is absolute. When in doubt, exclude and tell the user. A leaked
token in a shared plugin is the one unforgivable failure of this skill.
- Small + coherent > big + dumped. 3 skills someone can read.
- Co-equal: write both manifests; test-load on whichever platform you're on.
--plugin-dir is the CC install; use the Codex plugin flow on Codex.
- Don't overclaim. Plugins auto-load skills; identity + loop are a documented
copy-in. Be precise so the student trusts the artifact.
- Versioning: default
0.1.0. On re-run, bump patch and re-zip; keep the old
zip so they can roll back. This is their OS's first release — name it like one.
- Power-user variant (Vitaly): publish the plugin to a public GitHub repo +
--plugin-url / the marketplace manifest, so others install with one line. Keep
the secrets scan even stricter for a public repo.
