Skip to main content

Using skillshare in Dev Containers

Open in VS Code, skills are ready — no local install needed.

Prerequisites​

How It Works​

VS Code Dev Containers let you develop inside a Docker container. You define the environment in .devcontainer/, and VS Code handles the rest — open the project, click "Reopen in Container", and everything is ready.

skillshare fits naturally into this workflow. Add it to postCreateCommand and skills are installed and synced when the container starts.

Setup​

Add two things to your .devcontainer/devcontainer.json:

{
  "postCreateCommand": "curl -fsSL https://raw.githubusercontent.com/runkids/skillshare/main/install.sh | sh && skillshare init --no-copy --all-targets --no-skill && skillshare sync"
}

That's it. When a team member opens the project in VS Code and clicks "Reopen in Container":

  1. skillshare is installed automatically
  2. init runs non-interactively — adds all detected AI CLI targets, skips copy prompts and built-in skill installation
  3. sync delivers skills to all targets

Adding Project Skills​

For team-shared skills, commit a .skillshare/ config to the repo:

# Inside the container
skillshare init -p
skillshare install your-org/team-skills -p

Then commit and update postCreateCommand to also sync project skills:

{
  "postCreateCommand": "curl -fsSL https://raw.githubusercontent.com/runkids/skillshare/main/install.sh | sh && skillshare init --no-copy --all-targets --no-skill && skillshare sync && skillshare sync -p"
}

Now every team member gets the same skills when they open the container.

GitHub Codespaces​

The same .devcontainer/ config works in Codespaces with no changes. Codespaces runs postCreateCommand the same way VS Code does.

Isolated Testing with ssenv​

Inside the devcontainer, ssenv lets you create isolated skillshare environments for parallel testing. Each environment gets its own HOME directory with separate config, skills, and targets.

CommandWhat it does
ssnew <name>Create a new isolated environment
ssuse <name>Switch to an environment
ssbackReturn to the original environment
sslsList all environments
ssrm <name>Delete an environment
ssnew demo && ssuse demo    # Create and switch
ss init && ss sync          # Commands run in isolation
ssback                      # Return to original

This is useful for testing config changes or skill installations without affecting your main setup.

What's Next?​