← ClaudeAtlas

workspace-ruleslisted

Give a repo its house rules at the cheapest layer: what the workspace tells a session up front, plus what turns the build red afterwards (linter setting, architecture test, hook). Triggers: "house rules", "write a CLAUDE.md", "set up .claude", "turn this rule into a test", «قانون بذار», «قوانین پروژه».
smk-labs/claude-plugins · ★ 11 · Code & Development · score 79
Install: claude install-skill smk-labs/claude-plugins
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 i