Lekcja 7 · Kontekst na żądanie, nie zawsze
CLAUDE.md ma limit <200 linii, bo wszystko w nim ląduje w kontekście każdej sesji. W dużym repo zespołowym to za mało miejsca na konwencje frontendu, backendu, testów i bezpieczeństwa naraz. .claude/rules/ rozwiązuje to inaczej niż mogłoby się wydawać — samo rozbicie na pliki nic nie oszczędza. Oszczędza dopiero jedno konkretne pole frontmatteru.
| Kiedy ląduje w kontekście | Współdzielony? | |
|---|---|---|
| CLAUDE.md | zawsze, na starcie każdej sesji | tak (project) / nie (local) |
.claude/rules/*.md bez paths | zawsze, na starcie — dokładnie jak CLAUDE.md | tak, przez git |
.claude/rules/*.md z paths | dopiero gdy Claude czyta plik pasujący do wzorca | tak, przez git |
| Skill (Lekcja 3) | na żądanie: komenda albo decyzja modelu, że pasuje | tak, przez git |
.claude/rules/ bez pola paths ma dokładnie taki sam priorytet ładowania jak .claude/CLAUDE.md — rozbicie na osobne pliki porządkuje repo dla ludzi, ale nie zwalnia ani jednego tokena kontekstu. Realną oszczędność kontekstu daje dopiero paths: we frontmatterze: taka reguła ładuje się tylko wtedy, gdy Claude faktycznie otwiera pasujący plik — nie przy każdym innym wywołaniu narzędzia.
paths---
paths:
- "src/api/**/*.ts"
---
# API Development Rules
- Każdy endpoint musi mieć walidację wejścia
- Używaj standardowego formatu odpowiedzi błędu| Wzorzec | Dopasowuje |
|---|---|
**/*.ts | każdy plik .ts w dowolnym katalogu |
src/**/* | wszystkie pliki pod src/ |
src/**/*.{ts,tsx} | kilka rozszerzeń naraz (brace expansion) |
Reguła odpala się, gdy Claude czyta pasujący plik — nie przy każdym tool use w ogóle. Można mieć wiele wzorców w jednej regule i dowolnie zagnieżdżać pliki w podkatalogach (frontend/, backend/) — wszystkie .md są odkrywane rekurencyjnie.
Reguły osobiste w ~/.claude/rules/ (dla wszystkich Twoich projektów) ładują się przed regułami projektowymi w .claude/rules/ — dokładnie ta sama logika co w hierarchii settings.json z Lekcji 6: to co bliżej bieżącego projektu, czytane jest później i ma pierwszeństwo przy sprzeczności.
Ten projekt ma w CLAUDE.md sekcję "Konwencje" z zasadami tylko dla plików w lessons/ (długość opcji quizu, brak podpowiedzi przez formatowanie). To dobry kandydat na regułę przypiętą do ścieżki — nie musi ładować się, gdy pracujesz nad czymś innym niż lekcja.
.claude/rules/lekcje.md z frontmatterem:
---
paths:
- "lessons/**/*.html"
---
# Konwencje lekcji
- Opcje odpowiedzi w quizach: zbliżona długość (słowa/znaki)
- Bez podpowiedzi przez formatowanie
- Reużywaj assets/style.css i assets/quiz.js, nie duplikuj/memory i sprawdź, czy nowy plik pojawia się na liście — i czy jest oznaczony jako warunkowy (path-scoped).lessons/, a potem zapytaj, czy widzę treść tej reguły w kontekście.1. Masz regułę w .claude/rules/testing.md bez pola paths. Kiedy ląduje w kontekście?
2. Co dokładnie oszczędza kontekst przy dużym zestawie reguł w monorepo?
3. Kiedy dokładnie odpala się reguła ze scoped paths: "src/api/**/*.ts"?
4. Masz tę samą regułę zdefiniowaną i w ~/.claude/rules/ (user), i w .claude/rules/ (project), z różną treścią. Która "wygrywa" przy sprzeczności?
5. Masz proceduralne, wieloetapowe instrukcje ("jak wypuścić release"), potrzebne tylko czasem, nie w każdej sesji. Co lepiej pasuje niż .claude/rules/?