| name | cowork-readiness-check |
| description | Audit every plugin in this marketplace for Claude Cowork compatibility. Updates the plugins table in MARKETPLACE.md with a Cowork column and appends a status suffix to each skill's frontmatter description. Contributor-only skill — lives in `.claude/skills/`, not shipped via the marketplace. Use when adding or revising a plugin, or when refreshing Cowork readiness status. Triggers on "check cowork readiness", "audit plugins for cowork", "/cowork-readiness-check". |
Cowork Readiness Check
Determine whether each plugin under plugins/ is viable inside Claude Cowork's sandboxed environment, then write the verdict into the marketplace documentation so users and authors see it without having to read the limitations doc.
This is a contributor skill for this repo — it lives under .claude/skills/ rather than plugins/ because its job is to maintain the marketplace, not to ship inside it. It modifies files in plugins/ and MARKETPLACE.md; it never edits itself.
Authoritative reference for the criteria: COWORK-LIMITATIONS.md. Re-read it before running so the heuristics stay aligned with current product reality (it changes as Cowork evolves).
Workflow
Copy this checklist and track progress:
Task Progress:
- [ ] Step 1: List all plugins under plugins/
- [ ] Step 2: Classify each plugin (ready / not-ready + reason)
- [ ] Step 3: Update the plugins table in MARKETPLACE.md
- [ ] Step 4: Update each skill's SKILL.md frontmatter description
- [ ] Step 5: Print a summary
Step 1: List all plugins
Enumerate every directory directly under plugins/. Each directory is one plugin. For each plugin, read:
plugins/<name>/.claude-plugin/plugin.json — for the canonical name and current descriptionplugins/<name>/skills/*/SKILL.md — for the frontmatter description and the body (heuristic evidence)plugins/<name>/commands/*.md — if presentplugins/<name>/agents/*.md — if presentplugins/<name>/hooks/ — read the hook(s); they do run in Cowork, so classify by what each hook actually does (Step 2), not by mere presenceplugins/<name>/monitors/ — existence is itself a signalplugins/<name>/.lsp.json — existence is itself a signalplugins/<name>/.mcp.json — inspect the transportplugins/<name>/bin/ — existence is itself a signal
Step 2: Classify each plugin
Apply the checklist below in order. A plugin is Not Cowork-ready if any rule triggers. Otherwise it is Cowork-ready.
Hard structural rules (file-system signals)
A plugin is Not Cowork-ready if it contains any of:
- A
monitors/ directory.
- A
.lsp.json file.
- A
bin/ directory (no PATH injection in the sandbox).
- A
.mcp.json whose server entries use stdio transport — i.e. an entry with a command field (and typically args) rather than a url. Stdio MCP requires spawning a local subprocess on the user's machine, which the sandbox cannot do. HTTP/SSE MCP entries (with a url) are fine.
Hooks are NOT a disqualifier — correction (2026-07). Earlier versions of this skill listed a hooks/ directory as an automatic "Not Cowork-ready" signal. That was wrong. Plugin hooks run in Cowork — Anthropic's Use plugins in Claude Cowork Help Center article states: "hooks and sub-agents run only in Cowork, so they appear grayed out in chat" (i.e. they run in Cowork and the Claude Code terminal, just not in plain web/desktop chat). So hooks/ presence alone does not make a plugin Not Cowork-ready. Judge what the hook does against the behavioral rules below: a SessionStart hook that cats a bundled file into context is Cowork-fine; a hook that shells out to a local binary, hits localhost, or reaches a blocked network host is not. See COWORK-LIMITATIONS.md (§ Hooks run in Cowork and the rules-to-Cowork-via-hook trick) for the evidence and links. Caveat: the docs say "hooks" generally; the SessionStart event specifically is pending our own empirical confirmation in a live Cowork session.
Behavioral rules (scan the SKILL.md and any commands/agents)
A plugin is Not Cowork-ready if its instructions cause the agent to:
- Connect to
localhost, 127.0.0.1, host.docker.internal, or any user-machine-local hostname.
- Reach external services from the shell beyond Anthropic-sanctioned channels — outbound
curl to api.figma.com, github.com, npm/PyPI/Cargo registries, etc. is blocked by the Cowork egress proxy. (The agent's own WebFetch/WebSearch tools and registered MCP connectors are fine because they don't go through the shell sandbox.)
- Shell out to binaries that aren't in the Cowork base image —
brew, npm, pnpm, pip, cargo, gem, docker, kubectl, project-specific CLIs, etc. Only standard POSIX tools, git, and the agent's built-in tools should be assumed available.
- Read or write paths outside the explicit workspace mount —
~/.claude/, the user's home directory, system paths.
- Run the user's test suite, dev server, browser, or any process that requires their local environment.
Mixed cases
Some plugins have a primary path that fails and a fallback that might work (e.g., a local-MCP path with a hosted-API fallback). If both paths are not Cowork-ready, the plugin is Not Cowork-ready. If at least one path is genuinely viable in Cowork (e.g., the fallback goes through a registered connector or only uses agent-level tools), classify as Cowork-ready and note the constraint in the reason field.
Record the verdict
For each plugin, record:
name — plugin directory nameverdict — Ready or Not readyreason — required when Not ready. One short clause citing the rule that triggered. Example: "reads ~/.claude/ outside the workspace mount", "hits localhost:3845 and api.figma.com", "requires local npm/brew/pip binaries".
Step 3: Update the plugins table in MARKETPLACE.md
Find the existing plugins table. It currently has the header:
| Skill | Description | Cowork | Install |
For each row, fill in the Cowork column:
- Ready →
Ready
- Not ready →
Not ready — <reason>
Add a row for any plugin that's missing.
If the column doesn't exist yet (first run on a clean repo), insert it between Description and Install. Keep the column order and existing values otherwise unchanged. Don't reflow or re-sort rows.
Step 4: Update each SKILL.md frontmatter description
For every skill at plugins/<plugin>/skills/<skill>/SKILL.md, modify the description: line in the frontmatter to end with a Cowork status suffix:
- Ready → append
Cowork-ready. to the description.
- Not ready → append
Not Cowork-ready — <reason>. to the description.
Idempotency rules
This skill is meant to be re-run. Before appending, check whether a Cowork suffix already exists:
- If the description already ends with
Cowork-ready. or Not Cowork-ready — … matching the current verdict and reason, leave it alone.
- If the existing suffix has a different verdict or a different reason, replace the old suffix with the new one rather than appending a second.
Detect the suffix with a permissive match: anything starting with Cowork-ready or Not Cowork-ready and continuing to the end of the description string.
Preserve everything else in the description — keep the original copy, triggers, and tone intact. The suffix is a marker, not a rewrite.
Step 5: Print a summary
Output to the conversation:
- Total plugins checked
- Count of Ready vs Not ready
- List of Not-ready plugins with their reasons
- The list of files modified (MARKETPLACE.md + each SKILL.md whose suffix changed)
If the verdict for any plugin changed since the previous run (i.e., you replaced a suffix rather than adding one), flag those plugins explicitly — they're the ones a reader of the diff will care about.
Notes for the auditor
- This skill never edits plugin behavior or
plugin.json files. Only documentation surfaces — the MARKETPLACE.md table and SKILL.md descriptions.
- The verdict is binary by design. If you genuinely can't decide, default to Not ready and write a reason starting with "Uncertain — " so the next reviewer knows to look closer.
- The Cowork sandbox is a research preview; the rules above will drift. Treat
COWORK-LIMITATIONS.md as the source of truth and update that document first if you discover a rule has changed, then re-run this skill.
