---
name: pr-changes-data
description: Pobiera dane o zmianach w PR (metadane, pliki, diff) w celu dalszych operacji — odniesienia do zmian, inteligentny port na inny branch z dostosowaniem do stanu brancha i konfliktów. Nie służy do code review. Use when user wants PR change data for porting, referencing, or applying changes to another branch.
---

# PR Changes Data

Skill do **pobierania danych o zmianach w PR** i **operowania na nich**: odniesienia w rozmowie, inteligentny port zmian na inny branch (z uwzględnieniem konfliktów i obecnego stanu brancha). **Nie jest to skill do code review** — dane są surowcem do dalszych akcji.

## Kiedy używać

- Użytkownik chce mieć "dane z PR" do późniejszego użycia (odniesienie, port, analiza).
- Użytkownik chce przenieść zmiany z PR na inny branch **inteligentnie** (dostosowanie do stanu brancha, konflikty), a nie przez zwykły cherry-pick.
- Użytkownik mówi o "snapshot PR", "dane z PR", "port zmian", "przenieś zmiany na branch X".

## Część 1 — Pobieranie danych PR

Cel: uzyskać ustrukturyzowany zestaw danych o zmianach, który można później cytować lub użyć do portu.

### Źródła danych

**GH CLI (preferowane gdy repo jest lokalnie):**
- Metadane: `gh pr view <PR> --json number,title,url,author,baseRefName,headRefName,additions,deletions,changedFiles,files,commits`
- Lista plików: z `files` w JSON lub `gh pr diff <PR> --name-only`
- Diff: `gh pr diff <PR>` (pełny) lub `gh pr diff <PR> --patch` (z patchami)
- Opcjonalnie skrypt: `agent-skills/gh-smart-port/scripts/pr_snapshot.sh <PR>` — zwraca meta + diffstat + początek diffu

**GitHub MCP (gdy potrzebny dostęp przez API):**
- `get_pull_request` — owner, repo, pull_number → szczegóły PR
- `get_pull_request_files` — lista zmienionych plików (path, status, patch itd.)
- Dla treści plików: `get_file_contents` po odpowiednim ref (np. head ref PR)

**Git (gdy masz branch PR lokalnie):**
- `git diff <baseRef>..<headRef>` — diff między base a head PR
- `git diff --name-status`, `git diff --stat`

### Format danych do zachowania / przekazania dalej

Przygotuj zwięzły "snapshot" w formie nadającej się do operacji:

- **Meta**: numer PR, tytuł, base branch, head branch, autor, additions/deletions, liczba plików.
- **Pliki**: ścieżki + status (added/modified/deleted/renamed).
- **Intencja zmian**: 1–2 zdania streszczenia "co PR robi" (na podstawie tytułu, plików, diff).
- **Obszary**: które moduły/pliki/API są dotknięte (lista).
- **Diff**: pełny lub skrócony — w zależności od limitu kontekstu; dla portu przydatny pełny diff lub patch per plik.

Można zapisać snapshot do pliku (np. `pr-<number>-snapshot.md` lub `.json`) w repo, jeśli użytkownik chce go użyć w kolejnych krokach.

## Część 2 — Operacje na danych

### 2.1 Odniesienie do zmian

Na podstawie snapshotu możesz:
- Odpowiadać na pytania typu "co zmienia ten PR w pliku X?", "które pliki dotykają API?"
- Cytować konkretne fragmenty diffu (plik, zakres linii, przed/po).
- Podsumować "co już jest w PR" przed decyzją o porcie.

### 2.2 Inteligentny port zmian na inny branch

**Cel:** przenieść zmiany z PR (lub brancha źródłowego) na **target branch**, dostosowując je do **obecnego stanu** targetu — w tym rozwiązanie konfliktów, bez polegania na prostym `git cherry-pick` (chyba że użytkownik wyraźnie go zażyczy).

**Kroki:**

1. **Źródło i target**  
   Określ: branch/PR źródłowy (np. head ref PR) i docelowy branch (np. `main`, `release/x`).

2. **Snapshot źródła**  
   Użyj Części 1; miej listę plików i diff (lub patch).

3. **Stan targetu**  
   Na target branchu: które z tych plików istnieją, czy się zmieniły względem base PR.  
   Przydatne: `git diff <base-ref>..<target-branch> -- <path>` dla wybranych ścieżek, `git status`, ewentualnie `git merge-base`.

4. **Strategie portu (wybór w zależności od sytuacji)**  
   - **Port po plikach** — gdy zmiany są spójne per plik i mało konfliktów:  
     `git checkout <target>`, potem `git checkout <source-ref> -- <path>` dla wybranych plików; ewentualnie `git add -p` do selekcji hunków.  
   - **Port po patchach / hunki** — gdy chcesz przenieść tylko fragmenty:  
     Zapisany diff z PR zastosować na target: `git apply` (lub `git apply -3` przy konfliktach 3-way), potem ręczne dopracowanie.  
   - **Port commitów** — tylko na wyraźną prośbę:  
     `git cherry-pick` / `git cherry-pick -n`; przy konfliktach — rozwiązanie, potem `git add` i `git cherry-pick --continue`.

5. **Konflikty**  
   Przy `git apply -3` lub `git checkout <ref> -- <path>` konflikty mogą wymagać ręcznego połączenia. Opisz użytkownikowi: które pliki kolidują, co w nich jest (np. "ta sama funkcja zmieniona w obu branchach") i zaproponuj konkretne miejsca do edycji lub krótkie instrukcje "co zostawić / co scalić".

6. **Po porcie**  
   Podaj checklistę: build, testy, smoke; ewentualnie `git diff <target>..HEAD` żeby pokazać, co faktycznie zostało dodane na target.

W raporcie portu podaj: które pliki/hunki przenosisz i dlaczego, gdzie są ryzyka konfliktów, oraz krótkie kroki do wykonania (komendy + ewentualne miejsca do ręcznej edycji).

## Zasady

- **Nie publikuj** nic na GitHubie (komentarze, review) bez wyraźnej prośby.
- **Nie rób** destrukcyjnych operacji (force push, merge do main, zamykanie PR) bez wyraźnej instrukcji.
- Najpierw **pobierz dane** (snapshot), potem wykonuj lub proponuj **operacje** (odniesienia, port).
- Ten skill **nie zastępuje code review** — nie ocenia jakości kodu; dostarcza dane i procedury do pracy na zmianach.