claude-code - 💡(How to fix) Fix Allow workspace authors to suppress named platform skills during custom onboarding flows

Preflight Checklist

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

Problem Statement

When a Cowork workspace ships its own onboarding flow — a custom skill that walks new users through a setup sequence (connect tools → build reference files → configure preferences) — Claude's platform-level setup-cowork skill can auto-trigger and short-circuit the custom flow. The two skills overlap conceptually (both are "setup helpers") but the workspace skill is the authoritative one for that workspace.

Today there is no reliable mechanism to suppress a named platform skill from a workspace. A prose rule in CLAUDE.md ("do not use setup-cowork while setup is in progress") works inconsistently — beta testing showed the platform skill still fires in some sessions.

Existing related issues — #26838, #33080, #39749, #53746, #30355, #14920 — cover token-cost, plugin-displacement, and per-session-toggle framings. This request is specifically about workspace-distributed onboarding flows: someone packages a starter folder for new users and needs the custom onboarding to take precedence over platform defaults.

Proposed Solution

Any one of the following would solve this; preference for #1 because it's declarative and lives in the workspace alongside the custom onboarding files.

1. A disabledPlatformSkills: ["setup-cowork", "..."] array in CLAUDE.md or workspace settings.json that omits named platform skills from the session's skill registry for that workspace.

2. A conditional disable — e.g. "suppress setup-cowork while a named file (Setup/setup-progress.md) contains unchecked items." This is more nuanced and would let the platform skill come back online once onboarding is complete.

3. An explicit override mechanism — a workspace skill can declare in its frontmatter that it supersedes a named platform skill for the duration of that workspace. Example: supersedes: setup-cowork.

Alternative Solutions

Three-part workaround currently in place in the Cowork Skeleton (a starter folder being built for TELUS Health business analysts):

1. Negative CLAUDE.md rule: "do not use setup-cowork while Setup/setup-progress.md has unchecked items."
2. Positive CLAUDE.md rule: "If the user says 'build robot' or 'build my robot', use the build-robot skill — never setup-cowork."
3. Renamed the custom skill's trigger phrases from "continue setup" → "build robot" / "build robot step N" to reduce phonetic collision with setup-cowork.

Why these are inadequate: (1) is unreliable — beta testing on May 11, 2026 showed setup-cowork still occasionally fired despite this rule being in CLAUDE.md. (2) and (3) are new but only help when the user says one of the targeted phrases — any synonymous request ("help me set this up", "what's next", "where do I start") can still mis-route to the platform skill. The underlying gap (no programmatic way to suppress a named platform skill) is unresolved.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

The Cowork Skeleton — a shareable starter folder being built so other TELUS Health business analysts (and eventually external Cowork users) can bootstrap a personalized Cowork assistant without starting from zero.

The skeleton ships with:

• A Skills/build-robot.md skill — guides users through 10 numbered setup prompts (connect tools, set up rosters, build a style guide, etc.)
• A Setup/setup-progress.md file — tracks which steps are done
• A CLAUDE.md with the negative rule above

In beta testing with a user on May 11, 2026, the platform's setup-cowork skill fired during step 2 and steered her toward installing plugins, which conflicted with the skeleton's own connector setup that was about to happen in the same step. The chat had to be abandoned and restarted.

The skeleton's onboarding is the right flow for those users — the platform skill is generic and the workspace-specific one is authoritative. There's currently no way to declare that precedence.

Additional Context

This came out of building a shareable Cowork starter folder for TELUS Health business analysts. Project name: "Cowork Skeleton." It's the kind of artefact that becomes more common as Cowork adoption grows — teams packaging their own onboarding flows, training programs distributing pre-configured workspaces, etc.

The narrower phonetic-collision part of the problem (the custom skill's triggers overlapping with setup-cowork) was mitigated by renaming the custom skill's triggers. The underlying suppression gap remains.

Related but distinct from the issues listed in Problem Statement — those are about token cost, name collisions on update, or generic disable. This one's specifically about workspace authors declaring precedence.