coderabbit-setup — konfiguracja CodeRabbit dla projektu

Tworzy .coderabbit.yaml w korzeniu repo — spójny ze standardem z pozostałych projektów (język polski, profil assertive, te same tools i reguły kodu projektu), a dopasowany do stacku bieżącego projektu.

Pliki skilla

• templates/coderabbit-base.yaml — część wspólna configu (tone, review, tools, knowledge_base). Zawiera komentarze # STACK: i # UZUPEŁNIJ: wskazujące miejsca do dopasowania.
• reference/stack-blocks.md — gotowe bloki path_filters + path_instructions per stack, z sygnałami detekcji.

Stała ścieżki reguł kodu: CODING_RULES = .claude/rules/coding-rules.md. To jedyne miejsce z tą ścieżką — template ma w jej miejscu znacznik {{CODING_RULES}}, który przy sklejaniu zastępujesz wartością stałej.

Wykonanie

1. Sprawdź istniejący config. Jeśli .coderabbit.yaml już istnieje w korzeniu repo — pokaż userowi diff względem tego, co byś wygenerował, i ZAPYTAJ czy nadpisać. Nie nadpisuj bez potwierdzenia.

2. Wykryj stack. Przeczytaj package.json (dependencies + devDependencies) i strukturę katalogów. Sygnały detekcji są opisane przy każdym bloku w reference/stack-blocks.md. Jeśli user podał stack w argumencie — użyj go zamiast detekcji. Jeśli detekcja jest niejednoznaczna (np. brak package.json) — ZAPYTAJ usera o stack, nie zgaduj.

