solidcodersolidcoder
Explore Courses
solidcodersolidcoder
CoursesAboutPrivacy PolicyTerms
© 2026 solidcoder · Practical courses for software engineering interviews.
Home/AI Engineering/Skills/Scoping a Skill: Personal, Project, or Team
Chapters — Skills▾

Scoping a Skill: Personal, Project, or Team

Claude Code Skills·Advanced·6 min read·Sep 6, 2026

Where a skill lives changes who benefits from it: a personal toolbox, a project-specific one, or a shared one everyone on a team gets.

Your toolbox, or the site's toolbox

A carpenter usually has two sets of tools: a personal toolbox they carry from job to job, and a shared set of tools that stays at one particular site because that's the only place they're needed. Neither is wrong. They solve different problems: one travels with the person, the other stays with the place.

Skills work the same way, and where one lives determines which of those two problems it solves.

Personal
Lives with you, available in every project you touch. Right for a way of working that's yours specifically, not tied to any one codebase.
Project
Lives inside one specific project's files. Right for something that only makes sense there: this repo's deployment steps, this codebase's review checklist.
Team or plugin-provided
Shared across everyone working on something, so the same standard applies no matter who's doing the work, without each person having to set it up individually.

Why this choice actually matters

Putting a genuinely project-specific skill in your personal collection means it quietly misfires or sits uselessly the moment you're working somewhere else. Putting a genuinely personal preference into a shared project skill means it starts showing up for teammates who never asked for it and don't want it. The scope isn't just a filing detail. It's a decision about who this skill is actually for.

A quick way to decide

Ask: if I handed this exact skill file to a teammate working on a completely different project, would it still make sense, or would it reference things specific to one particular codebase? A confident "still makes sense" points toward personal. A confident "no, this is specific to here" points toward project.

Specific beats general, one level at a time

When a skill exists at more than one scope, the more specific one usually wins for a good reason: a project's own conventions should be able to override general habits, on purpose, for the place where those conventions actually apply. This mirrors something worth remembering from the tool-design instinct in general: the version closest to the actual situation at hand is usually the one that should take priority.

Sort your own habits

Think of two things you find yourself explaining to Claude repeatedly. Is either one truly personal, something you'd want everywhere? Is either one truly tied to one specific project, something that would look out of place anywhere else? Notice which category each one actually falls into, it's often not the one you'd assume at first.

Up next1/3
Part 3 · Advanced
Next Chapter →
Avoiding Overlap and Trigger Confusion
7 min · continue reading
→
← Prev Section
Intermediate
Writing a Description That Actually Triggers
Part of a free guide

Skills

A simple guide to Claude Code Skills: what they are, and how to build your own.

Browse All Guides →
On this page
  • Your toolbox, or the site's toolbox
  • Why this choice actually matters
  • Specific beats general, one level at a time