Here's how to set up multiple accounts properly, and how to stop manually copying skills, rules, and hooks between them.

Why Multiple Accounts?​

A few common scenarios:

• Personal + Work — your company pays for a team plan, but you also have your own subscription for side projects
• Personal + Client — a client added you to their org, but you want to keep your own setup separate
• Multiple orgs — you consult for several companies, each with their own Claude Code team

The problem is always the same: you've built up a collection of skills, rules, hooks, and agents in one account, and now you need them in the others too.

Step 1: Set Up Multiple Accounts​

Claude Code stores everything in ~/.claude/ by default. To add a second account, create a separate directory and point Claude at it with CLAUDE_CONFIG_DIR.

# Create a new config directory for your work account
mkdir -p ~/.claude-work

Then add aliases to your ~/.zshrc (or ~/.bashrc):

# Personal account (default)
alias claude="claude"

# Work account
alias claude-work="CLAUDE_CONFIG_DIR=~/.claude-work claude"

Reload and log in:

source ~/.zshrc
claude-work   # follow the login flow for your work account

That's it. claude uses your personal account, claude-work uses your work account. Each has its own API key, conversation history, and settings.

Need more accounts? Same pattern:

alias claude-client="CLAUDE_CONFIG_DIR=~/.claude-client claude"

Step 2: The Config Drift Problem​

After a week, here's what happens:

~/.claude/
├── skills/          ← 12 skills (you just added 2 new ones)
├── rules/           ← 5 rule files
├── hooks/           ← 3 hooks
└── agents/          ← 2 agent definitions

~/.claude-work/
├── skills/          ← 10 skills (missing the 2 new ones)
├── rules/           ← 3 rule files (missing 2)
├── hooks/           ← 1 hook (you forgot to copy the other 2)
└── agents/          ← 0 (you never set these up here)

You wrote a great debugging skill last Tuesday — but only in your personal account. Your work account still doesn't have it. Your carefully tuned rules about commit message style? Only in one place.

You could cp -r files around, but:

• You'll forget
• You'll overwrite something
• Files get out of sync silently
• Some accounts need different skills than others

Step 3: Sync Skills Automatically​

This is where skillshare comes in. Install it:

# macOS / Linux
curl -fsSL https://raw.githubusercontent.com/runkids/skillshare/main/install.sh | sh

# or via Homebrew
brew install skillshare

# Windows (PowerShell)
irm https://raw.githubusercontent.com/runkids/skillshare/main/install.ps1 | iex

Initialize and add your accounts as targets:

skillshare init

# Add each account's skill directory
skillshare target add claude ~/.claude/skills
skillshare target add claude-work ~/.claude-work/skills

Your config (~/.config/skillshare/config.yaml) now looks like:

targets:
  claude:
    skills:
      path: ~/.claude/skills
  claude-work:
    skills:
      path: ~/.claude-work/skills

Collect your existing skills into the source, then sync:

# Pull existing skills from your primary account into skillshare
skillshare collect claude

# Sync to all accounts
skillshare sync

Done. Both accounts now have the same skills.

Filtering: Different Skills for Different Accounts​

Not every skill belongs everywhere. Your personal side-project-ideas skill probably shouldn't show up at work:

targets:
  claude:
    skills:
      path: ~/.claude/skills
  claude-work:
    skills:
      path: ~/.claude-work/skills
      exclude:
        - "personal-*"
  claude-client:
    skills:
      path: ~/.claude-client/skills
      include:
        - "coding-*"
        - "commit"

Step 4: Sync Rules, Hooks, and Agents​

Skills are only part of the picture. You also want your rules (coding standards, locale preferences), hooks (auto-format on save, test runners), and agents synced across accounts.

skillshare's extras feature handles this — it syncs any directory, not just skills.

# Sync rules across accounts
skillshare extras init claude-rules \
  --source ~/.claude/rules \
  --target ~/.claude-work/rules

# Sync hooks
skillshare extras init claude-hooks \
  --source ~/.claude/hooks \
  --target ~/.claude-work/hooks

# Sync agents (use --flatten because Claude discovers agents at top level only)
skillshare extras init claude-agents \
  --source ~/.claude/agents \
  --target ~/.claude-work/agents \
  --flatten

Or put it all in the config:

