Detailed Analysis
A Reddit user's investigative post on r/ClaudeAI documents a hands-on technical resolution to a widely misunderstood aspect of Claude's Skills architecture: where, precisely, skills are stored and loaded from. The author's central finding is unambiguous — with the sole exception of Claude Code, all skills across every Claude surface (web chat, the Mac desktop app, and Cowork) are loaded exclusively from Anthropic's servers. No scanning of local or cloud-synced directories occurs at skill discovery time. The author arrived at this conclusion after a dedicated session in Cowork comparing live behavior against the contents of three distinct file locations: the Anthropic plugin mount, a personal Dropbox folder, and the Claude Code local skills directory. The practical upshot is that the only authoritative method for deploying a skill to chat surfaces is uploading a `.skill` bundle through the Customize Skills interface — edits made anywhere else do not propagate automatically.
The post's most technically useful contribution is its disambiguation of a subtle but consequential distinction: skill *discovery* versus skill *runtime asset access*. Some of the author's custom skills contain SKILL.md files that reference paths like `/mnt/skills/user/<skill>/scripts/foo.py`, which in the Cowork environment resolve to the user's Dropbox folder. This means that after a skill has already been loaded from the server, its execution logic can reach out to Dropbox for scripts, assets, or reference files. The skill is not *sourced* from Dropbox; rather, Dropbox functions as a runtime resource location for Cowork-exclusive skills. This path resolution does not exist in web chat, making such skills inherently surface-specific by design. The author's failure to recognize this boundary earlier led to a persistent and frustrating misdiagnosis of how the system operated.
The practical failure mode the author describes — maintaining three divergent copies of the same skill across server deployment, Dropbox, and stale `.skill` bundles with no canonical source of truth — reflects a common problem in developer workflows involving distributed or cached state. The author's self-prescribed resolution is a disciplined, single-origin edit workflow: all changes are made in Cowork (which can directly access Dropbox via file tools), followed by packaging into a `.skill` bundle and uploading via Customize Skills. Notably, the author explicitly rejects using the web Customize Skills editor directly, identifying it as a path to creating untracked forks. This is a meaningful observation about the design tension between convenience interfaces and version control discipline.
The broader context here involves the relative novelty and opacity of Claude's Skills system as a user-facing feature. Skills function as modular extensions that give Claude specialized, invocable capabilities — triggered either explicitly via `/skill-name` commands or loaded automatically when task context matches a skill's purpose. The architecture appears deliberately lightweight: only a brief header of each installed skill loads by default, with the full instruction set activating on relevance. This lazy-loading approach enables users to maintain large skill libraries without meaningfully degrading context window efficiency. However, as this post illustrates, the abstraction creates real confusion about where the "live" version of a skill resides, particularly when multiple authoring surfaces and sync tools are involved.
The post's call for corrections from Anthropic personnel signals a broader gap in official documentation around Skills architecture. The author's confusion was not idiosyncratic — earlier community explanations they received were incorrect, suggesting the misunderstanding is widespread. As Claude's Skills ecosystem matures and more users build custom workflows, the absence of clear, authoritative documentation about the server-only loading model, the Cowork-specific path resolution behavior, and the relationship between `.skill` bundles and deployed state represents a meaningful friction point. The distinction between Anthropic-managed stock skills (which update on Anthropic's own release schedule and should not be self-maintained) and user-defined custom skills is also underspecified in community knowledge, as the author's experience of perceived "drift" on stock skills demonstrates.
Read original article →