cowork-plugin-audit — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited cowork-plugin-audit (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill audits the active plugins in your Claude Cowork setup and produces a keep/disable/disable-until-needed recommendation table. It compares each installed plugin against your described workflow, flags idle or redundant plugins, and provides a qualitative estimate of potential token savings.
Input:
.md)Output:
Detect the user's language from their message:
Negative Case — Empty list: If no plugin list is received after prompting, stop and respond: "Plugin list required. Please paste your installed plugins from Cowork Settings → Plugins."
For each plugin in the list, assign one of three categories based on the described workflow:
Classification logic:
sales → core if user manages deals; idle if user is a solo developerengineering → core for developers; contextual for PMs who sometimes review code; idle for finance teamcontextual over idleFor each plugin classified as contextual or idle, generate a recommendation:
| Plugin state | Recommendation |
|---|---|
| core | keep |
| contextual, high relevance | keep |
| contextual, low relevance for current project | disable-until-needed |
| idle | disable |
Rationale rule: each rationale must name a specific reason (e.g., "No sales tasks in described workflow" — not just "unused").
Edge Case — Only one plugin installed: Output a brief audit note: "Minimum configuration detected — no plugins recommended for removal."
Edge Case — User's role changes by project: Mark conflicting plugins explicitly as contextual (other projects) and set recommendation to disable-until-needed.
Negative Case — Contradiction: If the user's workflow clearly requires a plugin they want to disable, flag the conflict: "Your workflow mentions [task] which uses [plugin] — recommend keeping. Please confirm if you still want to disable."
disable recommendations exist: render the optional Project Instructions blockToken savings estimate logic:
## Plugin Audit — [date]
### Workflow Context
[1–2 sentences: role and primary tasks as understood]
### Audit Table
| Plugin | Category | Recommendation | Rationale |
|--------|----------|----------------|-----------|
| engineering | contextual | disable-until-needed | Used only during code review tasks; not part of daily workflow |
| sales | idle | disable | No sales-related tasks in described workflow |
| data | core | keep | Regular data analysis is a primary task |
| product-management | core | keep | Sprint planning and spec writing are primary tasks |
| ... | ... | ... | ... |
### Summary
- **Keep:** N plugins
- **Disable:** N plugins
- **Disable-until-needed:** N plugins
- **Estimated token impact:** [low / moderate / significant] reduction
### Optional: Project Instructions Block
Add the following to your Project Instructions to prevent disabled plugins from being activated:
> Disabled plugins for this project: [plugin-1], [plugin-2]. Do not activate skills from these plugins unless I explicitly ask.Field rules:
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.