extras:
  - name: claude-rules
    source: ~/.claude/rules
    targets:
      - path: ~/.claude-work/rules
        mode: merge
      - path: ~/.claude-client/rules
        mode: merge

  - name: claude-hooks
    source: ~/.claude/hooks
    targets:
      - path: ~/.claude-work/hooks
        mode: merge

  - name: claude-agents
    source: ~/.claude/agents
    targets:
      - path: ~/.claude-work/agents
        mode: merge
        flatten: true

Why merge mode? It creates per-file symlinks from target to source, so account-specific files (like settings.json or settings.local.json) are left untouched. Your shared config syncs; your account-specific config stays separate.

Now sync everything:

skillshare sync --all   # skills + extras in one command

The Daily Workflow​

Once set up, keeping accounts in sync takes three commands:

skillshare check        # any upstream skill updates?
skillshare update --all # pull latest versions
skillshare sync --all   # push to all accounts

Write a new skill in your personal account → skillshare sync → it's everywhere.

Full Config Reference​

Here's a complete three-account setup:

# ~/.config/skillshare/config.yaml
targets:
  claude:
    skills:
      path: ~/.claude/skills
  claude-work:
    skills:
      path: ~/.claude-work/skills
      exclude:
        - "personal-*"
  claude-client:
    skills:
      path: ~/.claude-client/skills
      include:
        - "coding-*"
        - "commit"

extras:
  - name: claude-rules
    source: ~/.claude/rules
    targets:
      - path: ~/.claude-work/rules
        mode: merge
      - path: ~/.claude-client/rules
        mode: merge

  - name: claude-hooks
    source: ~/.claude/hooks
    targets:
      - path: ~/.claude-work/hooks
        mode: merge

  - name: claude-agents
    source: ~/.claude/agents
    targets:
      - path: ~/.claude-work/agents
        mode: merge
        flatten: true

Bonus: Manage Everything from the Web UI​

Prefer a visual interface over YAML? Over half of skillshare users manage their setup through the built-in web dashboard instead of editing config files by hand.

skillshare ui

This opens a dashboard at localhost:19420 where you can:

• View and manage all skills, targets, and extras
• Install new skills from GitHub with one click
• Run sync, audit, and check operations visually
• Edit target include/exclude filters without touching YAML

Everything you can do in the CLI, you can do in the UI — including setting up the multi-account extras config described above.

Quick Tips​

• Pick one primary account as the source of truth. Edit skills, rules, and hooks there; sync to the rest.
• Preview before syncing — skillshare sync --all --dry-run shows what will change.
• Flatten agents — Claude Code only discovers agents at the top level, so always use flatten: true for agent directories.
• Backup first — skillshare backup snapshots your current state before changes.

Get Started​

curl -fsSL https://raw.githubusercontent.com/runkids/skillshare/main/install.sh | sh
skillshare init

• GitHub
• Documentation
• Extras reference
• Sync modes explained

The Problem​

Claude Code stores skills in ~/.claude/skills/. Over time, you accumulate skills from different sources — some you wrote, some from teammates, some from GitHub. Without structure, it becomes hard to track what's installed, what's outdated, and what conflicts with what.

Step 1: Install skillshare​

curl -fsSL https://raw.githubusercontent.com/runkids/skillshare/main/install.sh | sh

Or via Homebrew (macOS/Linux):

brew install skillshare

Verify:

skillshare version

Step 2: Initialize​

skillshare init

This creates a source directory at ~/.config/skillshare/skills/ and auto-detects Claude Code as a sync target.

Step 3: Import Your Existing Skills​

Already have skills in ~/.claude/skills/? Collect them into your source:

skillshare collect

skillshare copies each skill from Claude Code's directory into your source. Now you have a single place that holds everything.

Step 4: Install a Skill from GitHub​

Let's add a popular skill set:

skillshare install anthropics/courses/prompt-eng

This clones the repository and places skills in your source directory. Run skillshare list to see everything:

skillshare list

Step 5: Sync​

skillshare sync

By default, skillshare uses merge mode — creating per-skill symlinks from your source into ~/.claude/skills/. Your original local skills are preserved — only new ones are added.

Step 6: Verify​

Open Claude Code and check that your skills are available:

claude
# Inside Claude Code, your skills should be loaded

Symlink Not Working? Use Copy Mode​

Some platforms and tools have inconsistent symlink support — WSL, certain Docker setups, or AI tools that don't follow symlinks. If you run into issues:

skillshare target claude --mode copy
skillshare sync