3. Sklej config. Weź templates/coderabbit-base.yaml w całości i:

   • dołóż do path_filters i path_instructions bloki wykrytego stacku (Supabase łączy się z blokiem frontowym),
   • w path_instructions zostaw TYLKO wpisy dla katalogów, które istnieją w projekcie (wyjątek: świeży projekt przed init — wtedy zostaw z komentarzem, że filtry są przygotowane z wyprzedzeniem); wpisy z template'u bazowego zostają zawsze — e2e/seeds/ dopisuje pipeline,
   • każdy znacznik {{CODING_RULES}} zastąp wartością stałej z sekcji „Pliki skilla”,
   • w knowledge_base.code_guidelines.filePatterns wpisz TYLKO istniejące pliki — sprawdź kolejno: plik ze stałej CODING_RULES, CLAUDE.md, dodatkowe konwencje w docs/ (np. docs/figma-build-conventions.md); gdy pliku ze stałej nie ma, usuń go także z pierwszej linii bloku **/*.{ts,tsx},
   • jeśli branch główny to nie main (sprawdź git symbolic-ref refs/remotes/origin/HEAD lub git branch) — popraw base_branches.

4. Zapisz jako .coderabbit.yaml w korzeniu repo (git toplevel, nie cwd).

5. Zwaliduj YAML. Uruchom:

   ruby -ryaml -e 't = File.read(".coderabbit.yaml"); c = YAML.load(t); abort "niepodstawiony {{CODING_RULES}}" if t.include?("{{CODING_RULES}}"); abort "tone_instructions > 250 zn." if c["tone_instructions"].to_s.size > 250; puts "YAML OK"'
   

   (systemowy ruby jest na macOS; gdyby go nie było — zwaliduj innym dostępnym parserem YAML). Błąd = napraw plik, nie pomijaj walidacji. Schemat CodeRabbit odrzuca tone_instructions dłuższe niż 250 znaków i nieznane klucze najwyższego poziomu — wtedy bot ignoruje cały plik bez komunikatu w PR. Template skilla jest sprawdzany schematem w teście __tests__/generator.test.mjs; dokładaj więc tylko klucze, które w nim są.

6. Zweryfikuj instalację aplikacji GitHub CodeRabbit — KROK OBOWIĄZKOWY, nie pomijaj go nigdy. Bez zainstalowanej aplikacji config jest martwym plikiem. Instalacji nie da się wykonać z CLI, ale da się ją WYKRYĆ:

   gh api user/installations --jq '.installations[] | select(.app_slug == "coderabbitai") | .account.login'
   

   • Wynik zawiera ownera repo (porównaj z gh repo view --json owner -q .owner.login) → instalacja jest, odnotuj ✅.
   • Wynik pusty, brak ownera albo błąd → uznaj instalację za BRAKUJĄCĄ (❌). Sygnał potwierdzający: sprawdź, czy bot komentował ostatnie PR-y —

     gh pr list --state merged --limit 3 --json number -q '.[].number'
     gh api "repos/{owner}/{repo}/issues/<nr>/comments" --jq '[.[] | select(.user.login == "coderabbitai[bot]")] | length'
     

     Zero komentarzy bota na istniejących PR-ach = na pewno brak instalacji.

7. Raport dla usera — ZAWSZE wypisz wszystkie 4 punkty poniżej. Nie skracaj i nie pomijaj żadnego, nawet gdy wszystko jest OK:

   1. Wykryty stack + które bloki weszły do configu.
   2. Pliki wpisane do code_guidelines.filePatterns.
   3. Instalacja aplikacji GitHub CodeRabbit: ✅ albo ❌ (wynik kroku 6). Przy ❌ powiedz wprost: „Bez tego config NIE DZIAŁA. Jednorazowy krok ręczny w przeglądarce (nie da się z CLI): https://github.com/apps/coderabbitai → Configure → zaznacz to repo."
   4. Przypomnienie: .coderabbit.yaml trzeba zacommitować i wypchnąć — CodeRabbit czyta config z brancha PR-a, więc już pierwszy PR zawierający ten plik jest reviewowany według niego.

Bot bez szumu — jak dopisywać reguły

Wzorzec z 574 uwag bota na 19 PR (85% szumu wynikało z konfiguracji, nie z kodu). Zanim dopiszesz albo zmienisz instrukcję, sprawdź ją wobec tej listy:

1. Instrukcje per glob się sumują. Plik testowy dostaje blok **/*.{ts,tsx} i blok **/*.test.{ts,tsx} naraz — wyjątek wpisany tylko w węższym globie nie zdejmuje reguły z głównego. Wyjątki od reguły z bloku głównego wpisuj w bloku głównym.
2. Progi liczbowe z tolerancją. Bot zgłasza przekroczenie o 5 linii tak samo jak o 500. Próg w instrukcji to 360/60 (reguła 300/50 + 20%); twardy próg egzekwuje lint, nie bot.
3. Nazwij, czego reguła nie obejmuje. „Zero as” bot czyta dosłownie: bez zdania o as const, satisfies i rzutowaniach w atrapach testowych zgłasza każde z nich.
4. Reguła dotyczy typu pliku, nie całego katalogu. „Jeden eksport per plik” dotyczy komponentów-ekranów; pliki-kolekcje (ikony, kafle, typy propsów obok komponentu) są wyjątkiem wpisanym w tej samej instrukcji.
5. Preferencje bez wpływu na defekty wyłączaj w tone_instructions (układ Arrange-Act-Assert, docstringi, DRY w testach) — w limicie 250 zn.
6. Kod działający na bazie dostaje własną instrukcję. Seedy E2E i skrypty bez wpisu w path_instructions bot czyta bez kontekstu granicy zaufania i pomija pytanie, na jakiej bazie działają.
7. Pliki generowane wyklucz w path_filters. Ich kształt dyktuje generator — uwaga do stylu trafia w próżnię.
8. Nowa reguła dopiero po powtórce. Dopisz ją, gdy ta sama klasa uwagi wróciła w 2+ PR-ach, i sprawdź, czy nie zgłosi czegoś, co jest decyzją z CLAUDE.md albo docs/decisions/.

Czego NIE robić

• Nie dodawaj sekcji, których nie ma w template (np. pre_merge_checks, finishing_touches, slop_detection) — user świadomie z nich zrezygnował.
• Nie zmieniaj tone_instructions, profile ani listy tools bez wyraźnej prośby usera — to ustandaryzowane między projektami.
• Nie wpisuj do filePatterns plików, których nie ma w repo — CodeRabbit po cichu je zignoruje, a config kłamie.