SKILL · coding
Triażowanie Długu Technicznego
Systematyczny framework do oceny, kategoryzowania i priorytetyzowania długu technicznego. Tworzy inwentarz długu z oceną wpływu, szacunkami kosztów naprawy i priorytetyzowanym planem działania. Zamienia ogólnikowe „powinniśmy to zrefaktoryzować" w konkretne decyzje: co naprawić, z czym żyć, co zaplanować i co usunąć.
Requires
Zainstaluj jako skill Claude Code
Umieść w ~/.claude/skills/<nazwa>/SKILL.md
Triażowanie Długu Technicznego
Co robi ten skill
Zamienia ogólnikowe „powinniśmy to zrefaktoryzować" w konkretne, priorytetyzowane decyzje. Tworzy inwentarz długu technicznego z analizą wpływu i jasnym planem działania.
Skill odpowiada na trzy pytania:
- Jaki dług faktycznie mamy? (inwentarz)
- Który dług najbardziej nam szkodzi? (priorytetyzacja)
- Co z tym zrobić? (plan działania)
Kategorie długu
| Kategoria | Opis | Przykład |
|---|---|---|
| Architektura | Decyzje strukturalne ograniczające system | Monolit, który powinien być serwisami |
| Design | Organizacja kodu i naruszenia wzorców | God class, zależności cykliczne |
| Jakość kodu | Czytelność, duplikacja, złożoność | Plik 2000 linii, logika copy-paste |
| Testowanie | Brakujące lub nieadekwatne pokrycie testami | Brak testów integracyjnych, niestabilne testy |
| Infrastruktura | Przestarzałe zależności, brak automatyzacji | Framework sprzed 3 lat |
| Dokumentacja | Brakująca lub nieaktualna dokumentacja | README z początkowego commita |
| Bezpieczeństwo | Znane podatności jeszcze nienaprawione | Przestarzała biblioteka auth |
Macierz oceny wpływu
Każdy element długu dostaje dwie oceny (1-5):
Ocena bólu — Jak bardzo to nam dziś szkodzi?
- 5: Blokuje prace nad funkcjami, powoduje incydenty
- 4: Znacząco spowalnia każdy sprint
- 3: Powoduje regularną irytację
- 2: Denerwujące, ale istnieje obejście
- 1: Teoretyczny problem, brak obecnego bólu
Ocena ryzyka — Jak niebezpieczne jest zostawienie tego?
- 5: Podatność bezpieczeństwa lub ryzyko utraty danych
- 4: Stabilność systemu zagrożona pod obciążeniem
- 3: Stanie się krytyczne w ciągu 3 miesięcy
- 2: Stanie się bolesne w ciągu 6 miesięcy
- 1: Niskie ryzyko, długi horyzont czasowy
Priorytet = Ból x Ryzyko (skala 1-25)
Szacowanie kosztów naprawy
Dla każdego elementu oszacuj:
- Rozmiar koszulkowy: XS (godziny) | S (1-2 dni) | M (3-5 dni) | L (1-2 tygodnie) | XL (sprint+)
- Ryzyko naprawy: Jak prawdopodobne, że ta naprawa wprowadzi nowe problemy?
- Zależności: Co jeszcze musi się zmienić?
Kategorie działań
Na podstawie priorytetu vs. kosztu:
| Niski koszt | Wysoki koszt | |
|---|---|---|
| Wysoki priorytet | Napraw teraz — szybkie wygrane redukujące ból | Zaplanuj — dedykowany sprint |
| Niski priorytet | Oportunistycznie — napraw przy okazji dotykania kodu | Zaakceptuj — udokumentuj i idź dalej |
Plus jedna specjalna kategoria:
- Usuń — kod/funkcje, których nikt nie używa. Najlepszy refaktoring to usunięcie.
Proces
- Inwentaryzuj — przeskanuj codebase, zbierz znane elementy długu od zespołu
- Kategoryzuj — przypisz każdy element do kategorii długu
- Oceń — oceń ból i ryzyko dla każdego elementu
- Szacuj — rozmiar koszulkowy wysiłku naprawy
- Priorytetyzuj — posortuj po wyniku priorytetu, pogrupuj w kategorie działań
- Zaplanuj — stwórz konkretny harmonogram: co w tym sprincie, następnym, w tym kwartale
Format wyjścia
## Triażowanie Długu Technicznego: {nazwa projektu}
### Inwentarz długu
| # | Element | Kategoria | Ból | Ryzyko | Priorytet | Koszt | Działanie |
|---|---------|-----------|-----|--------|-----------|-------|-----------|
| 1 | ... | Architektura | 5 | 4 | 20 | L | Zaplanuj |
| 2 | ... | Bezpieczeństwo | 3 | 5 | 15 | S | Napraw teraz |
### Napraw teraz (ten sprint)
- Element 2: {opis + konkretne podejście do naprawy}
### Zaplanuj (dedykowany wysiłek)
- Element 1: {opis + zakres + sugerowany harmonogram}
### Oportunistycznie (przy dotykaniu tego kodu)
- ...
### Zaakceptuj (udokumentuj i idź dalej)
- ...
### Kandydaci do usunięcia
- ...
Antywzorce
- Listowanie długu bez oceniania go (wszystko wydaje się równie ważne)
- Traktowanie całego długu jako równy priorytet
- Refaktoryzowanie bez mierzenia wpływu
- Perfekcjonizm — z częścią długu da się żyć
- Ignorowanie opcji „usuń" — nieużywany kod to najgorszy dług