Lesson 4 - Deploying and Sharing Skills

Learn the exact directories each platform watches, how precedence works when skills share a name, and how to promote skills from personal sandboxes to shared repositories safely.

Duration: 1.5-2 hours

Learning Objectives

By the end of this lesson, you will be able to:

  • Know the canonical paths for personal and project skills across major AI tools.
  • Promote a personal skill into a project repository with git-based review.
  • Explain priority resolution when duplicate skill names exist in multiple locations.
  • Evaluate community skills for security and quality before installing.

Videos

Personal Skills: Your Private Toolkit

Where to store skills that are just for you — your personal AI configuration that follows you across every project.

Duration: 7 minutes

Video coming soon

Project Skills: Sharing with Your Team via Git

Promote a skill from personal to project-level so everyone on the team benefits. Enforce review through pull requests.

Duration: 10 minutes

Video coming soon

Community Skills: Finding and Evaluating Shared Skills

How to discover community-built skills, evaluate them for safety, and install them responsibly.

Duration: 6 minutes

Video coming soon

Key Concepts

Directory Cheat Sheet

**Personal skills (just for you — available in all projects):** | Tool | Path | |------|------| | Claude Code | `~/.claude/skills/<name>/SKILL.md` | | GitHub Copilot | `~/.copilot/skills/<name>/SKILL.md` | | Cursor | `~/.cursor/skills/<name>/SKILL.md` | | Universal | `~/.agents/skills/<name>/SKILL.md` | **Project skills (shared via git — available to the team):** | Tool | Path | |------|------| | Claude Code | `.claude/skills/<name>/SKILL.md` | | GitHub Copilot | `.github/skills/<name>/SKILL.md` | | Cursor | `.cursor/skills/<name>/SKILL.md` | | Universal | `.agents/skills/<name>/SKILL.md` | **Note:** GitHub Copilot checks all three project directories. When in doubt, `.agents/skills/` is the most universal.

Priority Resolution: What Wins When Names Clash

When multiple skills share the same name, the most specific one wins: 1. **Project skills** override **personal skills** (team standards beat personal preferences). 2. **Enterprise skills** override both (organization policies win). **Example:** You have a personal `code-review` skill. Your project also has a `code-review` skill. The project version is used — because it reflects team conventions, not just yours. **Tip:** To avoid confusion, use distinct names: `my-code-review` (personal) vs. `code-review` (project).

Promotion Workflow: Personal → Project

Step-by-step guide to promoting a skill: **1. Validate the skill works consistently** (you've tested it 3+ times with different inputs). **2. Copy to the project directory:** ```bash cp -r ~/.claude/skills/deploy-checklist .claude/skills/deploy-checklist ``` **3. Commit and push:** ```bash git add .claude/skills/deploy-checklist/ git commit -m "Add deploy-checklist skill for team use" git push ``` **4. Open a pull request** with: - What problem the skill solves - Test evidence (screenshots or test log from Lesson 3) - How to invoke the skill **5. (Optional) Remove the personal copy** to avoid shadowing: ```bash rm -r ~/.claude/skills/deploy-checklist ``` Now everyone on your team gets the skill on their next `git pull`.

Security Checklist for Community Skills

Before installing any community skill, check: - [ ] **Read SKILL.md** — does the description match your use case? - [ ] **Audit scripts/** — look for `rm`, `curl`, `wget`, `eval`, or commands that modify files - [ ] **Check references/** — no secrets, credentials, or proprietary data - [ ] **Verify the source** — active repo? Recent commits? Issues addressed? - [ ] **Install to personal first** — test in your sandbox before promoting to project - [ ] **Note the commit hash** — document exactly which version you installed A skill with scripts/ can run commands on your machine. Treat it with the same caution as installing any software.

Common Mistakes & Pitfalls

Putting personal preferences in project skills

Project skills should reflect team conventions, not individual taste. Keep your personal quirks (favorite formatting, custom abbreviations) in personal skills.

Installing community skills without reading them

Always read SKILL.md and inspect scripts/ before installing. A skill with 'rm -rf' in a script could delete your files.

Forgetting to commit and push skill changes

Project skills only reach your team through git. Edit → commit → push. If you skip push, nobody else gets the update.

Using the wrong directory path for your tool

Each tool has specific paths. .claude/skills/ works for Claude Code but may not be discovered by Gemini CLI. Check the cheat sheet.

Not removing the personal copy after promotion

If both personal and project versions exist, the project version wins. But having two copies creates confusion about which to edit. Clean up after promoting.

Exercises

Exercise 1: Path Audit

10 minutes

Verify that the personal and project skill directories exist on your machine. Create any missing directories.

Expected Output:

Verified directory paths plus commands used to create any missing ones.

Success Criteria:

  • Confirmed the personal skill directory exists for your primary AI tool.
  • Confirmed the project skill directory exists (or created it).
  • Noted the exact paths for your OS and tool combination.

Exercise 2: Promote Your Skill to Project Level

20 minutes

Move your skill from personal to project directory, commit it to git, and verify it still works from the project location.

Expected Output:

A git commit containing your skill in the project skills directory.

Success Criteria:

  • Skill copied to the correct project directory.
  • Committed to git with a descriptive message.
  • AI tool recognizes the skill from the project directory.
  • Tested the skill still works after relocation.

Exercise 3: Community Skill Evaluation

20 minutes

Find a community skill, run the security checklist, and write a one-paragraph evaluation: adopt, fork, or reject.

Expected Output:

Completed security checklist plus your decision with justification.

Success Criteria:

  • Found a community skill and noted the source URL + commit hash.
  • Completed all items on the security checklist.
  • Wrote a clear decision (adopt/fork/reject) with reasoning.
  • If adopted, installed to personal directory and tested.

Lesson Reflection

Take a moment to reflect on what you've learned:

  • 1. Is your skill more of a personal preference or a team convention? Which tier does it belong at?
  • 2. If your team had a shared skills library, which 3 skills would save the most collective time?
  • 3. Have you ever wished a colleague followed the same process you do? That's a project skill waiting to be written.
  • 4. What would your security checklist look like for evaluating skills in a regulated industry?