Menú
Przegląd i odświeżanie bazy wiedzy docs/solutions/.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Aktualizuje maszynerię workflow (.claude/: skille, agenci, reguły, hooki, workflows, templates + settings.json) w bieżącym projekcie, zaciągając najnowszą wersję z repo szablonu claude-code-starter. Jednym uruchomieniem sprawdza czy w szablonie pojawiły się jakiekolwiek zmiany i automatycznie je aplikuje. Używaj gdy: „zaktualizuj szablon", „zsynchronizuj .claude", „zaciągnij zmiany z szablonu", „sync template", „czy są nowe skille/agenci", „update workflow", „odśwież folder Claude" — a także po wrzuceniu tego szablonu do nowego projektu, żeby dociągnąć maszynerię. Wywołuj TEN skill zawsze gdy user chce zsynchronizować konfigurację Claude Code z centralnym szablonem, nawet jeśli nie nazwie tego wprost „synchronizacją".
"Cykliczny audyt aktualności skilli technicznych względem żywej dokumentacji (oficjalne docs, changelogi GitHub, npm registry). Weryfikuje wersje, pinowane paczki i wzorce API z żywych źródeł, nie z pamięci modelu. Używaj przy: „audyt aktualności", „freshness", „czy skille są aktualne", „sprawdź wersje w skillach", „czy Stripe/React/Zod w skillach jest aktualny", przeglądzie przeterminowań w guidelines technicznych."
Automatyzacja przeglądarki przez CLI agent-browser. Nawigacja, formularze, screenshoty, scraping, testowanie UI — wszystko przez komendy Bash z ref-based element selection (@e1, @e2). Używaj przy "otwórz stronę", "wypełnij formularz", "zrób screenshot", "scrape page", "testuj UI", "agent-browser".
Walidacja i doprecyzowanie pomysłu przed planowaniem. Interaktywny dialog, pressure test, eksploracja podejść, requirements doc. Używaj przy "mam pomysł", "zróbmy brainstorm", "co myślisz o", "pomóż mi przemyśleć", "chcę zbudować", niejasny scope, wiele możliwych rozwiązań.
Archiwizacja ukończonego zadania i wyciągnięcie kluczowych wniosków.
Kontynuacja pracy nad zadaniem - wykonanie kolejnej fazy/etapu.
| name | dev-compound-refresh |
| description | Przegląd i odświeżanie bazy wiedzy docs/solutions/. |
| argument-hint | [opcjonalnie: kategoria do przejrzenia] |
Uwaga: Aktualny rok to 2026. Używaj tego przy datowaniu dokumentów.
Utrzymuje jakość docs/solutions/ oraz reguł w .claude/rules/learned-patterns.md w czasie. Workflow przeglada istniejące dokumenty rozwiązań względem aktualnego codebase, a następnie odświeża dokumenty wzorcowe (pattern docs) zależne od nich.
Domyślny tryb: AUTONOMICZNY — bez pytań, przetwarza wszystko w scope, generuje raport.
| Tryb | Kiedy | Zachowanie |
|---|---|---|
| Autonomiczny (domyślnie) | Bez argumentów lub z argumentem kategorii | Bez interakcji z użytkownikiem. Wykonaj wszystkie jednoznaczne akcje. Oznacz niejednoznaczne przypadki jako stale. Wygeneruj raport końcowy. |
| Z argumentem | Podana kategoria lub słowo kluczowe | Przegląda tylko wskazaną kategorię/obszar |
docs/solutions/. Z argumentem = przetwarzaj tylko dopasowany zakres.status: stale, stale_reason, stale_date we frontmatter.<category_hint> #$ARGUMENTS </category_hint>
Odświeżaj w tej kolejności:
.claude/rules/learned-patterns.md — usuń reguły bez aktualnego źródła, zaktualizuj po Replace, zdeduplikuj, wyegzekwuj limit ~50docs/CONCEPTS.md (jeśli istnieje) — słownik domenowy. Usuń hasła, których kod/feature już nie istnieje; scal duplikaty; zweryfikuj, że definicje pasują do aktualnego zachowania; zamień treść skopiowaną z CLAUDE.md na link. Trzymaj formę cienkiego indeksu (1-2 zdania na hasło, alfabetycznie). Nie dubluj tu wiedzy z docs/solutions/ — to glosariusz pojęć, nie baza rozwiązań.Dlaczego ta kolejność:
Dla każdego dokumentu sklasyfikuj go do jednego z czterech wyników:
| Wynik | Znaczenie | Domyślna akcja |
|---|---|---|
| Keep | Nadal dokładny i przydatny | Brak edycji pliku; raportuj że przejrzano i pozostaje wiarygodny |
| Update | Główne rozwiązanie nadal poprawne, ale referencje się rozjechały | Zastosuj poprawki in-place poparte dowodami |
| Replace | Stary dokument jest teraz mylący, ale istnieje znane lepsze zastępstwo | Stwórz godnego zaufania następcę, a stary dokument oznacz/zarchiwizuj |
| Archive | Nie jest już przydatny ani mający zastosowanie | Przenieś do docs/solutions/_archived/ z metadanymi archiwizacji |
Zacznij od odkrywania dokumentów pod docs/solutions/.
Wyklucz:
README.mddocs/solutions/_archived/Znajdź wszystkie pliki .md pod docs/solutions/, wykluczając pliki README.md i wszystko pod _archived/.
Jeśli $ARGUMENTS podano, użyj go do zawężenia zakresu. Próbuj te strategie dopasowania w kolejności, zatrzymując się na pierwszej która daje wyniki:
docs/solutions/ (np. performance-issues, database-issues)module, component lub tags we frontmatterJeśli nie znaleziono dopasowań, raportuj to i zakończ — nie zgaduj zakresu.
Jeśli nie znaleziono żadnych dokumentów kandydujących, raportuj:
Nie znaleziono dokumentów kandydujących w docs/solutions/.
Uruchom /dev-compound po rozwiązaniu problemów żeby zacząć budować bazę wiedzy.
Przed klasyfikacją czegokolwiek:
| Zakres | Kiedy | Styl pracy |
|---|---|---|
| Skupiony | 1-2 prawdopodobne pliki lub argument wskazuje konkretny dokument | Zbadaj bezpośrednio, potem wykonaj akcję |
| Wsadowy | Do ~8 w większości niezależnych dokumentów | Zbadaj najpierw, potem wykonaj zgrupowane akcje |
| Szeroki | 9+ dokumentów, niejednoznaczne, lub przegląd całego repo | Triażuj najpierw, potem badaj partiami |
Gdy zakres jest szeroki (9+ dokumentów kandydujących), zrób lekki triaż przed głębokim badaniem:
Dla każdego dokumentu w zakresie, przeczytaj go, porównaj jego twierdzenia z aktualnym codebase i sformułuj rekomendację.
Dokument ma kilka wymiarów, które mogą niezależnie się zdezaktualizować. Powierzchowne sprawdzenia łapią oczywisty dryf, ale przestarzałość często kryje się głębiej:
Dopasuj głębokość badania do specyficzności dokumentu — dokument referencjujący dokładne ścieżki plików i fragmenty kodu wymaga więcej weryfikacji niż opisujący ogólną zasadę.
Kluczowe rozróżnienie to czy dryf jest kosmetyczny (referencje się przeniosły ale rozwiązanie jest to samo) czy merytoryczny (samo rozwiązanie się zmieniło):
/dev-compound: frontmatter YAML (title, category, date, module, component, tags), opis problemu, root cause, aktualne rozwiązanie z przykładami kodu i zapobieganie.Granica: jeśli przepisujesz sekcję rozwiązania lub zmieniasz to co dokument rekomenduje, zatrzymaj się — to Replace, nie Update.
Trzy wytyczne, które łatwo pomylić:
Po przejrzeniu dokumentów rozwiązań, zbadaj powiązane dokumenty wzorcowe pod docs/solutions/patterns/.
Dokumenty wzorcowe mają wysoki dźwignię — przestarzały wzorzec jest bardziej niebezpieczny niż przestarzałe pojedyncze rozwiązanie, bo przyszła praca może traktować go jako szeroko stosowalne wskazówki. Oceń czy uogólniona reguła nadal obowiązuje, biorąc pod uwagę odświeżony stan rozwiązań na których bazuje.
Dokument wzorcowy bez wyraźnych wspierających rozwiązań to sygnał przestarzałości — zbadaj uważnie przed zostawieniem bez zmian.
Po przejrzeniu dokumentów rozwiązań i wzorcowych, przejrzyj reguły w .claude/rules/learned-patterns.md.
Jeśli plik nie istnieje — pomiń tę fazę.
Dla KAŻDEJ reguły w pliku:
Odczytaj ścieżkę Source z reguły
Sprawdź status źródła:
docs/solutions/?docs/solutions/_archived/ w tej lub wcześniejszej sesji refresh?superseded_by we frontmatter?Klasyfikacja akcji na regule:
| Stan źródła | Akcja na regule |
|---|---|
| Źródło istnieje i jest Keep/Update | Zachowaj regułę bez zmian |
| Źródło zostało Replace | Zaktualizuj Source na nowy plik następcy. Jeśli treść reguły jest nadal prawdziwa — zachowaj. Jeśli następca zmienia rekomendację — przepisz regułę na podstawie nowego następcy |
| Źródło zostało Archive | Usuń regułę — problem nie jest już aktualny |
| Źródło nie istnieje (brak pliku, brak archiwum) | Zweryfikuj aktualność reguły na podstawie codebase. Jeśli nadal poprawna — zachowaj z adnotacją (źródło usunięte, reguła zachowana). Jeśli nie można zweryfikować — usuń |
Deduplikacja:
Egzekwowanie limitu ~50:
<!-- rule-count: N -->Zapisz zmodyfikowany plik jeśli wprowadzono jakiekolwiek zmiany.
Używaj subagentów do izolacji kontekstu przy badaniu wielu artefaktów — nie tylko dlatego, że zadanie brzmi złożono. Wybierz najlżejsze podejście które pasuje:
| Podejście | Kiedy użyć |
|---|---|
| Tylko główny wątek | Mały zakres, krótkie dokumenty |
| Sekwencyjne subagenty | 1-2 artefakty z wieloma wspierającymi plikami do przeczytania |
| Równoległe subagenty | 3+ naprawdę niezależne artefakty z małym nakładaniem |
| Wsadowe subagenty | Szerokie przeglądy — najpierw zawęź zakres, potem badaj partiami |
Przy uruchamianiu dowolnego subagenta, dołącz tę instrukcję w jego zadaniu:
Używaj dedykowanych narzędzi do wyszukiwania i czytania plików (Glob, Grep, Read) do całego badania. NIE używaj komend shell (ls, find, cat, grep, test, bash) do operacji na plikach. Unikaj promptów o uprawnienia i jest to bardziej niezawodne.
Dwie role subagentów:
Orkiestrator łączy wyniki badań, wykrywa sprzeczności, koordynuje subagenty zastępujące i wykonuje wszystkie operacje archiwizacji/metadanych centralnie. Oznacza niejednoznaczne przypadki jako stale. Jeśli dwa artefakty nakładają się lub omawiają ten sam problem, badaj je razem zamiast równolegle.
Po zebraniu dowodów, przypisz jedną rekomendowaną akcję.
Dokument jest nadal dokładny i przydatny. Nie edytuj pliku — raportuj że przejrzano i pozostaje wiarygodny. Dodaj last_refreshed tylko jeśli już dokonujesz znaczącej aktualizacji z innego powodu.
Główne rozwiązanie nadal aktualne ale referencje się rozjechały (ścieżki, nazwy klas, linki, fragmenty kodu, metadane). Zastosuj poprawki bezpośrednio.
Przykłady prawidłowych aktualizacji in-place:
app/models/auth_token.rb na app/models/session_token.rbmodule: AuthToken na module: SessionTokenPrzykłady które nie powinny być aktualizacjami in-place:
Te przypadki wymagają Replace, nie Update.
Wybierz Replace gdy główne wskazówki dokumentu są teraz mylące — rekomendowany fix zmienił się materialnie, root cause lub architektura się przesunęła, lub preferowany wzorzec jest inny.
Ocena dowodów:
Do czasu identyfikacji kandydata Replace, badanie Fazy 1 zebrało już znaczące dowody: twierdzenia starego dokumentu, co aktualny kod faktycznie robi i gdzie wystąpił dryf. Oceń czy te dowody są wystarczające do napisania godnego zaufania zastępstwa:
status: stale, stale_reason: [co znalazłeś], stale_date: YYYY-MM-DD do frontmatter/dev-compound po następnym spotkaniu z tym obszaremWybierz Archive gdy:
Akcja:
docs/solutions/_archived/, zachowując strukturę katalogów gdy pomocnearchived_date: YYYY-MM-DDarchive_reason: [dlaczego zarchiwizowano]Gdy referencjowane pliki dokumentu zniknęły, to silne dowody — ale tylko że implementacja zniknęła. Przed archiwizacją zastanów się czy problem który dokument rozwiązuje jest nadal aktualny w codebase:
auth_token.rb zniknął — czy aplikacja nadal obsługuje tokeny sesji? Jeśli tak, koncepcja trwa pod nową implementacją. To Replace, nie Archive.Nie szukaj mechanicznie słów kluczowych ze starego dokumentu. Zamiast tego zrozum jaki problem dokument adresuje, potem zbadaj czy ta domena problemu nadal istnieje w codebase.
Auto-archiwizuj tylko gdy zniknęła ZARÓWNO implementacja JAK I domena problemu:
Jeśli implementacja zniknęła ale domena problemu trwa (aplikacja nadal robi auth, nadal przetwarza płatności, nadal obsługuje migracje), klasyfikuj jako Replace — problem nadal ma znaczenie i aktualne podejście powinno być udokumentowane.
Stosuj te same cztery wyniki (Keep, Update, Replace, Archive) do dokumentów wzorcowych, ale oceniaj je jako pochodne wskazówki a nie rozwiązania na poziomie incydentu. Kluczowe różnice:
Wykonaj wszystkie akcje na podstawie klasyfikacji z Fazy 2:
Brak edycji pliku. Podsumuj dlaczego dokument pozostaje wiarygodny.
Zastosuj edycje in-place tylko gdy rozwiązanie jest nadal merytorycznie poprawne.
Przetwarzaj kandydatów Replace jeden na raz, sekwencyjnie. Każde zastępstwo pisane jest przez subagenta dla ochrony głównego okna kontekstu.
Gdy dowody wystarczające:
/dev-compound: frontmatter YAML (title, category, date, module, component, tags), opis problemu, root cause, aktualne rozwiązanie z przykładami kodu i zapobieganie.superseded_by: [ścieżka nowego dokumentu] do frontmatter starego dokumentudocs/solutions/_archived/Gdy dowody niewystarczające:
status: stale, stale_reason: [co znalazłeś], stale_date: YYYY-MM-DD/dev-compound po następnym spotkaniu z tym obszaremArchiwizuj tylko gdy dokument jest wyraźnie przestarzały lub redundantny. Nie archiwizuj dokumentu tylko dlatego, że jest stary.
Pełny raport MUSI być wydrukowany jako output markdown. Nie streszczaj wewnętrznie wyników i nie wypuszczaj jednolinijkowego podsumowania. Raport jest produktem — drukuj każdą sekcję w całości, sformatowaną jako czytelny markdown z nagłówkami, tabelami i bullet pointami.
Po przetworzeniu wybranego zakresu, wypisz następujący raport:
Compound Refresh — Podsumowanie
================================
Przeskanowano: N dokumentów
Zachowano (Keep): X
Zaktualizowano (Update): Y
Zastąpiono (Replace): Z
Zarchiwizowano (Archive): W
Pominięto: V
Oznaczono jako stale: S
Następnie dla KAŻDEGO przetworzonego pliku podaj:
Dla wyników Keep, umieść je w sekcji przejrzanych-bez-edycji żeby wynik był widoczny bez tworzenia churnu git.
Jeśli plik istnieje i był przeglądany w Fazie 1.7, dodaj sekcję:
Learned Patterns:
Reguł przed refresh: N
Reguł po refresh: M
Usunięte (źródło zarchiwizowane): X
Zaktualizowane (źródło zastąpione): Y
Zduplikowane (zmergowane): Z
Raport jest jedynym produktem — nie ma użytkownika do zadawania dodatkowych pytań, więc raport musi być samowystarczalny i kompletny. Drukuj pełny raport. Nie skracaj, nie streszczaj, nie pomijaj sekcji.
Podziel akcje na dwie sekcje:
Wykonane (zapisy które się powiodły):
Rekomendowane (akcje których nie udało się zapisać):
Jeśli wszystkie zapisy się powiodą, sekcja Rekomendowane jest pusta. Jeśli żaden zapis się nie powiedzie, wszystkie akcje trafiają pod Rekomendowane — raport staje się planem utrzymania.
/dev-compound przechwytuje nowo rozwiązany, zweryfikowany problem/dev-compound-refresh utrzymuje starsze dokumenty gdy codebase ewoluujeUżywaj Replace tylko gdy proces odświeżania ma wystarczające prawdziwe dowody do napisania godnego zaufania następcy. Gdy dowody są niewystarczające, oznacz jako stale i zarekomenduj /dev-compound na gdy użytkownik następnym razem natrafi na ten obszar problemu.