Copy mode physically copies skill files instead of symlinking. The trade-off:

See Sync Modes for the full comparison.

What You Get​

After these steps:

• Single source of truth — all skills live in ~/.config/skillshare/skills/
• Non-destructive sync — local Claude Code skills are untouched
• Version tracking — installed repos are tracked for updates via skillshare check
• Backup ready — skillshare backup snapshots your entire skill library

Next Steps​

• Set up multi-tool sync if you also use Cursor, Codex, or other tools
• Create your first custom skill
• Share skills with your team

The Setup​

My daily toolkit:

• Claude Code — primary coding assistant
• Cursor — IDE-integrated AI
• Codex — quick prototyping and script generation

Each tool has its own skill directory, its own format quirks, and its own update cycle. Without skillshare, I was manually copying files between three locations every time I changed a skill.

Directory Structure​

After skillshare init, my source looks like this:

~/.config/skillshare/skills/
├── _anthropics__courses__prompt-eng/   # tracked repo
├── _team__frontend/                    # team shared
├── code-review/                        # my custom skill
├── commit-message/                     # my custom skill
├── debugging/                          # organized into folders
├── testing/
└── frontend/
    ├── react-patterns/
    ├── css-guidelines/
    └── accessibility/

Skills prefixed with _ are tracked repositories. The rest are local skills organized into logical groups.

Organizing with --into​

The --into flag places installed skills into subdirectories:

skillshare install user/repo --into frontend
skillshare install another/repo --into backend

This creates a clean hierarchy without flat-file chaos.

Multi-Target Sync​

Global config targets use a map format:

targets:
  claude:
    skills:
      path: ~/.claude/skills
  cursor:
    skills:
      path: ~/.cursor/skills
  codex:
    skills:
      path: ~/.codex/skills

One skillshare sync pushes all 50+ skills to all three tools simultaneously. Each target gets per-skill symlinks, so tool-specific local skills remain untouched.

Per-Target Mode and Filtering​

You can set a different sync mode per target, and use include/exclude patterns to control which skills go where:

targets:
  claude:
    skills:
      path: ~/.claude/skills
      mode: merge
  cursor:
    skills:
      path: ~/.cursor/skills
      mode: copy          # copy mode for better compatibility
      exclude:
        - "_experimental*"
  codex:
    skills:
      path: ~/.codex/skills
      mode: merge
      include:
        - "coding-*"

Daily Workflow​

My morning routine takes about 30 seconds:

# Check for upstream updates
skillshare check

# If updates available
skillshare update --all

# Sync to all targets
skillshare sync

That's it. Three tools, 50+ skills, one command chain.

Handling Conflicts​

Occasionally, a tool creates a skill with the same name as one in my source. skillshare handles this gracefully:

• In merge mode, the symlink points to your source skill
• The target's original file is not deleted — it's simply overshadowed by the symlink
• Running skillshare diff shows exactly what differs between source and target

Backup Strategy​

Before major changes, I snapshot:

skillshare backup

Backups are stored in ~/.local/share/skillshare/backups/ with timestamps. To restore a specific target:

skillshare restore claude

Key Takeaways​

1. One source, many targets — the fundamental principle
2. Use --into for organization — avoid flat directory sprawl
3. Check + update + sync — the daily three-command chain
4. Backup before experiments — it takes 2 seconds and saves hours

Resources​

• Multi-tool quickstart
• Organizing skills guide
• Backup & restore guide

What They Have in Common​

Both tools solve the same core problem: managing AI skill files across 40+ coding agents (Claude Code, Cursor, Codex, etc.). Both offer:

• Install skills from Git repositories (GitHub, GitLab, and other hosts)
• Sync to multiple AI tool targets
• Support for symlink and copy modes
• Project-level and global skill management
• Security audit before installation

Where vercel/skills Shines​

Best for quick, curated installs:

• Runs via npx skills — no binary installation needed if you have Node.js
• Curated skill discovery via npx skills find with interactive selection
• Server-side security audit powered by Snyk — skills on the catalog are automatically scanned and flagged
• Strong Vercel/Next.js ecosystem integration
• Familiar npm-based workflow for JavaScript developers

Use vercel/skills when:

• You're already in the Node.js ecosystem
• You primarily install from the skills.sh catalog (which provides pre-audited skills)
• You want a curated, community-driven skill catalog
• You prefer npx-based tooling with no permanent install
• Your workflow is primarily single-machine, single-project

