Developer · FREE

Dokumentacja z diffa

Z git diffa albo opisu zmiany pisze changelog dla człowieka i patch do docs. Skutek dla użytkownika, nie lista plików. Kopiujesz notę do changelogu, maila do klienta albo pomocy.

reviewed:

Jak zainstalować

  1. Uzupełnij pola poniżej (albo zostaw nazwy zmiennych i dopisz w czacie). Wartości z Skill creatora na liście podstawiają się same.
  2. Kopiuj, potem wklej w Claude.ai (instrukcje projektu) albo ChatGPT (Custom Instructions).
  3. Albo pobierz SKILL.md i połóż w folderze skilli Claude Code.
SKILL
Odbiorca noty (user / klient B2B / changelog publiczny): [ODBIORCA].
Co już jest w docs (wklejka albo "brak"): [DOCS].
Diff, lista commitów albo opis zmiany:

[DIFF]

Jeśli [DIFF] pusty - poproś o `git diff` / listę commitów / opis scalonego PR i stop.
Puste [ODBIORCA] = przyjmij "user produktu" i napisz to na górze.
Puste [DOCS] = patch do docs oznacz jako `[NOWY FRAGMENT, nie wiem co nadpisać]`.

To nie jest recenzja kodu i nie jest dump `git log`. Piszesz dla człowieka, który nie otworzy hunku.

Zwracasz trzy bloki, w tej kolejności.

## 1. Co się zmieniło i co robi

Max 8 zdań. Język [ODBIORCA].

Tłumacz hunk na skutek:
- źle: "+12 -4 SkillKopiuj.astro", "refaktor utils"
- dobrze: "przycisk Kopiuj działa bez włączonego JS"

Każde zdanie = 1 skutek, który da się kliknąć albo zobaczyć. Cisza o refaktorze, rename, formatowaniu, bumpie zależności, jeśli użytkownik nic nie zauważy.

Rozdział w notatce (pomijasz puste):

- breaking - coś przestaje działać albo wymaga innej klikalnej ścieżki
- fix - zepsute zaczyna działać
- docs - zmiana tylko w pomocy / komentarzu dla człowieka

Nie mieszaj breaking z "drobną poprawką". Jeśli w [DIFF] nie ma breaking - nie wymyślaj.

## 2. Patch do docs

Nagłówki + akapity gotowe do wklejenia. Jeśli [DOCS] wskazuje konkretną sekcję - pisz jako zamiana "było -> jest". Jeśli docs milczy o tej funkcji - dopisz fragment pod istniejącym H2 albo `[NOWY H2]`.

Nie kopiuj nazw plików źródłowych do pomocy. Nie zostawiaj "zobacz PR #".

## 3. Czego nie opisano (wewnętrzne)

Lista rzeczy z [DIFF], które świadomie wypadają z noty: refaktor bez skutku, testy, CI, sekrety, ścieżki deweloperskie. 1 linia na pozycję. Pusta lista = napisz "nic wewnętrznego do ukrycia".

## Zakazy

- obietnice "wkrótce", "planujemy", "w następnej wersji", jeśli tego nie ma w [DIFF]
- zmyślone funkcje, zrzuty, liczby użytkowników
- unified diff w nocie dla [ODBIORCA]
- "lgtm", "czytelny kod", lista 20 plików
- recenzja bezpieczeństwa (to inny skill)

Jeśli [DIFF] wygląda na niepełny (ucięty hunk, sam tytuł PR) - daj notę z `[NIEPEWNY SKUTEK]` przy zgadniętych zdaniach, nie udawaj pełnego obrazu.

Dywiz "-". Strona czynna.

Zanim wkleisz

Skill vs zły prompt

Zły prompt

Zrob changelog z tego diffa, wymien wszystkie pliki i napisz co bedzie w nastepnej wersji.

Skill

Odbiorca noty (user / klient B2B / changelog publiczny): [ODBIORCA].
Co już jest w docs (wklejka albo "brak"): [DOCS].
Diff, lista commitów albo opis zmiany:

[DIFF]

Jeśli [DIFF] pusty - poproś o `git diff` / listę commitów / opis scalonego PR i stop.
Puste [ODBIORCA] = przyjmij "user produktu" i napisz to na górze.

Użyj z tym narzędziem

Lekcja: claude-start-06-claude-dla-programisty

Pytania

Jak użyć skilla "Dokumentacja z diffa" w Claude?

Uzupełnij pola w nawiasach (albo weź je z profilu Skill creator na /skille), kliknij Kopiuj i wklej treść do instrukcji projektu w Claude.ai. W Claude Code kliknij Pobierz SKILL.md i połóż plik w folderze skilli. Skill działa też w ChatGPT (Custom Instructions). Nie chowa się za paywallem: kopia jest darmowa.

Kiedy tego skilla NIE używać?

Nie do recenzji kodu (tam review senior). Nie do ADR. Nie zmyślać funkcji, których nie ma w diffie.