agentic-codemod-pipeline/.apm/skills/repo-recon/SKILL.md

name, description, license, metadata

name	description	license	metadata
repo-recon	Rozpoznanie repozytorium przed zmianą - ustalenie systemu budowania, menedżera zależności, komendy testowej, miejsc użycia biblioteki i realnego promienia rażenia zmiany. Użyj zawsze jako pierwszy krok migracji, upgrade'u SDK lub większego refaktoru.	Apache-2.0	owner version pubi-platform 1.0.0

Rozpoznanie repozytorium

Celem jest fakt, nie domysł. Każde stwierdzenie w raporcie musi wynikać z odczytanego pliku lub wyniku wyszukiwania.

Procedura

1. System budowania i menedżer zależności - sprawdź w tej kolejności: pyproject.toml, requirements*.txt, setup.cfg, pom.xml, build.gradle*, package.json, go.mod. Zanotuj plik, który realnie deklaruje wersję biblioteki (może być więcej niż jeden - np. pyproject.toml + constraints.txt).
2. Aktualna wersja pakietu - odczytaj dosłownie zapis wersji (==, ~=, ^, zakres). Zapis ma znaczenie: ~=1.4 migruje się inaczej niż ==1.4.2.
3. Miejsca użycia - search_repo po nazwie modułu importu (uwaga: nazwa pakietu dystrybucyjnego bywa inna niż nazwa modułu, np. acme-sdk -> import acme). Zbierz: pliki, symbole (klasy, metody), liczbę wystąpień.
4. Komenda weryfikacji - znajdź jak repozytorium się testuje: sekcja [tool.pytest.ini_options], Makefile, tox.ini, .gitlab-ci.yml (tylko do odczytu!). Jeśli brak - zaraportuj brak, nie wymyślaj komendy.
5. Promień rażenia - oceń, czy użycia są skupione w warstwie adaptera (niskie ryzyko), czy rozlane po kodzie domenowym (wysokie ryzyko).

Wynik

Zwróć strukturę zgodną ze schematem RepoProfile. Pola, których nie udało się ustalić, oznaczaj jako null i wypisz w gaps - to sygnał dla planisty, że potrzebna jest decyzja człowieka.

Antywzorce

• Zgadywanie komendy testowej ("pewnie pytest") - jeśli nie ma dowodu, wpisz gaps.
• Pomijanie plików lock (poetry.lock, package-lock.json) - one też pinują wersję.
• Raportowanie użyć na podstawie samej nazwy pakietu bez sprawdzenia aliasów importu.