Where skillshare Shines​

Best for multi-tool sync, multi-platform, and team workflows:

• Single binary — no Node.js, npm, or runtime dependencies
• Any Git host — GitHub, GitLab, Bitbucket, Gitea, Azure DevOps, AtomGit, Codeberg, self-hosted, and any HTTPS/SSH git server
• Bidirectional sync: collect skills from targets back to source
• Cross-machine sync via push/pull
• Fully customizable security audit — 15+ detection patterns, configurable block thresholds, custom rules to enable/disable individual patterns, and multiple output formats (text, JSON, SARIF, Markdown). Runs locally on any skill source — no server dependency
• Pre-commit hook integration via the pre-commit framework
• Backup/restore with timestamped snapshots
• Web dashboard (skillshare ui)
• Organization-wide skill distribution via tracked repos
• Works offline (core operations need no network)

Use skillshare when:

• You use multiple AI tools and need one source of truth
• Your skills live on GitLab, Bitbucket, Azure DevOps, or self-hosted Git — not just GitHub
• You work across multiple machines
• Your team needs standardized skills via git
• You need customizable security scanning — your own rules, thresholds, and CI integration for any skill source (not just a public catalog)
• You want zero runtime dependencies (CI/CD, Docker, air-gapped environments)

Feature Comparison​

Migrating from vercel/skills​

If you decide to switch, the process is straightforward:

Step 1: Install skillshare​

curl -fsSL https://raw.githubusercontent.com/runkids/skillshare/main/install.sh | sh
skillshare init

Step 2: Collect existing skills​

If vercel/skills already synced skills to your AI tool directories:

skillshare collect

This copies skills from your target directories into skillshare's source.

Step 3: Sync​

skillshare sync

Step 4: Ongoing updates​

skillshare check          # Detect upstream changes
skillshare update --all   # Apply updates
skillshare sync           # Push to all tools

Can They Coexist?​

Yes. Both tools use symlinks (or copies) to the same target directories. However, running both simultaneously on the same targets may cause conflicts — one tool's symlinks may be overwritten by the other. If you're evaluating both, use them on separate targets or test one at a time.

Resources​

• Migration guide
• Install command reference
• Security audit guide

Pattern 1: Shared Git Repository​

Best for: Small teams (2-5 people) who want a quick start.

Create a Git repository with your team's skills:

team-skills/
├── code-review/
│   └── SKILL.md
├── pr-description/
│   └── SKILL.md
└── testing-standards/
    └── SKILL.md

Each team member installs it:

skillshare install your-org/team-skills
skillshare sync

When someone updates a skill, others pull changes:

skillshare check              # "team-skills: 2 skills updated"
skillshare update --all       # Apply all available updates
skillshare sync

Pros: Simple, familiar Git workflow, works with any Git host.

Cons: Everyone gets all skills, no per-project customization.

Pattern 2: Organization-Wide + Project-Scoped​

Best for: Medium teams (5-20 people) with different projects.

Split skills into two layers:

Organization Layer (global)​

Shared standards that apply everywhere:

skillshare install your-org/org-skills

These live in ~/.config/skillshare/skills/ and sync to all tools on every machine.

Project Layer (scoped)​

Project-specific skills committed to the project repo:

cd your-project
skillshare init -p
skillshare install your-org/frontend-skills -p
git add .skillshare/
git commit -m "Add project skills"

Team members get project skills automatically when they clone and run:

skillshare sync -p

Pros: Organization standards + project flexibility. Skills travel with the code.

Cons: Two sync commands (global + project). Requires project setup.

Pattern 3: Hub Index (Registry)​

Best for: Large teams or open-source communities.

Generate a hub index from your source skills:

skillshare hub index --source ./skills --output ./skillshare-hub.json

This creates a JSON file listing all available skills with metadata. Host it on GitHub Pages or any HTTPS URL, then register it:

skillshare hub add https://your-org.github.io/skillshare-hub.json --label team
skillshare hub default team

Team members can then browse and install:

skillshare search --hub https://your-org.github.io/skillshare-hub.json
skillshare install your-org/skills --skill code-review

Pros: Discoverable, self-service, scales to hundreds of skills.

Cons: Requires maintaining the index. More setup upfront.

Choosing a Pattern​

Most teams start with Pattern 1 and evolve to Pattern 2 when they need project-specific skills. Pattern 3 is for organizations that want a curated skill catalog.

