How to improve collaboration by making skills and projects multiplayer

Claude and ChatGPT are single-player by default. You open a chat, do good work, and the result stays with you and in your files. Teams notice this quickly: people paste results into Slack or share finished docs, but they can't easily iterate together. The usual reflex is to reach for a shared workspace (Notion or Drive) and call it collaboration.

Key takeaway: By making skills and projects multiplayer (durable, shareable, and versionable), teams can collaborate more effectively and iterate together, closing the gap left by single-player chat tools.

The three layers of multiplayer

I find it easier to reason about once you separate it into three layers:

1. Shared context (org memory): Everyone works from the same inputs and knowledge base.

2. Shared output (artifact repository): Results are stored in durable places so others can build on them, not just pasted in Slack. (The knowledge base from the next section, or a workspace like Notion or Drive. Keep it to one place.)

3. Shared process (skills): Everyone runs a given task the same way, with the same guardrails, so you stop reinventing the prompt, and you can improve the method as a team.

A shared knowledge base pattern (Obsidian vault as the team brain)

To enable shared context, keep your team's knowledge in a plain-text, version-controlled system. An Obsidian vault backed by git works well, because it is just Markdown files: diffable, reviewable, and usable by both people and Claude. Other options include Linear project docs or a GitHub repo.

Use a single vault accessible to all. Store decisions, runbooks, naming conventions, standard operating notes, and project writeups as Markdown. Rely on the vault as the context source to reduce dependency on Slack threads or memory.

• Skills should reference the vault rather than duplicate it. Have the skill refer directly to the vault ("pull the relevant runbook from the vault, then proceed") instead of embedding a copy of the knowledge inside. The skill is the method, the vault is the knowledge source. Keep them separate so changes in one do not disrupt the other.
• Writeups go back into the vault in a stable location and format whenever a skill produces durable work such as decisions, postmortems, or specs. This is what lets others build on completed work.
• Git is the collaboration layer. Edits to the vault are commits. Disagreements about "how we do X" become PRs and reviews, not debates that evaporate in chat. Every project leaves the team's brain a little smarter, and every new skill can draw on all of it.

How to make a multiplayer skill

A skill is a Markdown file, which already makes it shareable. To make it genuinely multiplayer, version it in a repo so the method can be reviewed and improved like code.

• Version the skill in git so methods are reviewable, changeable, and revertible. A required review step is itself multiplayer: a second person signs off before a change ships, the same way a code review works.
• Distribute it as a single installable package, not as files people copy by hand. The problem with sharing skills as loose Markdown is that everyone ends up with a slightly different copy. A Claude Code plugin marketplace fixes this. It is a repo with a .claude-plugin/marketplace.json file that lists your skills as plugins. Each teammate runs a single command to connect to it:

claude plugin marketplace add <owner>/<repo>

With this approach, everyone installs the same skills from a centralized source. Changing a skill in the repo updates it for the whole team once each person refreshes the marketplace (see the update step below). For private playbooks, use a private repo with marketplace.json and point the install command to it.

• Standardize the entry point. When everyone says financial pulse and gets the identical workflow, the interface is shared even though each session is private. Put those phrases in the skill's description (and the optional when_to_use field), which is what Claude reads to decide when to invoke the skill.
• Point at shared systems of record via MCP. Skills that read from the team's real tools (Ramp, Monday, Gmail, a shared vault) keep state in those systems, not in a chat transcript. This is the direct antidote to "people keep pasting paragraphs into Slack."
• Define where the output lands. A multiplayer skill should not end by dumping a wall of text into the chat. It should write its result back to the same hub it reads context from (your vault, or a Notion DB or Monday board if that is your hub) in a stable format, so the output is durable and the next person can build on it. Pick one hub per output type and say so in the skill.
• Make handoffs explicit. Org multiplayer is one person's skill output becoming another person's skill input. For example, a finance agent can hand off to a subscription-canceling skill and an expense tracker. Name the upstream and downstream skills so the chain is obvious.

Making a Claude Project multiplayer

After making skills collaborative, the next step is to make the whole Claude Project multiplayer.

Include the skill in the Project instructions. Insert the skill body into the shared Project instructions so everyone using that Project runs the same method. Update it once to keep the team aligned.

