Lekcja 16 · Faza 2 · między planowaniem a implementacją
prototype: kod do wyrzucenia, który odpowiada na pytanie
W Lekcji 15 to-issues wspomniał wyjątek: fragment kodu z prototypu można wkleić do opisu issue, bo precyzyjniej koduje decyzję niż prosa. Ten skill to właśnie źródło takich fragmentów. Definicja z samego skilla: "throwaway code that answers a question. The question decides the shape."
Polecane źródło
Lokalne pliki .agents/skills/prototype/{SKILL,LOGIC,UI}.md w tym repo.
Dwie gałęzie, jedna decyzja
Pytanie
Gałąź
Artefakt
"Czy ta logika / model stanu ma sens?"
LOGIC.md
mały, interaktywny terminal (TUI), przez który ręcznie przepychasz stan przez trudne przypadki
"Jak to powinno wyglądać?"
UI.md
kilka radykalnie różnych wariantów na jednej stronie, przełączanych paskiem na dole ekranu
Pomylenie gałęzi marnuje cały prototyp — dlatego skill każe najpierw jednoznacznie ustalić, które pytanie właściwie zadajesz, zanim napisze choćby linijkę.
Sześć zasad wspólnych dla obu gałęzi
Od pierwszej linijki oznaczone jako do wyrzucenia — leży blisko docelowego miejsca w kodzie, ale nazwane tak, żeby nikt nie pomylił go z produkcją
Jedna komenda, żeby uruchomić — cokolwiek już obsługuje task runner projektu
Brak trwałości domyślnie — stan żyje w pamięci; trwałość to rzecz, którą prototyp sprawdza, nie na której polega
Bez polerowania — żadnych testów, żadnej obsługi błędów poza tym, co potrzebne do uruchomienia
Stan zawsze widoczny — po każdej akcji albo zmianie wariantu
Usuń albo wchłoń po zakończeniu — nic nie ma gnić w repo
Kluczowy wniosek: w gałęzi LOGIC prawdziwa logika (reducer, maszyna stanów, czyste funkcje) ma być odizolowana za małym, czystym interfejsem, oddzielnym od samego TUI. TUI jest do wyrzucenia; logika — jeśli odpowiedź wypadła pozytywnie — trafia wprost do prawdziwego kodu. To dokładnie ta sama zasada "seam" i czystego interfejsu, którą spotkasz w kolejnej lekcji o codebase-design.
UI: wariant A prawie zawsze wygrywa
Skill silnie preferuje podszywanie się pod istniejącą stronę (realny header, sidebar, dane) zamiast nowej, pustej trasy — bo w próżni każdy wariant wygląda dobrze. Domyślnie 3 warianty (więcej niż 5 przestaje być "radykalnie różne", zaczyna być szumem), przełączane parametrem ?variant= i strzałkami. Warianty muszą różnić się strukturalnie — inny układ, inna hierarchia informacji — nie tylko kolorem.
Jedyna rzecz warta zachowania
Gdy prototyp odpowiedział na pytanie: odpowiedź jest jedyną rzeczą wartą zachowania — zapisaną w commit message, ADR, issue albo NOTES.md obok prototypu. Sam kod prototypu (poza ewentualnie wyizolowanym modułem logiki) idzie do usunięcia.
Zadanie praktyczne — odpowiedz na jedno pytanie projektowe
W swoim prawdziwym projekcie znajdź jedno nierozstrzygnięte pytanie z ostatniego grillowania albo planowania (np. "czy ten model stanu obsłuży anulowanie częściowe?" albo "jak ma wyglądać ten nowy ekran?") i wpisz /prototype:
Sprawdź, którą gałąź wybrał Claude i czy zgadzasz się z tym wyborem.
Dla LOGIC: czy faktycznie dostałeś czysty moduł logiki oddzielony od TUI, czy są ze sobą pomieszane?
Po odpowiedzi na pytanie: zapisz ją gdzieś trwale (issue, ADR, NOTES.md) i usuń albo wchłoń resztę prototypu — nie zostawiaj go w repo.
Sprawdź się
1. Pytanie brzmi "czy ten stan obsłuży częściowe anulowanie zamówienia?". Którą gałąź wybierze prototype?
To pytanie o logikę/model stanu — dokładnie przykład z LOGIC.md ("does this data model actually let me represent the case where..."). UI.md jest dla pytań o wygląd.
2. Dlaczego prototyp UI domyślnie osadza warianty na istniejącej stronie (sub-shape A), zamiast tworzyć nową, pustą trasę?
Pusta trasa to próżnia, w której każdy wariant wygląda w porządku — dopiero zderzenie z realnym headerem, danymi i gęstością istniejącej strony ujawnia prawdziwe różnice.
3. Zgodnie z anti-patterns z LOGIC.md, co jest sygnałem, że coś przestało być prototypem?
Skill wprost: "A prototype that needs tests is no longer a prototype" — potrzeba testów to sygnał, że kod przestał być jednorazowym, wyrzucalnym eksperymentem.
4. Prototyp logiki odpowiedział na pytanie pozytywnie. Co dokładnie warto przenieść do prawdziwego kodu?
TUI to jednorazowa powłoka do ręcznego sterowania. Czysty moduł logiki za nią — jeśli się sprawdził — jest tym, co faktycznie warto przenieść do produkcyjnego kodu.
5. Po zakończeniu pracy z prototypem, co jest jedyną rzeczą wartą trwałego zachowania?
Skill jest tu jednoznaczny: odpowiedź na pytanie jest jedyną trwałą wartością prototypu. Kod (poza ewentualnym modułem logiki) ma zostać usunięty, żeby nie gnił w repo.
Coś niejasne? Zapytaj mnie wprost — mogę pomóc rozstrzygnąć, które pytanie z Twojego projektu kwalifikuje się do LOGIC, a które do UI.