Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/smk-labs/claude-plugins/workspace-rulesnpx skills add smk-labs/claude-plugins --skill workspace-rulesgit clone --depth 1 https://github.com/smk-labs/claude-pluginsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/smk-labs/claude-plugins/workspace-rules)<a href="https://agentmods.dev/skills/smk-labs/claude-plugins/workspace-rules"><img src="https://agentmods.dev/badge/skills/smk-labs/claude-plugins/workspace-rules.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00313 | $0.02821 |
| Opus 5 | $0.00156 | $0.01411 |
| Sonnet 5 | $0.00063 | $0.00564 |
| Haiku 4.5 | $0.00031 | $0.00282 |
Grade A, and why
workspace-rules scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 63 lines — stays where its author put it; the contents beside it link to each section on GitHub.
A repo's rules sit at two layers: what its workspace tells a model before a line exists, and what its build catches after one is written. Telling costs a line in a file the model already reads; catching costs a red build, a turn, and a check somebody maintains forever. A rule belongs at the cheapest layer that holds it, and getting that call right is most of this pass. One test governs both: if you could have written the rule without opening this repo, the model already knows it and the line is a tax.
Which layer, and this is the judgment the rest hangs on
Take the capability away before writing any rule. Delete the export, narrow the visibility, drop the dependency, remove the tool. A reviewer shipped without an edit tool cannot fix the code it reviews, which no instruction achieves and no compacted context forgets. Then read the default posture, because omission from an allow list is not removal.
Sort what is left by what it hands the model. Information it could not infer costs nothing to obey and holds with no gate, no judge and no repetition: what this repo does not have, which of two sources wins, where the local default is wrong and how widely. A cost it must pay against its own task is not held by prose at any volume. Loudness and frequency buy nothing, and the loudest rule in this evidence sits beside a settings file granting the very access it forbids.
If a script could count compliance, something must count it. Best-evidenced claim here, and it runs one way only: every countable rule nobody counted was found violated, most often by the file stating it. A file carrying a two hundred line target ran five hundred and fifty three, and a field no downstream reader consumed was blank in thirty-seven of thirty-nine notes.
Where a cost remains and the capability cannot go, put the result in front of somebody who did not produce it, reading primary evidence rather than the producer's account. The one controlled comparison here is exactly that: reviews handed a summary found none of the blockers, reviews handed the diff found twelve. A self-reported pass is worse than no check, because it launders trust downstream.
What is left is a cost no script can count, and that is the handful worth writing down. No script reads degree or intent, so none tells a surgical cut from a rewrite. None reaches a truth living outside the repo, like what someone else's binary does with your flags after their next release. None sees how you checked, only what you wrote, so render it and look at it is out of reach. And none gets any signal when the violation still works, which covers every judgment about where a thing belongs. Write those. Write almost nothing else twice.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 63 lines · 313 tokens per session scan A 375145a9bd0c
workspace-rules is a skill published in the GitHub repository smk-labs/claude-plugins (11 stars, last pushed 4d ago), licensed MIT. It adds 313 tokens to every session and 2,821 once invoked, about $0.0016 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
ab-test-analysis
Analyze A/B test results with statistical significance, sample size validation, confidence intervals, and ship/extend/stop recommendations. Use when evaluating experiment results, checking if a test reached significance, interpreting split test data, or deciding whether to ship a variant.
brainstorm-okrs
Brainstorm team-level OKRs aligned with company objectives — qualitative objectives with measurable key results. Use when setting quarterly OKRs, aligning team goals with company strategy, drafting objectives, or learning how to write effective OKRs.
dummy-dataset
Generate realistic dummy datasets for testing with customizable columns, constraints, and output formats (CSV, JSON, SQL, Python script). Use when creating test data, building mock datasets, or generating sample data for development and demos.
outcome-roadmap
Transform an output-focused roadmap into an outcome-focused one that communicates strategic intent. Rewrites initiatives as outcome statements reflecting user and business impacts. Use when shifting to outcome roadmaps, making a roadmap more strategic, or rewriting feature lists as outcomes.
pre-mortem
Run a pre-mortem risk analysis on a PRD or launch plan. Categorizes risks as Tigers (real problems), Paper Tigers (overblown concerns), and Elephants (unspoken worries), then classifies as launch-blocking, fast-follow, or track. Use when preparing for launch, stress-testing a product plan, or identifying what could go…
shipping-artifacts
The durable documentation set that makes an AI-built (vibe-coded) app reviewable before shipping. A small core every app needs — architecture, user/permission flows, permissions, variables/secrets, and a test-coverage map — plus conditional docs added only when they apply: emails, scheduled work, SEO, and embedded…