Two issues from the post-merge review of #1860: 1. **`brakeman --no-pager` is not a real flag.** Brakeman has no `--no-pager` option (that's `git` / `gh` style). It appeared in three locations: - `rules/ruby/hooks.md` L18 (bullet recommendation) - `rules/ruby/hooks.md` L32 (CI gate snippet) - `rules/ruby/security.md` L38 (dependency check snippet) Replaced with `--no-progress`, which is the closest valid option (suppresses the progress bar while keeping warning output — what hook contexts usually want). `-q` / `--no-color` would also be valid alternatives but `--no-progress` matches the original intent best. 2. **`bundle-audit` invocation was inconsistent across the two files.** `rules/ruby/security.md` L37 used the `bundle audit check --update` Bundler plugin subcommand form, while `rules/ruby/hooks.md` L20 used the direct `bundle exec bundle-audit check --update` binary form. Both invoke the same `bundler-audit` gem but look different enough to confuse readers. Standardized on the `bundle exec bundle-audit` form (the portable invocation that works across bundler-audit gem versions without depending on the plugin registering a `bundle audit` subcommand). Both issues were also flagged in PR #1860 review comments (#1, #2 of my comprehensive review; the bundle-audit one was independently caught by greptile-apps and coderabbitai bots). Full test suite (`node tests/run-all.js`): 2382 passed, 0 failed. `markdownlint-cli` clean on both files.
Rules
Structure
Rules are organized into a common layer plus language-specific directories:
rules/
├── common/ # Language-agnostic principles (always install)
│ ├── coding-style.md
│ ├── git-workflow.md
│ ├── testing.md
│ ├── performance.md
│ ├── patterns.md
│ ├── hooks.md
│ ├── agents.md
│ └── security.md
├── typescript/ # TypeScript/JavaScript specific
├── angular/ # Angular specific
├── python/ # Python specific
├── golang/ # Go specific
├── web/ # Web and frontend specific
├── swift/ # Swift specific
├── php/ # PHP specific
├── ruby/ # Ruby / Rails specific
└── arkts/ # HarmonyOS / ArkTS specific
- common/ contains universal principles — no language-specific code examples.
- Language directories extend the common rules with framework-specific patterns, tools, and code examples. Each file references its common counterpart.
Installation
Option 1: Install Script (Recommended)
# Install common + one or more language-specific rule sets
./install.sh typescript
./install.sh angular
./install.sh python
./install.sh golang
./install.sh web
./install.sh swift
./install.sh php
./install.sh ruby
./install.sh arkts
# Install multiple languages at once
./install.sh typescript python
Option 2: Manual Installation
Important: Copy entire directories — do NOT flatten with
/*. Common and language-specific directories contain files with the same names. Flattening them into one directory causes language-specific files to overwrite common rules, and breaks the relative../common/references used by language-specific files.
# Install common rules (required for all projects)
cp -r rules/common ~/.claude/rules/common
# Install language-specific rules based on your project's tech stack
cp -r rules/typescript ~/.claude/rules/typescript
cp -r rules/angular ~/.claude/rules/angular
cp -r rules/python ~/.claude/rules/python
cp -r rules/golang ~/.claude/rules/golang
cp -r rules/web ~/.claude/rules/web
cp -r rules/swift ~/.claude/rules/swift
cp -r rules/php ~/.claude/rules/php
cp -r rules/ruby ~/.claude/rules/ruby
cp -r rules/arkts ~/.claude/rules/arkts
# Attention ! ! ! Configure according to your actual project requirements; the configuration here is for reference only.
Rules vs Skills
- Rules define standards, conventions, and checklists that apply broadly (e.g., "80% test coverage", "no hardcoded secrets").
- Skills (
skills/directory) provide deep, actionable reference material for specific tasks (e.g.,python-patterns,golang-testing).
Language-specific rule files reference relevant skills where appropriate. Rules tell you what to do; skills tell you how to do it.
Adding a New Language
To add support for a new language (e.g., rust/):
- Create a
rules/rust/directory - Add files that extend the common rules:
coding-style.md— formatting tools, idioms, error handling patternstesting.md— test framework, coverage tools, test organizationpatterns.md— language-specific design patternshooks.md— PostToolUse hooks for formatters, linters, type checkerssecurity.md— secret management, security scanning tools
- Each file should start with:
> This file extends [common/xxx.md](../common/xxx.md) with <Language> specific content. - Reference existing skills if available, or create new ones under
skills/.
For non-language domains like web/, follow the same layered pattern when there is enough reusable domain-specific guidance to justify a standalone ruleset.
Rule Priority
When language-specific rules and common rules conflict, language-specific rules take precedence (specific overrides general). This follows the standard layered configuration pattern (similar to CSS specificity or .gitignore precedence).
rules/common/defines universal defaults applicable to all projects.rules/golang/,rules/python/,rules/swift/,rules/php/,rules/typescript/, etc. override those defaults where language idioms differ.
Example
common/coding-style.md recommends immutability as a default principle. A language-specific golang/coding-style.md can override this:
Idiomatic Go uses pointer receivers for struct mutation — see common/coding-style.md for the general principle, but Go-idiomatic mutation is preferred here.
Common rules with override notes
Rules in rules/common/ that may be overridden by language-specific files are marked with:
Language note: This rule may be overridden by language-specific rules for languages where this pattern is not idiomatic.