to-issues: plan pocięty na kawałki, które da się oddać
Masz zgrillowany plan z Lekcji 14. Teraz trzeba go pociąć na kawałki, które ktoś — człowiek albo agent bez żadnego dodatkowego kontekstu — może wziąć i zrobić samodzielnie. to-issues robi to konkretną techniką: tracer bullets, nie podział na warstwy.
Polecane źródło
Lokalny plik .agents/skills/to-issues/SKILL.md w tym repo.
Issue 1: pełna, wąska ścieżka "dodaj komentarz" — schema + API + UI + testy razem
Czy da się zademonstrować po jednym issue?
Nie — dopiero po wszystkich trzech naraz
Tak — jeden issue to jedna kompletna, działająca rzecz
Można oddać niezależnie?
Nie, mocno sprzężone
Tak — stąd "independently-grabbable"
Każdy tracer bullet przecina wszystkie warstwy integracji na raz (schema, API, UI, testy) — wąsko, ale kompletnie od początku do końca.
Proces krok po kroku
Zbierz kontekst — z rozmowy, albo z referencji do istniejącego issue, jeśli podasz numer/URL.
Eksploruj kod (opcjonalnie) — szukając okazji do prefaktoringu, zanim pocięcie na sliceʼy w ogóle się zacznie.
Zaproponuj podział na tracer bullety, z zależnościami między nimi.
Zapytaj Ciebie — czy granularność jest w sam raz, czy zależności się zgadzają, czy coś połączyć albo rozbić dalej. Iteruje, aż zatwierdzisz.
Publikuje do issue trackera, w kolejności zależności (blokery najpierw), z etykietą triage ready-for-agent z Lekcji 13.
Kluczowy wniosek: zanim w ogóle dojdzie do cięcia na slice'y, skill ma szukać okazji do prefaktoringu kodu — cytując wprost: "Make the change easy, then make the easy change." Refaktor, który upraszcza wprowadzenie zmiany, idzie jako osobny, wcześniejszy krok — nie miesza się z samą nową funkcjonalnością w jednym tracer bullecie.
Szablon issue: bez ścieżek plików, z jednym wyjątkiem
Opis "What to build" ma unikać konkretnych ścieżek plików i fragmentów kodu — bo szybko się dezaktualizują. Jeden wyjątek: jeśli poprzedzający prototype (kolejna lekcja) wyprodukował fragment kodu precyzyjniej kodujący decyzję niż prosa — maszynę stanów, reducer, kształt schematu — wtedy wklejasz go, przycięty do sedna decyzji, z notatką że pochodzi z prototypu.
## What to build
[koniec-do-końca zachowanie, nie warstwa po warstwie]
## Acceptance criteria
- [ ] Kryterium 1
- [ ] Kryterium 2
## Blocked by
[referencja do blokującego ticketu, albo "None"]
Zadanie praktyczne — potnij zgrillowany plan
W tym samym prawdziwym projekcie, na tym samym planie, który zgrillowałeś w Lekcji 14, wpisz /to-issues:
Sprawdź każdy proponowany issue: czy to naprawdę pionowy plaster (schema+API+UI+testy razem), czy przypadkiem podział na warstwy?
Odpowiedz na pytanie o granularność — nie akceptuj automatycznie, spróbuj naprawdę ocenić, czy coś jest za grube albo za drobne.
Po publikacji sprawdź w issue trackerze: czy issues mają etykietę ready-for-agent i poprawną kolejność Blocked by?
Sprawdź się
1. Który podział jest przykładem tracer bullet zgodnie z to-issues?
Tracer bullet to wąski, ale kompletny przekrój przez wszystkie warstwy integracji naraz — dokładnie odwrotność podziału warstwa-po-warstwie.
2. Co powinno się wydarzyć PRZED pocięciem planu na tracer bullety, jeśli kod na to pozwala?
"Make the change easy, then make the easy change" — skill szuka okazji do prefaktoringu przed samym cięciem na slice'y, żeby nowa funkcjonalność wchodziła na przygotowany grunt.
3. Dlaczego opis issue ma unikać konkretnych ścieżek plików i fragmentów kodu?
Konkretne ścieżki i fragmenty kodu tracą aktualność, gdy kod ewoluuje między napisaniem issue a jego realizacją — opis ma opisywać zachowanie end-to-end, nie implementację.
4. Kiedy WYJĄTKOWO dopuszczalne jest wklejenie fragmentu kodu do opisu issue?
Wyjątek dotyczy fragmentów z prototypu (maszyna stanów, reducer, kształt schematu), które precyzyjniej kodują podjętą decyzję niż opis słowny — i tylko przyciętych do sedna, nie całego działającego demo.
5. W jakiej kolejności to-issues publikuje zatwierdzone slice'y do issue trackera?
Publikacja w kolejności zależności pozwala odwołać się do realnych identyfikatorów już opublikowanych blokerów w polu "Blocked by" kolejnych issues.
Coś niejasne? Zapytaj mnie wprost — mogę pomóc ocenić, czy konkretny podział, który dostałeś, jest naprawdę pionowy, czy tylko tak wygląda.