rules
Skill2 starsChanged 6 days agoMITView on GitHub
Manage the architectural-rule overlay: list, disable, enable, edit, sync or locate rules across the shipped, company, user and project tiers. Use on /rules, or when the user asks to override, disable or add a rule, see which rules are active or why one applies, or point at a company rules repo. Mode A only — never auto-fire.
11 other projects use a version of this.
Adopted by
Most recently taken up by
- Beskars-Code/Skillstheir own version, first seen Nov 6, 2026
- Gabriel-Lafrance/Skillstheir own version, first seen Nov 6, 2026
- MagicJosh/rastheir own version, first seen Nov 2, 2026
- newkayak12/claude-skillstheir own version, first seen Nov 1, 2026
- avivsinai/bitbucket-clitheir own version, first seen Oct 13, 2026
- wjgoarxiv/litopencodetheir own version, first seen Oct 13, 2026
Other versions11 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 11
- avivsinai/bitbucket-cli★ 257same name
- ByronFinn/dev-skills★ 4same name
- yinhunfeixue/software_development_skills★ 4same name
- newkayak12/claude-skills★ 3same name
- AltDoug/found-issues★ 2same name
- ibahgat/oh-my-iflow★ 2same name
- wjgoarxiv/litopencode★ 2same name
- MaGe1993/Claude-Code-Base-Harness★ 1same name
- MagicJosh/ras★ 1same name
- Beskars-Code/Skills★ 0same name
1 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository47 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- autonomizeSkill
- blueprintSkill
- brainstormSkill
- captureSkill
- checkpointSkill
- close-outSkill
- coordinateSkill
- cycleSkill
- deliverSkill
- design-proposalSkill
- discoverSkill
- dispatchSkill
- draft-planSkill
- envisionSkill
- executeSkill
- extract-conventionsSkill
- glossarySkill
- humanizeSkill
- human-viewSkill
- improve-promptSkill
- memory-auditSkill
- new-agentSkill
- new-agents-mdSkill
- new-hookSkill
- new-mcpSkill
- orchestrateSkill
- pr-authorSkill
- prepSkill
- pre-pushSkill
- pr-triageSkill
- recapSkill
- retrospect-coreSkill
- reviewSkill
- shortcutsSkill
- specSkill
- systematic-debuggingSkill
- test-driven-developmentSkill
- update-changelogSkill
- update-codemapSkill
- using-git-worktreesSkill
- visualise-codemapSkill
- visualSkill
- work-stateSkill
- wrapSkill
- write-testsSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 2 are distinctive, and 5 are very specific to this project.
0
Common
Most of the 10 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 11
Mode A only: Every mutating command previews the before→after effect on the *effective corpus* and waits for explicit confirmation before …
- Very specific: line 25
Run the resolver (see docs/architectural-rules-overlay.md § Resolution).
- Very specific: line 32
Default scope = global (user manifest disabled:).
- Very specific: line 33
If the target carries locked: true, require explicit confirmation naming the lock.
- Very specific: line 37
Remove the key from whichever manifest disabled: set holds it (project checked before user).
- Distinctive: line 41
Ask: whole-file override or field patch?
- Very specific: line 45
If the target is locked: true, confirm + write a divergence entry (as in disable).
“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
rules
Front door for the architectural-rule overlay system. Manages the user/company/project tiers that layer over the shipped architectural-rules/ tree. See docs/architectural-rules-overlay.md for the model.
Mode A only. Every mutating command previews the before→after effect on the effective corpus and waits for explicit confirmation before writing. Never auto-fires.
Tier directories
- shipped:
~/.claude/architectural-rules/, or${CLAUDE_PLUGIN_ROOT}/architectural-rules/in a plugin install (read-only here — never edit through this skill) - company:
~/.claude/architectural-rules-company/ - user:
~/.claude/architectural-rules-local/ - project:
<project>/.claude/rules/
Manifests: ~/.claude/architectural-rules.config.yaml (user), <project>/.claude/rules.config.yaml (project).
Subcommands
/rules list
Run the resolver (see docs/architectural-rules-overlay.md § Resolution). Show the effective corpus grouped by winning tier. Annotate only non-default rules: overridden, patched, disabled, or locked-and-diverged. Plain shipped rules show name + scope only.
/rules where <key>
The debug command. For one <scope>/<name> key, list every tier that defines it, which wins, and why (override / patch deltas / disable / lock). Show orphaned patch anchors if any.
/rules disable <key> [--project | --session]
- Resolve the key; show exactly which rule(s) vanish from the effective corpus.
- Default scope = global (user manifest
disabled:).--project→ project manifest.--session→ ephemeral, in-context note only, nothing written. - If the target carries
locked: true, require explicit confirmation naming the lock; on confirm, append adivergences:entry to the project manifest. - Preview → confirm → write.
/rules enable <key>
Remove the key from whichever manifest disabled: set holds it (project checked before user). Preview → confirm → write.
/rules edit <key> [--editor]
- Resolve the current winning tier for the key.
- Ask: whole-file override or field patch?
- whole-file → create
~/.claude/architectural-rules-local/<key>.mdseeded with the resolved lower-tier body (a real baseline, not blank). Setorigin: user. - field patch → create the same path with
override: <key>,mode: patch, and emptyremove/replace/addsections to fill in.
- whole-file → create
- Conversational by default: load the body into the chat; the user describes the change; apply via Edit with propose-confirm.
--editorinstead opens the file in$EDITORfor raw hand-editing. - If the target is
locked: true, confirm + write a divergence entry (as indisable). - Show the resulting effective rule (post-resolution) so the user sees the merged outcome.
/rules sync
Clone or pull the company repo per the user manifest's company.repo + ref, into ~/.claude/architectural-rules-company/. Idempotent. If no company.repo is configured, no-op with a clear message — not an error. Pin ref to a tag for reproducibility.
Notes
- This skill never edits the shipped tree. Overrides always land in the user or project tier.
--sessiondisables are the fastest control: kill a rule that's in the way now, nothing persisted.- The resolver is shared with discover; keep behaviour identical (one source of truth in
docs/architectural-rules-overlay.md). - Anchors (
<!-- id: ... -->) stay in files but are stripped before context — do not remove them when editing a body, they are patch targets.
See docs/architectural-rules-overlay.md for the full contract.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