Getting Started​

Regardless of pattern, the workflow is the same:

skillshare install <repo>    # Add skills
skillshare sync              # Push to tools
skillshare check             # Detect updates
skillshare update --all      # Apply updates

Resources​

• Organization sharing guide
• Project setup guide
• Hub index guide

What Is a Skill?​

A skill is a SKILL.md file inside a named directory. It contains instructions that AI coding tools (Claude Code, Cursor, Codex, etc.) load as context when working on your code.

my-skill/
└── SKILL.md

That's the minimum. The SKILL.md file has two parts: frontmatter (metadata) and body (the actual instructions).

Step 1: Scaffold with skillshare new​

skillshare new my-code-review

This creates ~/.config/skillshare/skills/my-code-review/SKILL.md with a template:

---
name: my-code-review
description: >-
  Describe what this skill does. Use when user asks to
  "trigger phrase 1", "trigger phrase 2", or needs help
  with a specific task.
# targets: []           # e.g. [claude, cursor] — omit for all targets
# metadata:
#   author: Your Name
#   version: 1.0.0
---

# My Code Review

Brief overview of what this skill does and its value.

Step 2: Write the Instructions​

Replace the template body with clear, actionable instructions. Good skills are:

• Specific — tell the AI exactly what to do, not vague guidelines
• Scoped — one skill, one concern (code review, testing, commit messages)
• Contextual — explain when to apply the instructions

Here's an example code review skill:

---
name: my-code-review
description: >-
  Enforce team code review standards. Check for security,
  error handling, input validation, and style compliance.
targets: [claude, cursor]
---

# Code Review Standards

When reviewing code (PR reviews, code suggestions, refactoring):

## Must Check
- No hardcoded secrets or credentials
- Error handling for all external calls (API, DB, file I/O)
- Input validation at system boundaries
- Tests for new public functions

## Style
- Functions under 30 lines
- No more than 3 parameters per function
- Early returns over nested conditionals
- Descriptive variable names (no single letters except loop counters)

## Response Format
- List issues by severity: critical > warning > suggestion
- Include file path and line number for each issue
- Suggest fixes, don't just flag problems

Step 3: Security Scan​

Before sharing, audit your skill:

skillshare audit

This checks for patterns that could be harmful: prompt injection, data exfiltration, destructive commands. Even well-intentioned skills can accidentally trigger these patterns.

Step 4: Sync and Test​

skillshare sync

Now open your AI tool and test the skill. Ask it to review some code and check whether it follows your instructions.

Step 5: Share​

Option A: Commit to a shared repo​

# Copy to a team repository
cp -r ~/.config/skillshare/skills/my-code-review /path/to/team-skills/
cd /path/to/team-skills
git add my-code-review/
git commit -m "Add code review skill"
git push

Team members install with:

skillshare install your-org/team-skills --skill my-code-review

Option B: Project-scoped skill​

cd your-project
skillshare init -p
cp -r ~/.config/skillshare/skills/my-code-review .skillshare/skills/
git add .skillshare/
git commit -m "Add project code review skill"

Anyone who clones the repo gets the skill automatically.

Controlling Where Skills Sync​

Per-skill target restriction​

Add a targets field to SKILL.md frontmatter to limit which AI tools receive this skill:

---
name: claude-only-skill
description: Only syncs to Claude Code
targets: [claude]
---

Skills without a targets field sync to all configured targets.

Per-target filtering​

In your config, use include/exclude patterns to control which skills each target receives:

targets:
  claude:
    skills:
      path: ~/.claude/skills
      exclude:
        - "experimental-*"
  cursor:
    skills:
      path: ~/.cursor/skills
      include:
        - "coding-*"
        - "review-*"

.skillignore for repositories​

If you publish a skill repository, add a .skillignore file to exclude internal/test skills from installation:

# .skillignore — skills to exclude during install
internal-testing
experimental
debug-*

Patterns support exact names, group prefixes, and trailing wildcards.

Tips for Effective Skills​

1. Keep the description under 1024 characters — Codex enforces this limit
2. Use headers for structure — AI tools parse Markdown headers for context
3. Be imperative — "Check for X" not "It would be good to check for X"
4. Include examples — Show the AI what good output looks like
5. Use targets to scope — Not every skill makes sense for every tool

Resources​

• Creating skills guide
• Skill format reference
• Best practices