• Attach the shared context. Connect the Project to the shared knowledge base or the relevant documents so each conversation starts with the same information. Do not rely on each participant to paste their own context.
• Name the output hub. In the Project instructions, specify where finished work should be placed and in what format. Make this explicit as part of the method, not a personal afterthought.

Setting this up, step by step

You can stand up the basic version in an afternoon. Each step builds on the last.

1. Create the shared hub. Make a git repo of Markdown files and open it as an Obsidian vault (or use a Notion/Drive space if that is where your team works). Add a few starter notes: a decisions/ folder, a runbooks/ folder, and a README that says what goes where.

mkdir team-vault && cd team-vault && git init -b main
mkdir decisions runbooks
printf '# Team vault\n' > README.md
touch decisions/.gitkeep runbooks/.gitkeep
git add -A && git commit -m "Start the team vault"
# push to a shared remote so teammates can clone it and skills can pull/push:
git remote add origin <your-vault-repo-url>
git push -u origin main

(Git does not track empty folders, so the README.md and .gitkeep files are what make the first commit non-empty. The remote matters: skills that pull the latest context and push results back need the vault to track a shared origin.)

2. Create the skills repo. Make a second repo for your skills, with each skill in its own folder as a SKILL.md and a .claude-plugin/marketplace.json that lists them as plugins. For a complete, copyable example (a shared vault plus a skills pack that reads from it and writes back to it), see the multiplayer setup example.

3. Connect the team. Each teammate registers the marketplace, then installs the plugin from it:

claude plugin marketplace add <owner>/<skills-repo>
/plugin install <plugin-name>@<marketplace-name>

The add command only registers the marketplace. The /plugin install step (run inside Claude Code) is what actually pulls in the plugin and exposes its skills. To pick up later changes, teammates refresh the catalog and then update the plugin: /plugin marketplace update <marketplace-name> followed by /plugin update <plugin-name>@<marketplace-name>. Third-party marketplaces do not auto-update by default, so either tell people to run those commands or enable auto-update for the marketplace under /plugin.

4. Write the first skill so it uses the hub. In the skill body, tell it to read the relevant note from the vault before it starts, and to write its result back to a stable path when it finishes. For example: "Read runbooks/competitor-intel.md, run the analysis, then write the brief to outputs/competitor/<competitor-slug>-<date>-<time>.md." The skill is the method, the vault holds the inputs and the outputs.

5. Wire a shared Project. Create a Claude Project, paste the skill body into the Project instructions, and attach the vault (or the relevant docs) as context. Now anyone who opens the Project runs the same method against the same knowledge.

One caveat: a web Claude Project cannot read local paths or run git, so a filesystem-backed skill (one with ${VAULT_PATH} reads and a git publish step, like the example) is a Claude Code workflow. In a web Project, attach the vault as project knowledge for context and have the skill return the finished result in chat for someone to save into the vault, rather than reading and writing the disk itself.

6. Set the review habit. Changes to a skill or a vault note go through a pull request, not a Slack message. One person opens the PR, a second signs off before it merges. That is how the method improves as a team instead of forking into private copies.

After this, the loop runs on its own: people run skills, results land in the hub, the next person starts from that work, and improvements to the method ship through PRs.

A short checklist for a multiplayer workflow

Before you call a workflow "multiplayer," check:

• The method lives in a versioned file, not in someone's head or a Slack thread.
• Installing it is one command (a plugin pack) or one paste (Project instructions), and everyone installs the same version.
• The entry point is standardized (a trigger phrase or a named Project).
• Context is read from a shared source, not re-pasted per person.
• Output is written to one durable hub in a stable format, not dumped into chat.
• Changes to the method go through review (a PR), so the team improves it together instead of forking private copies.

What to use for what

Notion and Drive can be the right place for finished work to land. Use them for that. But a shared workspace stores documents, it does not run your process the same way every time, so do not expect it to make the work repeatable.

Anthropic will keep improving shared context and org memory, so you do not have to solve that part yourself. What no vendor ships is your team's specific way of doing your specific work. That part is yours to write down, and the durable place to keep it is a versioned skills repo plus one shared hub.

If you want to see the kind of skills and agents this works with, the catalog is at skillsandagents.co.

If this problem is interesting to you, or you have faced it, reach out and let's chat. We ware working on finding a way to solve this problem.