Share Your Foundation

share-your-foundation

The problem this solves: you spent Levels 1–3 building a real foundation — the house rules your agent follows (CLAUDE.md), the skills you wrote or adopted, the brand kit that makes everything sound like you. Right now that foundation lives in one place: the machine you built it on. A teammate who wants the same setup gets a Slack thread of "copy this file, then install that, then paste these rules" — and ends up with a slightly-different, already- drifting version of your stack. Worse, you hit the same wall between your own two machines: the setup you rely on at your desk isn't the one on your laptop.

This skill fixes that with one move, borrowed from how software teams ship the same code to every machine:

Put your foundation in one repo. A teammate clones it and runs one install command. An update is a pull, not a re-send.

That's the whole thing. Your rules, your skills, your brand — one versioned repo, one command to install, and everyone (including future-you on a new laptop) runs the exact same setup.

Why an owner should care, in money terms: every hour a new hire spends recreating your setup by hand is an hour they're not billing, and every drifted copy is a client deliverable that doesn't match your standard. A shared foundation means a new teammate is producing work to your bar on day one, not week three — that's the offense. The consistency it buys is the enabler underneath, not the headline.

Say this to your agent

"Package my agent foundation into one repo I can share. Take my house rules (my CLAUDE.md), my skills folder, and my brand kit, put them in a my-foundation/ repo with a single install.sh that a teammate runs after cloning, and a README that explains the one command. Make updating it a git pull, not a re-send."

That one line is the whole ask. Below is what it actually builds.

The 3-step setup

Step 1 — Build the foundation repo

Run the bootstrapper once. It scaffolds a my-foundation/ repo with the four things a teammate needs and nothing they don't:

bash bootstrap.sh --out ./my-foundation

That creates:

my-foundation/
  CLAUDE.md          your house rules — the standards every agent run follows
  skills/            your skills (one folder per skill), the capabilities you built
  brand/             your brand kit — voice, audience, style, so output sounds like you
  install.sh         the ONE command a teammate runs after cloning
  README.md          "clone this, run ./install.sh" — the whole onboarding, one page

By default the bootstrapper drops in a starter CLAUDE.md and an empty skills/ + brand/ for you to fill. If you already have a setup on this machine, point it at your real files and it copies them in for you:

bash bootstrap.sh --out ./my-foundation \
  --claude ~/.claude/CLAUDE.md \
  --skills ~/.claude/skills \
  --brand  ~/brand-kit.md

What good looks like: open my-foundation/ and everything a teammate would need to be you is sitting in one folder — the rules, the skills, the brand — with a README that tells them the single command to run. Nothing about your machine, your logins, or your clients is in there (see the safety note below).

Step 2 — Put it in a shared repo (the "share" part)

A folder on your laptop isn't shared — a repo is. Initialize it, commit, and push to wherever your team already lives (GitHub, GitLab, a private repo — your call):

cd my-foundation
git init && git add -A && git commit -m "My agent foundation v1"
# push to your team's git host, then send the clone URL — that's the last time you "send" it

From now on, "sharing your setup" is sharing a clone URL once. When you improve a rule or add a skill, you commit and push; your teammates (and your other machine) run git pull and they're current. No more "which version of the CLAUDE.md are you on?"

Step 3 — A teammate clones and runs one command

This is the payoff. Your teammate — or you, on a fresh machine — does exactly this:

git clone <your-foundation-repo-url> my-foundation
cd my-foundation
bash install.sh

install.sh installs your foundation into their agent, additively and safely:

• Skills are copied into their agent's skills directory (~/.claude/skills/ by default) — purely additive, it never deletes skills they already have.
• Your CLAUDE.md is installed as their house rules — and if they already have one, the installer backs it up to CLAUDE.md.bak first and tells them, so nothing is lost.
• Your brand kit is placed where their agent can find it, so output sounds like your shop from the first run.

It prints exactly what it did and how to check it. Restart the agent, and the teammate is running your exact foundation.

What a good result looks like

• There's one repo that holds your rules + skills + brand, versioned in git.
• A teammate goes from nothing to your exact setup with git clone + bash install.sh — minutes, not a week of back-and-forth.
• An update is a git pull, not a re-send — you fix a rule once and everyone gets it.
• Your own second machine installs the same way: the setup finally follows you, instead of living on one laptop.
• Nothing private ships in the repo — no logins, no API keys, no client data (see below).

Concretely: you can hand the clone URL to a new hire on their first morning and by lunch their agent produces work to your standard — because it is your standard, installed verbatim.

The one thing to keep OUT of the repo (safety)

A shared foundation is your standards, not your secrets. Before you push, make sure the repo contains only shareable config:

• Never commit API keys, tokens, .env files, or login/session files. The bootstrapper writes a .gitignore that blocks the common ones (.env, *.key, credentials*, *.pem), but you own the final check — skim the file list before your first commit.
• Never commit client data or anything under NDA. Brand kit = your voice/style, not a client's private material.
• Keep it to the four things: house rules, skills, brand, the installer. If you're unsure whether something belongs, it doesn't.

If your foundation must carry a secret to work (rare), the right pattern is an .env.example with blank placeholders that the teammate fills in locally — the shape of the secret is shared, never the secret itself.

How this pairs with the other skills

• determinism-pattern — teaches "one skill per repeatable process, versioned in a shared repo, with a judge as the gate." This skill is that shared repo, made concrete: the place your versioned skills live so a fix reaches every machine and teammate on the next pull.
• brand-kit-from-url — builds the brand kit once. This skill is how that brand kit stops being yours alone and becomes your whole team's default voice.
• capability-map — shows what your stack can and can't do. Share the foundation and your teammate inherits the whole map, not a partial copy of it.
• host-your-agent — the same clone-and-install move that puts your foundation on a teammate's machine also stands your setup up on an always-on box you host the agent from.

Where things land

Read README.md in this folder for the copy-paste quickstart.

The rules it runs under (why the setup stays identical everywhere)

• One repo is the one copy of the truth. Rules, skills, brand — all in one versioned place; a fix reaches every machine and teammate on the next pull.
• One command to install. git clone + bash install.sh. If onboarding takes more than that, the foundation isn't packaged yet.
• Additive and reversible. Installing never deletes a teammate's existing skills, and it backs up any CLAUDE.md it replaces — nothing is lost.
• Standards, not secrets. Only shareable config goes in the repo; keys, sessions, and client data never do.

When those four things are true, "share your foundation with your team" stops being a Slack thread and becomes a clone URL — which is exactly what Level 4 asks for.