Where are Claude Code skills stored?
Find every Claude Code skill location, choose personal or project scope, create a safe AEC SKILL.md, verify it, fix failures, and remove it cleanly.
Direct answer
Answer
Personal Claude Code skills are stored at ~/.claude/skills/<skill-name>/SKILL.md. Project skills are stored at .claude/skills/<skill-name>/SKILL.md inside a repository. Plugin skills remain inside the plugin, enterprise skills come from managed settings, and locally downloaded claude.ai skills use the reserved ~/.claude/skills/synced/ directory.
Audience + setup
Before you start
- For
- Architects and designers · BIM and digital-practice teams · AEC students and technologists
- Software context
- Claude Code skills documentation verified 26 August 2026; interface names and supported frontmatter can change in later releases.
- Prerequisites
- A current Claude Code installation · Write access to your home folder or test repository · A non-production AEC sample for verification
- Outcome
- Locate, create, verify, troubleshoot, disable, and remove a Claude Code skill without confusing personal, project, plugin, enterprise, or synced scopes.
01
Which Claude Code skill path should you use?
Choose the location by audience. Put a method used across all of your local projects in the personal folder. Put a team method beside one repository in the project folder so its instructions and supporting files can be reviewed and versioned with that project. Do not copy a plugin skill into either folder merely because it appears in Claude Code; plugin skills are namespaced and travel with their plugin.
On macOS and Linux, the tilde in ~/.claude means your home directory. Anthropic defines the same notation on Windows as %USERPROFILE%\.claude, so the personal skills folder is under that user profile. Enterprise paths depend on managed settings and should be obtained from the administrator rather than guessed.
- — Personal — ~/.claude/skills/<skill-name>/SKILL.md — available across your local projects
- — Project — .claude/skills/<skill-name>/SKILL.md — available for that repository
- — Plugin — <plugin>/skills/<skill-name>/SKILL.md — available where the plugin is enabled
- — Enterprise — .claude/skills inside the managed-settings directory — deployed by an administrator
- — Synced — ~/.claude/skills/synced/ — reserved for skills downloaded from an enabled claude.ai account
02
How does Claude Code discover project and monorepo skills?
Project discovery is broader than a single repository-root folder. Claude Code checks .claude/skills in the directory where the session starts and in parent directories up to the repository root. In a monorepo, it can discover a nested package skill after it first reads or edits a file inside that package; the nested skill then remains available for the session.
A directory supplied with --add-dir is a documented exception: Claude Code also loads .claude/skills from that added directory. A path added only through permissions.additionalDirectories grants file access but does not load skills. This distinction explains why a readable SKILL.md may still be absent from the command menu.
03
Is a skill the same as CLAUDE.md, a rule, or a plugin?
Use CLAUDE.md for short instructions that every session in the repository must know, such as build commands, file conventions, or a non-negotiable office rule. Use a skill for task-specific knowledge or a repeatable procedure that should load only when relevant or when someone invokes its slash command.
A plugin is a distribution container rather than a synonym for a skill. It can bundle skills with agents, hooks, or MCP configuration, and its skills use a plugin namespace. A project skill is simpler when an AEC team only needs a review checklist, handoff method, or documented task procedure in one repository.
- — CLAUDE.md — always-loaded core project instructions
- — .claude/rules — standing instructions that may be limited to file paths
- — Skill — on-demand reference material or repeatable workflow
- — Plugin — installable package that can include skills and other extensions
04
How do you create a safe AEC project skill?
For a shared AEC method, start in a test repository and create one directory under .claude/skills. The following example produces a manual drawing-QA handoff from issues that a person has already reviewed. It does not inspect a model, decide whether an issue is valid, or grant itself tool permissions.
The directory name and the name in frontmatter are deliberately aligned. The description says when the skill applies, while disable-model-invocation keeps it manual so the user chooses when the handoff procedure enters the conversation.
mkdir -p .claude/skills/drawing-qa-handoffNew-Item -ItemType Directory -Force .claude/skills/drawing-qa-handoff---
name: drawing-qa-handoff
description: Prepares an evidence-linked drawing coordination handoff from reviewer-accepted issue data. Use after a qualified reviewer has accepted the source issues.
disable-model-invocation: true
---
Use only the supplied, reviewer-accepted issue register.
1. Preserve sheet, detail, discipline, and source references.
2. Separate observed evidence from interpretations.
3. Mark missing owners, due dates, and unresolved conflicts.
4. Produce a Markdown handoff with a summary, action table, and human-review checklist.
Do not change project files, determine code compliance, or present any issue as approved.05
How do you verify that Claude Code loaded the skill?
Start Claude Code at the repository root. Open the skills menu and confirm that drawing-qa-handoff is listed as a project skill, then invoke it by its exact command name. Test it with sanitized, non-production issue data that has known sheet references, owners, gaps, and one deliberate conflict.
A passing test is not merely a response. Confirm that every accepted source reference is preserved, observations remain separate from interpretations, unknowns stay visible, no project file is changed, and the output still calls for human review. Repeat the test in a fresh session so context left over from authoring the skill does not hide missing instructions.
- — The skill appears under the expected scope
- — The slash command runs only when invoked
- — The output preserves evidence and unresolved items
- — The test makes no edits or unsupported professional decisions
- — The same acceptance checks pass in a fresh session
/skills
/drawing-qa-handoff06
Why is a Claude Code skill missing or not triggering?
If a new skill does not appear, first confirm the entry file is named exactly SKILL.md and sits one directory below a discovered skills folder. If the top-level skills directory did not exist when the session began, restart Claude Code so it can watch the new directory. A nested monorepo skill will not be available until Claude Code first works with a file in that nested package.
Malformed YAML can produce a misleading partial success: the body may remain invocable while the metadata is empty, so automatic matching fails. Use Claude Code's debug output to find the parse error. Also check whether a higher-precedence skill has the same name; enterprise overrides personal, personal overrides project, and plugin skills avoid this conflict by using a namespace.
- — Confirm the exact SKILL.md filename and directory depth
- — Restart if the top-level skills directory was created after session start
- — Touch the relevant nested package before expecting its monorepo skill
- — Check YAML parsing and make the description match natural user language
- — Inspect same-name precedence and skill visibility settings
07
What should an AEC team review before trusting a skill?
Treat every downloaded or repository-supplied skill as executable instructions that require review. Read SKILL.md, every referenced file, and any bundled script before invocation. Pay particular attention to allowed-tools: Anthropic documents that this field can grant tools without a per-use prompt for the invoking turn, and workspace trust does not gate that grant.
For practice use, begin with sanitized data and the narrowest permissions. Keep client credentials, personal information, contract-sensitive records, and unreleased project files out of the test. Review every proposed command and critical-file change, and use an isolated environment when a third-party skill runs scripts or reaches external services.
- — Source and ownership of the skill
- — SKILL.md frontmatter and invocation controls
- — Allowed and disallowed tools
- — Referenced files, scripts, network calls, and output destinations
- — Data classification, professional boundary, reviewer, and rollback path
08
How do you disable, roll back, or remove a skill?
For a reversible rollback, move a personal or project skill directory outside its discovered skills folder, start a fresh session if it was already invoked, and confirm it no longer appears in /skills. Once the team has preserved any required version history, it can delete the archived directory through its normal source-control and retention process. Content from a skill invoked earlier remains in that conversation until the session ends, even after the directory is removed.
Remove a plugin skill by disabling or uninstalling its plugin, then reload plugins or restart. Remove a synced skill by turning it off for the claude.ai account and syncing again; deleting its downloaded folder alone is temporary because the next sync can restore it. Enterprise skills require the responsible administrator.
- — Personal or project — archive outside the skills folder, verify, then remove under your retention policy
- — Plugin — disable or uninstall the plugin, then reload plugins or restart
- — Synced — disable in the claude.ai account and sync again
- — Enterprise — ask the administrator responsible for managed settings
- — Invoked earlier — use a fresh session to verify a clean removal
09
What is the next practical step for an AEC team?
Choose one real task and one scope. A personal skill suits your own recurring, low-risk drafting method across projects. A project skill suits an office-approved QA or handoff procedure that should be reviewed with a repository. A plugin suits broader distribution only when the extra packaging is necessary.
For drawing and BIM review, start with a redacted sample and compare the proposed skill structure against archiPrompt's published Drawing Set Coordination Review or BIM Model QA Checklist listings below. Confirm compatibility, inputs, outputs, version, limitations, and reviewer responsibility before adapting either method to Claude Code or a live project.
REVIEW BEFORE USE
Known limitations
- Claude Code changes frequently; confirm the current Anthropic skills documentation before standardizing paths, commands, frontmatter, or organization-wide rollout.
- A skill can structure AEC review work, but it cannot approve a drawing set, determine code compliance, validate model geometry, or replace the responsible architect, engineer, contractor, BIM lead, or other qualified reviewer.
- Personal skills on one workstation are not automatically available in Cowork or remote cloud sessions; distribution and data-handling rules must be tested for the surface the team actually uses.
PRIMARY SOURCES
References used for this guide
These guides support Prompt evaluation and do not replace project-specific advice, code interpretation, consultant coordination, or qualified professional review.
Reviewed by archiPrompt Studio · Technical editorial + AEC workflow review