[FEATURE] Project-scoped skills in Cowork (parity with Claude Code's `.claude/skills/`)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Cowork currently has no equivalent to Claude Code's project-scoped skills. Skills in Cowork are managed at the user/account level through the Customize UI, with no mechanism to scope a set of skills to a specific Cowork Project. This forces every skill to be globally active across every project, which causes context pollution and works against the isolation that Cowork Projects are otherwise designed to provide.

Cowork Projects already isolate context, memory, files, and scheduled tasks per project — skills are the notable exception. The result is that a skill tuned for one project's tone, file conventions, target services, or domain will trigger inappropriately in unrelated projects, and there's no clean way to scope it.

My setup is multiple active Cowork Projects with distinct audiences and collaborators — one for personal/family affairs and several work projects shared with different teams. The lack of skill isolation between these projects is a direct concern: a skill useful for one work project shouldn't be discoverable or triggerable when working in the family project, and vice versa. This is a privacy/correctness issue, not just a tidiness one.

Proposed Solution

Cowork should support a per-project skill scope that follows the same precedence model as Claude Code: enterprise > personal > project. The exact discovery mechanism (a .claude/skills/ directory inside the project folder, a path configured in the Project settings, or something else) is less important than the capability itself — whichever approach fits best with Cowork's architecture works.

Key requirements:

1. Skills attached to a Cowork Project are only active when that project is open.
2. Project skills do not appear in or affect other projects or standalone Cowork sessions.
3. Precedence matches Claude Code (enterprise > personal > project) so the mental model is consistent across surfaces.
4. Project skills are visible in the project's Skills panel alongside personal/global skills, ideally with a clear indicator of their scope.

Alternative Solutions

Current workarounds, all unsatisfactory:

1. Install the skill globally and hope it never triggers in the wrong project — it does, because skill descriptions often match broad intents (e.g. "calendar") that apply across projects.
2. Don't use a skill at all and re-prompt the workflow each time — defeats the purpose of skills.
3. Write extremely defensive description text trying to gate the skill on project context — fragile, and eats into the 16K description budget.

None of these provide actual isolation. They're all forms of mitigation that depend on the LLM's discretion at trigger time, rather than the platform enforcing scope.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

I have a skill that fetches calendar information from a specific website, adds matching events to a shared Google Calendar, and updates a key_dates.md file inside the project folder. The skill encodes project-specific logic: which events to filter for, which calendar to write to, how to format entries, and where the key_dates.md lives.

This skill is meaningless — and actively harmful — outside that one project:

• The target calendar belongs to one project's team; firing this skill in another project would write events to the wrong calendar.
• The key_dates.md path is hard-coded to the project's folder structure.
• The filter criteria are tied to a specific source website that's only relevant to this project.

Today the skill has to either live globally (where it can fire on the wrong project and write to the wrong calendar) or not exist as a skill at all. A project-scoped skill would solve this cleanly: the skill lives with the project that needs it, isn't visible to any other project, and travels with the project if I archive or move it.

Additional Context

Related issues

This sits alongside existing skill-discovery problems in Cowork, but is distinct from all of them:

• #53414 — Skills are siloed across Chat / Cowork / Code tabs
• #52873 — Skills edited via Customize UI not reflected in Code tab
• #50669 — Cowork only loads a subset of personal skills from ~/.claude/skills/

Those issues address inconsistencies in how existing skills are loaded across surfaces. This request is asking for a new scope level (project) that Cowork doesn't currently have at all.

Environment

• Claude Desktop version: 1.7196.0 (2dbd78)
• OS: macOS 26.3.1
• Hardware: MacBook Pro 16-inch (2021), Apple M1 Pro, 32 GB RAM
• Cowork Project setup: Multiple active projects (one personal/family, several work projects shared with different teams)