Code Rules
Universal rules for all languages + index to language-specific guides.
Language Rules
Should USE ‘English’ for all code comments, docstrings, and commit messages. This ensures clarity and consistency across projects and collaborators.
Tier 1: Essential (Universal)
ALWAYS follow these. No exceptions.
- Format before commit: Run the language-specific formatter
- Type hints / annotations: Required on all public functions
- No magic: No hidden side effects, no implicit behavior
- Tests: Write tests for new functionality
- Docstrings: On modules, classes, and public functions
Caution
Never use force flags (--force, -f, etc.) without first investigating the cause of failure. If apply or similar command fails, use diff or other diagnostic tools to understand the issue before attempting force.
Pre-Commit Documentation Check
Before committing, ask yourself:
- Did I add something new? (feature, file, module, command) → Is it documented?
- Did I remove or rename something? → Are old references cleaned up?
- Did I change behavior? (API, output, flags) → Are docs updated?
- Did I add dependencies? → Are they recorded? (requirements, package.json, etc.)
- Did I add code that needs a docstring? → Did I write it?
If any answer is "needs update" → update docs first, then commit everything together.
Commit Messages
- Each commit should focus on one thing. If the workspace has 3 changes, make 3 separate commits
- Documentation updates should be a separate commit. Reference the triggering commit in the message, e.g., "Update docs for X after Y commit" or standalone docs updates
- Format:
<type>(<scope>): <subject> where:
<type>: feat, fix, docs, style, refactor, test, chore<scope>: optional area of code affected (e.g. module name)<subject>: brief description of change (max 50 chars), English
Language Index
PLEASE FOLLOW THE LANGUAGE-SPECIFIC GUIDES FOR EACH LANGUAGE YOU USE. They contain important style rules and tool recommendations.
| Language |
Guide File |
Key Tools |
| Python |
languages/python.md |
uv, ruff, pytest |
| Lean |
languages/lean.md |
lake, mathlib style |
Common Mistakes (All Languages)
- ❌ Skipping format/lint before commit
- ❌ Missing type annotations on public APIs
- ❌ No docstrings on modules and classes
- ❌ Writing code before writing tests
- ❌ Committing without checking if docs need updating
1---2name: code-rules3description: Use when writing code, to follow personal code style and ensure documentation is consistent.4---56# Code Rules78Universal rules for all languages + index to language-specific guides.910## Language Rules11Should USE ‘English’ for all code comments, docstrings, and commit messages. This ensures clarity and consistency across projects and collaborators.1213## Tier 1: Essential (Universal)1415**ALWAYS follow these. No exceptions.**1617- **Format before commit**: Run the language-specific formatter18- **Type hints / annotations**: Required on all public functions19- **No magic**: No hidden side effects, no implicit behavior20- **Tests**: Write tests for new functionality21- **Docstrings**: On modules, classes, and public functions2223## Caution2425**Never use force flags** (`--force`, `-f`, etc.) without first investigating the cause of failure. If `apply` or similar command fails, use `diff` or other diagnostic tools to understand the issue before attempting force.2627## Pre-Commit Documentation Check2829Before committing, ask yourself:30311. **Did I add something new?** (feature, file, module, command) → Is it documented?322. **Did I remove or rename something?** → Are old references cleaned up?333. **Did I change behavior?** (API, output, flags) → Are docs updated?344. **Did I add dependencies?** → Are they recorded? (requirements, package.json, etc.)355. **Did I add code that needs a docstring?** → Did I write it?3637If any answer is "needs update" → update docs first, then commit everything together.3839## Commit Messages40- 1. Each commit should focus on one thing. If the workspace has 3 changes, make 3 separate commits41- 2. Documentation updates should be a separate commit. Reference the triggering commit in the message, e.g., "Update docs for X after Y commit" or standalone docs updates42- 3. Format: `<type>(<scope>): <subject>` where:43 - `<type>`: feat, fix, docs, style, refactor, test, chore44 - `<scope>`: optional area of code affected (e.g. module name)45 - `<subject>`: brief description of change (max 50 chars), English4647## Language Index48PLEASE FOLLOW THE LANGUAGE-SPECIFIC GUIDES FOR EACH LANGUAGE YOU USE. They contain important style rules and tool recommendations.49| Language | Guide File | Key Tools |50|----------|------------|-----------|51| Python | `languages/python.md` | uv, ruff, pytest |52| Lean | `languages/lean.md` | lake, mathlib style |5354## Common Mistakes (All Languages)5556- ❌ Skipping format/lint before commit57- ❌ Missing type annotations on public APIs58- ❌ No docstrings on modules and classes59- ❌ Writing code before writing tests60- ❌ Committing without checking if docs need updating
FrankieeW