Files
everything-claude-code/rules
konstapukarifastnetfi 8b24f63ede fix: refresh stale technical content in agents, rules, and skills (#2168)
Several published examples contained APIs that no longer exist, code that
does not run, or model versions that drifted from reality:

- agents/performance-optimizer.md used the web-vitals v3 API
  (getCLS/getFID/getLCP/getFCP/getTTFB) and reported FID. web-vitals v4
  renamed the imports to onCLS/onINP/onLCP/onFCP/onTTFB and FID was
  replaced by INP (target < 200ms)
- rules/common/performance.md pinned stale model versions in the
  model-selection guidance; refresh to the versions the repo itself uses
  (agent.yaml pins claude-opus-4-6) and add the PowerShell variant for
  MAX_THINKING_TOKENS next to the bash export
- skills/python-patterns/SKILL.md: both get_value examples referenced
  default_value without declaring the parameter (NameError); add
  default_value: Any = None to the EAFP and LBYL signatures
- skills/frontend-patterns/SKILL.md: the custom useQuery example rebuilt
  refetch whenever callers passed inline fetchers/options, re-triggering
  the effect after every state update (infinite fetch loop). Keep the
  latest fetcher/options in refs so refetch stays referentially stable.
  The PASS-labelled useMemo example mutated its input with in-place sort;
  copy before sorting
- skills/coding-standards/SKILL.md repeated the same PASS-labelled
  in-place-sort-in-useMemo example; same fix
- rules/typescript/security.md used a vendor-specific OPENAI_API_KEY in
  generic guidance; switch to a neutral API_KEY

Every hand-maintained copy of the affected content is synced in the same
change: locale mirrors (ja-JP, ko-KR, pt-BR, tr, zh-CN, zh-TW - each only
where it carries the affected file) and the .agents/.kiro/.cursor harness
mirrors. Two structural divergences are left alone and noted here:
.kiro/steering/performance.md has no extended-thinking control list to
carry the PowerShell variant, and docs/zh-TW/rules/performance.md keeps an
older condensed thinking section without the budget-cap line.
rules/zh/performance.md is intentionally untouched - the rules/zh tree is
being retired in a separate change
2026-06-07 13:26:01 +08:00
..
2026-03-10 20:42:54 -07:00
2026-03-16 13:35:23 -07:00

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

# 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.

Use the ECC-owned namespace below for user-level Claude installs. Flat package-level destinations can collide with non-ECC rule packs and do not match the main README guidance.

# Create the ECC rule namespace once.
mkdir -p ~/.claude/rules/ecc

# Install common rules (required for all projects)
cp -r rules/common ~/.claude/rules/ecc/

# Install language-specific rules based on your project's tech stack
cp -r rules/typescript ~/.claude/rules/ecc/
cp -r rules/angular ~/.claude/rules/ecc/
cp -r rules/python ~/.claude/rules/ecc/
cp -r rules/golang ~/.claude/rules/ecc/
cp -r rules/web ~/.claude/rules/ecc/
cp -r rules/swift ~/.claude/rules/ecc/
cp -r rules/php ~/.claude/rules/ecc/
cp -r rules/ruby ~/.claude/rules/ecc/
cp -r rules/arkts ~/.claude/rules/ecc/

# Attention ! ! ! Configure according to your actual project requirements; the configuration here is for reference only.

For project-local rules, use the same namespace under the project root:

mkdir -p .claude/rules/ecc
cp -r rules/common .claude/rules/ecc/
cp -r rules/typescript .claude/rules/ecc/

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/):

  1. Create a rules/rust/ directory
  2. Add files that extend the common rules:
    • coding-style.md — formatting tools, idioms, error handling patterns
    • testing.md — test framework, coverage tools, test organization
    • patterns.md — language-specific design patterns
    • hooks.md — PostToolUse hooks for formatters, linters, type checkers
    • security.md — secret management, security scanning tools
  3. Each file should start with:
    > This file extends [common/xxx.md](../common/xxx.md) with <Language> specific content.
    
  4. 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.