Każdy z nas buduje rozwiązania z AI po swojemu, metodą prób i błędów. Piszesz do Claude „zbuduj mi aplikację”, poprawiasz, dopisujesz, próbujesz jeszcze raz. Czasem to działa. Czasem dostajesz coś, co prawie działa. Prawie. I nie wiesz nawet, czego brakuje, bo nikt nie spisał, co miało powstać.
Można inaczej. Zamiast zgadywać, możesz podpatrzyć tych, którzy robią to najlepiej. Deweloperzy z Anthropic, firmy, która zbudowała Claude i Claude Code, pracują z AI według jednego, powtarzalnego systemu. W sierpniu 2026 roku opisali go w dokumencie „The AI-native SDLC playbook”. Stosują go z Claude Code u siebie i u klientów.
Oryginał jest napisany dla zespołów programistów i miejscami jest dość techniczny. Już sama nazwa to skrót: SDLC znaczy cykl życia oprogramowania, czyli cała droga projektu, od pomysłu, przez budowę, aż po pilnowanie, żeby gotowa rzecz dalej działała. Wziąłem z niego to, co najważniejsze: cały proces i etapy, przez które przechodzi każdy projekt. Przeprowadzę cię przez nie krok po kroku, a przy każdym kroku dostaniesz prompt do skopiowania.
Jedna zasada, na której stoi cały system
Sedno sprawy: każdy krok kończy się zapisanym plikiem, a następny krok zaczyna się od jego przeczytania.
Pomyśl o sztafecie. Każdy biegacz przebiega swój odcinek i przekazuje pałeczkę następnemu. Tutaj pałeczką jest dokument. Ty spisujesz pomysł i przekazujesz go dalej. Claude czyta pomysł i na jego podstawie pisze specyfikację. Specyfikacja staje się podstawą planu, plan podstawą budowy. Nic nie ginie po drodze, bo wszystko jest zapisane, a ty w każdej chwili możesz sprawdzić, skąd wzięła się dana decyzja.
Te pliki to zwykłe dokumenty tekstowe z końcówką .md. Czytasz je ty i czyta je Claude. W całym procesie powstaną trzy główne:
intent.mdOpis pomysłu: co chcesz osiągnąć i dlaczego.spec.mdSpecyfikacja: co dokładnie ma powstać i jak ma działać.plan.mdPlan budowy: w jakiej kolejności to zbudować i jak sprawdzić, że działa.
Do tego dochodzi plik CLAUDE.md z zasadami twojego projektu. Od niego zaczniemy.
Druga połowa zasady dotyczy ciebie. AI przygotowuje, a ty decydujesz. Na końcu każdego kroku to ty czytasz plik i mówisz „idziemy dalej” albo „poprawiamy”.
W większych projektach pracuje cały zespół i każdy odpowiada za swoją część: jedna osoba zgłasza pomysł, inna zatwierdza plan, jeszcze inna sprawdza kod i zgadza się na publikację. Ty możesz przejść przez cały ten proces sam, bez angażowania innych. Jeśli masz zespół, podzielcie się krokami. Proces zostaje ten sam, zmienia się tylko liczba osób przy stole.
Jeśli czytałeś mój artykuł „Jak budować projekt AI od A do Z”, rozpoznasz tę zasadę. Tam pokazałem ją na prawdziwym projekcie, przy samej budowie, a tutaj przechodzimy cały cykl, od pomysłu po utrzymanie.
Każdy projekt to osobny folder na twoim komputerze. Dzięki temu wszystko, co go dotyczy, leży w jednym miejscu. Cały projekt zbudujesz w aplikacji desktopowej Claude, w zakładce Code. Zakładając nową sesję, wybierasz pod polem wiadomości folder projektu, a Claude pracuje bezpośrednio na plikach w nim. Wszystkie pliki z tego artykułu powstaną właśnie tam. W pierwszym przełączniku pod polem wiadomości wybierz pracę na swoim komputerze. Jest też praca w chmurze, ale to zupełnie inny sposób pracy, więc tutaj ją pomijam.
Jak zbudowane są prompty
Zanim przejdziemy do kroków, krótkie przypomnienie, bo na nim opierają się wszystkie prompty poniżej. Z nowymi modelami AI rozmawia się inaczej niż jeszcze rok czy dwa lata temu. Kiedyś pisało się wielkimi literami „KONIECZNIE”, powtarzało polecenia i rozpisywało każdy ruch, bo model łatwo gubił instrukcje. Dzisiejsze modele trzymają się poleceń bardzo dokładnie, więc takie krzyczenie potrafi zaszkodzić: model zaczyna przesadzać. Lepiej działa coś prostszego. Jasno opisujesz, co ma powstać i po co, a resztę zostawiasz Claude.
Dlatego wszystkie prompty w tym artykule mają ten sam układ. Anthropic pisze o tym wprost w swoich wskazówkach do pisania promptów: kiedy wyjaśnisz Claude, po co coś robi, lepiej rozumie twój cel i daje trafniejszy wynik. Potrafi wtedy zastosować twoje wyjaśnienie także w sytuacjach, których nie wymieniłeś.
Każdy prompt ma pięć części:
REZULTAT: co ma powstać na końcu, najczęściej konkretny plik.
PO CO: do czego ten rezultat posłuży. To najważniejsza część.
KONTEKST / MATERIAŁY: na czym Claude ma pracować.
OGRANICZENIA: granice, których nie wolno przekroczyć, w tym momenty, w których Claude ma się zatrzymać i zapytać ciebie.
WARUNEK UKOŃCZENIA: po czym poznasz, że wynik jest gotowy.
Tekst w nawiasach kwadratowych podmieniasz na swój. Nad każdym promptem masz też informację, gdzie go wkleić. Prawie zawsze w nowej sesji. Ten układ przyda ci się też poza tym projektem, przy każdym większym zadaniu dla Claude.
Krok 0. Przygotowanie: powiedz Claude, o co w ogóle chodzi
Każdy krok robisz w osobnej sesji, czyli w nowej rozmowie w zakładce Code, w tym samym folderze projektu. Nawet jeśli wszystkie robisz jednego dnia. Dzięki temu Claude zaczyna każdy krok z czystą głową i opiera się na tym, co zapisane w plikach. Rzecz w tym, że nowa sesja nie pamięta poprzedniej. Dlatego potrzebny jest plik CLAUDE.md w głównym folderze projektu. Claude czyta go na początku każdej sesji. Coś jak krótka instrukcja, którą nowa osoba w zespole dostaje pierwszego dnia.
Zanim zaczniesz, załóż go. Na razie mały: kilka zdań o projekcie i zasady pracy. Szczegóły dojdą przy budowie. W playbooku CLAUDE.md pojawia się dopiero przy budowie. Ja zakładam go na samym początku, bo w małym projekcie zaczynasz od pustego folderu.
Przy okazji Claude przygotuje folder do zapisywania kolejnych wersji projektu. Przyda się od kroku 3. Jeśli na twoim komputerze brakuje do tego programu, Claude powie ci, co zainstalować.
REZULTAT
Plik CLAUDE.md w tym folderze: krótka instrukcja, którą przeczytasz
na początku każdej sesji w tym projekcie.
PO CO
Projekt będziemy prowadzić przez wiele sesji, a każda nowa sesja zaczyna
bez pamięci o poprzednich. Dzięki temu plikowi od pierwszej minuty wiesz,
co budujemy i jak pracujemy.
KONTEKST / MATERIAŁY
Mój projekt: [dwa, trzy zdania: co chcesz zbudować, dla kogo i po co]
OGRANICZENIA
- Najwyżej jedna strona. Szczegóły dojdą później.
- Poza tym plikiem nic nie rób. Jedyny wyjątek: jeśli w folderze nie ma
jeszcze zapisu wersji (git), załóż go.
WARUNEK UKOŃCZENIA
CLAUDE.md ma trzy sekcje:
- „O projekcie”: dwa, trzy zdania na podstawie mojego opisu,
- „Jak pracujemy”, z zasadami:
- projekt prowadzimy krok po kroku: opis pomysłu (intent.md),
specyfikacja (spec.md), plan (plan.md), budowa, testy,
kontrola i publikacja, utrzymanie,
- na początku każdej sesji sprawdzasz, które z tych plików istnieją,
i czytasz je, zanim cokolwiek zrobisz,
- nie piszesz kodu, dopóki plan.md nie jest zaakceptowany,
- decyzje podejmuję ja, a przy wątpliwościach pytasz,
- piszesz do mnie prostym językiem,
- „Błędy, których nie powtarzamy”: na razie pusta.Od tej chwili każda nowa sesja w tym folderze od początku wie, co budujesz i jak pracujecie. Jeśli ktoś w środku projektu napisze „dodaj jeszcze to”, Claude najpierw sprawdzi, na którym kroku jesteście, zamiast od razu budować.
Krok 1. Planowanie: daj Claude kierunek
Planowanie ma jeden cel: pokazać Claude, co ma zrobić. Zanim cokolwiek zbuduje, musi wiedzieć, jaki problem rozwiązujesz, dla kogo i po czym poznasz, że się udało. To jest kontekst projektu. Na nim oprą się wszystkie kolejne kroki: specyfikacja, plan i sam kod. Im lepiej zbudujesz go teraz, tym mniej Claude będzie musiał zgadywać później.
W praktyce wygląda to jak zwykła rozmowa z deweloperem, któremu tłumaczysz, co chcesz zbudować. Opowiadasz o pomyśle własnymi słowami, a Claude zadaje ci pytania. Jaki jest cel tego projektu? Kto będzie z niego korzystał? Co dokładnie ma powstać? Jak ma to wyglądać? Z twoich odpowiedzi buduje kontekst, a na koniec spisuje wszystko w jednym pliku. W playbooku Anthropic ten plik nazywa się intent.md, czyli opis zamiaru.
Skopiuj ten prompt i w nawiasie opisz swój pomysł.
REZULTAT
Plik intent.md: opis mojego pomysłu, pod którym mogę się podpisać
w całości.
PO CO
To pierwszy dokument projektu. Na jego podstawie powstanie specyfikacja,
plan i kod, więc wszystko, czego tu nie wyjaśnimy, ktoś później zgadnie.
KONTEKST / MATERIAŁY
Mój pomysł: [opisz go własnymi słowami]
OGRANICZENIA
- Rozmawiaj ze mną jak deweloper, który poznaje nowy projekt: zadawaj
pytania po jednym i czekaj na moją odpowiedź.
- Rozmawiamy o tym, co i po co. Jak to zbudować, ustalimy później.
- Zanim zapiszesz plik, pokaż mi krótkie podsumowanie i zapytaj,
czy czegoś nie brakuje. Zapisz go dopiero po moim potwierdzeniu.
WARUNEK UKOŃCZENIA
intent.md ma sekcje: Problem, Oczekiwany efekt, Kto będzie z tego
korzystał, Ograniczenia, Poza zakresem, Po czym poznamy, że się udało,
Otwarte pytania. Zaznaczyłeś w nim, co wywnioskowałeś sam, a czego
nie usłyszałeś ode mnie wprost.Po twoim potwierdzeniu Claude zapisze plik w folderze projektu. Przeczytaj go i popraw to, co Claude źle zrozumiał. Dopiero wtedy idziesz dalej.
Krok 2. Projektowanie: ustal, co dokładnie ma powstać
Masz już opis pomysłu. Wiesz, po co budujesz projekt i dla kogo. Teraz trzeba ustalić, co dokładnie ma powstać: jak ma działać, co zobaczy użytkownik i skąd wezmą się dane. To jest specyfikacja, zapisana w pliku spec.md.
Znowu wygląda to jak rozmowa z deweloperem. Claude czyta intent.md i proponuje, jak projekt ma działać. Ty mówisz, co ci pasuje, a co nie. Jeśli masz swoje zasady, na przykład kolory marki albo zasady dotyczące danych klientów, daj je Claude teraz. Lepiej, żeby znał je od razu, niż żeby dowiedział się o nich, kiedy wszystko będzie już zbudowane.
Plik intent.md leży już w folderze projektu, więc wystarczy skopiować prompt.
REZULTAT
Specyfikacja projektu zapisana jako spec.md: co dokładnie ma powstać
i jak ma działać.
PO CO
Na jej podstawie powstanie plan budowy, a potem kod. Wszystko, czego
tu nie ustalimy, będziesz później zgadywać.
KONTEKST / MATERIAŁY
- intent.md w folderze projektu: opis pomysłu,
- moje zasady: [wklej albo załącz swoje zasady].
OGRANICZENIA
- Pisz prostym językiem, tak żebym zrozumiał każdy punkt.
- Wybierz najprostszą technologię, która wystarczy.
- Konfliktów między moimi zasadami nie rozstrzygaj sam. Ja zdecyduję.
- Nie pisz jeszcze kodu.
WARUNEK UKOŃCZENIA
spec.md zawiera:
- jak projekt działa z punktu widzenia użytkownika, krok po kroku,
- z jakich części będzie się składał projekt,
- jakie dane są potrzebne i skąd się wezmą,
- z czego to zbudujemy i dlaczego, w dwóch, trzech zdaniach,
- sekcję „Jak sprawdzimy, że działa”: listę konkretnych sprawdzeń,
- odpowiedź na każde otwarte pytanie z intent.md albo informację,
że nadal jest otwarte,
- sekcję „Do decyzji” ze wszystkim, co budzi wątpliwości, szczególnie
z miejscami, w których moje zasady się wykluczają.Jeśli nie masz spisanych zasad, usuń z promptu linijkę o nich. Claude i tak zapyta o to, co będzie mu potrzebne.
Kiedy specyfikacja będzie gotowa, zacznij od sekcji „Do decyzji”. Claude zbiera tam wszystko, czego nie był pewien i o czym musisz zdecydować ty. Odpowiedz na te pytania, a Claude poprawi spec.md. Od teraz masz w folderze dwa pliki: po co budujesz i co dokładnie budujesz.
Krok 3. Budowa: najpierw plan, potem kod
Teraz Claude zaczyna budować. Zanim jednak napisze pierwszą linijkę kodu, musicie się umówić, jak to zrobi. Tak samo jak z deweloperem: zanim zacznie pracę, pokazuje ci plan, a ty mówisz, czy się zgadzasz. Playbook ma tu twardą zasadę: nic nie powstaje bez zaakceptowanego planu.
Do tego służy tryb planowania. Włączasz go w przełączniku trybu pod polem wiadomości, wybierając Plan. W tym trybie Claude czyta twoje pliki i obmyśla, jak zbudować projekt, ale niczego nie zmienia, dopóki nie zaakceptujesz planu.
Włącz tryb planowania i skopiuj prompt.
REZULTAT
Plan budowy podzielony na małe kroki, zaakceptowany przeze mnie
i zapisany jako plan.md.
PO CO
Według tego planu będziesz budować. Chcę rozumieć, co powstanie, zanim
powstanie, bo poprawić plan jest dużo łatwiej niż gotowy kod.
KONTEKST / MATERIAŁY
intent.md i spec.md w folderze projektu.
OGRANICZENIA
- Pisz prostym językiem, tak żebym zrozumiał każdy krok planu.
- Nie pisz jeszcze kodu.
- Po mojej akceptacji zrób tylko to, co opisuje warunek ukończenia,
i zatrzymaj się. Budowę zaczniesz, kiedy ci napiszę.
WARUNEK UKOŃCZENIA
- Przy każdym kroku planu jest: co powstanie albo się zmieni (jakie
pliki) i jak sprawdzimy, że ten krok działa. Plan jest na tyle
dokładny, że ktoś, kto nie widział naszej rozmowy, mógłby według
niego zbudować projekt sam.
- Pod planem są odpowiedzi na trzy pytania: co może się zepsuć, który
krok jest najbardziej ryzykowny, jakie inne rozwiązania rozważyłeś
i dlaczego je odrzuciłeś.
- Po mojej akceptacji:
1. plan.md jest zapisany razem z odpowiedziami na te pytania,
2. CLAUDE.md jest uzupełniony, bez usuwania tego, co już w nim jest,
o to, jak uruchomić projekt i jak sprawdzić, że działa, oraz
o sekcję „Zanim powiesz, że skończone”: uruchom wszystkie testy
i pokaż mi wynik, przejdź listę „Jak sprawdzimy, że działa”
ze spec.md, a gdy coś nie przechodzi, popraw kod, a nie test.Kiedy plan jest gotowy, Claude pokazuje go i pyta, co dalej. Przeczytaj go spokojnie i dopytuj o wszystko, czego nie rozumiesz. Jeśli chcesz coś zmienić, napisz to zwykłymi słowami. Kiedy plan ci odpowiada, wybierz opcję, która go zatwierdza. Claude zapisze wtedy plan.md i dopisze do CLAUDE.md, jak uruchomić projekt i jak go sprawdzać. O sprawdzaniu więcej w kroku 4.
Teraz możesz budować. Playbook mówi, że przy dobrym planie budowa często idzie za jednym podejściem. Ja robię inaczej: buduję po jednym kroku planu, każdy w nowej sesji. Im dłuższa rozmowa, tym łatwiej Claude gubi to, co ustaliliście na początku. Mały, jasno opisany kawałek robi dobrze.
Po każdym kroku Claude zapisze wersję projektu. Programiści nazywają to commitem. To jak zapis gry przed trudnym poziomem: jeśli coś pójdzie źle, napiszesz „Wróć do wersji sprzed ostatniego kroku”.
REZULTAT
Następny krok z plan.md zbudowany, sprawdzony i odhaczony.
PO CO
Budujemy po jednym kroku, każdy w osobnej sesji, żeby każdy był
zrobiony dobrze. Chcę w każdej chwili wiedzieć, na którym kroku
jesteśmy, i móc wrócić do każdej wcześniejszej wersji.
KONTEKST / MATERIAŁY
plan.md, spec.md i CLAUDE.md w folderze projektu.
OGRANICZENIA
- Weź pierwszy nieodhaczony krok z plan.md. Zanim zaczniesz, powiedz
mi w jednym zdaniu, co teraz zbudujesz.
- Zbuduj tylko ten jeden krok. Nic więcej.
- Jeśli musisz odejść od planu, najpierw powiedz mi dlaczego, a potem
zaktualizuj plan.md.
WARUNEK UKOŃCZENIA
- Do tego, co zbudowałeś, są testy, uruchomione, a wynik mi pokazany.
- Krok jest odhaczony w plan.md.
- Wersja jest zapisana (commit) z krótkim opisem.
- Zatrzymałeś się i czekasz na mnie.Kiedy Claude skończy krok, sprawdź wynik. Przy następnym kroku otwórz nową sesję i wklej ten sam prompt. Nowa sesja nie pamięta poprzedniej rozmowy, ale nie musi. Czyta plan.md i widzi, co jest już odhaczone, a co zostało. Prompt wklejasz tyle razy, ile kroków ma plan.
Jeszcze jedna rada z playbooka. Jeśli Claude dwa razy zrobi ten sam błąd, zapisz go w CLAUDE.md. Tu nie potrzebujesz całego układu, wystarczy jedno zdanie.
Dopisz do CLAUDE.md, w sekcji „Błędy, których nie powtarzamy”: [opisz błąd
i jak ma być poprawnie].Claude czyta CLAUDE.md na początku każdej sesji, więc ten błąd będzie się zdarzał dużo rzadziej. Jeśli mimo to wraca, opisz zasadę konkretniej. Im jaśniej ją napiszesz, tym pewniej Claude się jej trzyma.
Krok 4. Testy: niech Claude sprawdza się sam
Zwykle o błędzie dowiadujesz się za późno, kiedy dzwoni klient i mówi, że coś nie działa. Tutaj Claude sprawdza swoją pracę sam, zanim ci ją pokaże.
Robi to za pomocą testów. Test to mały program, który sprawdza, czy aplikacja robi to, co powinna. Na przykład czy po kliknięciu przycisku dzieje się to, co miało się stać. Nie musisz umieć go napisać. Claude zrobi to sam, a ty pilnujesz tylko, żeby go uruchamiał i pokazywał ci wynik.
Zasady sprawdzania masz już w CLAUDE.md, bo Claude dopisał je w kroku 3. Zanim powie, że coś jest skończone, ma uruchomić testy, pokazać ci wynik i przejść listę „Jak sprawdzimy, że działa” ze specyfikacji.
Jest w tym jeden haczyk. AI, które ma naprawić błąd, potrafi czasem zmienić sam test, tak żeby przestał wykrywać błąd. Wtedy test mówi, że wszystko gra, a błąd zostaje. Dlatego kiedy coś nie działa, kolejność jest zawsze ta sama: najpierw test, który pokazuje błąd, dopiero potem poprawka.
Z promptu poniżej korzystasz za każdym razem, kiedy coś nie działa: przy budowie, po kontroli w kroku 5 albo już po publikacji.
REZULTAT
Naprawiony błąd opisany niżej.
PO CO
Chcę mieć dowód, że błąd naprawdę zniknął i nie wróci przy kolejnych
zmianach.
KONTEKST / MATERIAŁY
Błąd: [opisz, co się dzieje i co powinno się dziać]
OGRANICZENIA
- Najpierw napisz test, który ten błąd pokazuje, uruchom go, pokaż mi,
że nie przechodzi, i zapisz go (commit). Dopiero potem poprawiaj kod.
- Samego testu nie zmieniaj.
- Jeśli nie umiesz odtworzyć błędu testem, powiedz mi to, zamiast
zgadywać.
WARUNEK UKOŃCZENIA
Nowy test przechodzi, wszystkie pozostałe testy też, a wersja jest
zapisana (commit).Jeśli po poprawce test przechodzi, a Claude go nie ruszał, masz dowód, że błąd zniknął. Możesz to sprawdzić sam: zapytaj Claude, czy plik testu zmienił się od chwili, gdy go zapisał.
Testy pisze i uruchamia ten sam Claude, który buduje. Tak ma być, bo sam najszybciej łapie swoje błędy. Ostatnie słowo należy jednak do kogoś, kto nie budował. O tym jest krok 5.
Krok 5. Kontrola i publikacja: sprawdza ktoś, kto nie budował
Ten, kto napisał kod, nigdy go nie zatwierdza.
Pomyśl o tym jak o pracy z deweloperem. Nikt rozsądny nie publikuje kodu, który sprawdził tylko jego autor. Autor patrzy na swoją pracę przez to, co chciał zrobić, i łatwo przeoczy, co zrobił naprawdę. Pracując z jednym Claude, łamiesz tę zasadę bez zastanowienia: ta sama sesja buduje i sama ocenia, że jest dobrze.
Rozwiązanie jest proste: otwórz nową sesję w tym samym folderze. Nowa sesja nie zna rozmowy, w której powstawał kod, więc nie ma założeń sesji, która budowała. Ma przed sobą spec.md, plan.md i sam projekt, więc porównuje to, co powstało, z tym, co miało powstać.
Taka kontrola najpierw uruchamia projekt i sprawdza, czy działa. Potem czyta kod i szuka błędów. Na koniec pisze ci raport.
REZULTAT
Raport z kontroli projektu zapisany jako kontrola.md.
PO CO
Nie budowałeś tego projektu i widzisz go pierwszy raz. Właśnie dlatego
sprawdzasz go ty: sesja, która budowała, patrzy na niego przez własne
założenia. Na podstawie raportu zdecyduję, co poprawić przed publikacją.
KONTEKST / MATERIAŁY
spec.md, plan.md i cały projekt w tym folderze.
OGRANICZENIA
- Niczego nie poprawiaj, tylko raportuj.
- Pisz prostym językiem.
WARUNEK UKOŃCZENIA
- Uruchomiłeś wszystkie testy i samą aplikację i przeszedłeś listę
„Jak sprawdzimy, że działa” ze spec.md, także w nietypowych
sytuacjach.
- Przeczytałeś kod pod kątem błędów (coś działa inaczej, niż opisuje
specyfikacja), bezpieczeństwa (czy nie mogą wyciec poufne
dane) i zgodności (zbudowano to, co było w planie, i nic
ponad to).
- W kontrola.md uwagi są ułożone od najpoważniejszych, a poważne
problemy oddzielone od drobiazgów.Przeczytaj raport i zdecyduj, co poprawiacie. Poważne problemy poprawiasz w kolejnej nowej sesji, tak jak kolejny krok budowy. Wystarczy napisać: „Przeczytaj kontrola.md i popraw poważne problemy”. Drobiazgi możesz odłożyć. Decyzja zawsze należy do ciebie.
Zostaje publikacja, czyli udostępnienie projektu użytkownikom. Zanim to zrobisz, przygotuj sobie drogę powrotu. Jeśli nowa wersja zacznie sprawiać problemy, musisz umieć szybko wrócić do poprzedniej. Playbook mówi, że powrót ma być najlepiej przećwiczoną rzeczą przy publikacji. Dlatego Claude spisze ci instrukcję, a potem raz ją razem przećwiczycie.
REZULTAT
Projekt gotowy do publikacji i instrukcja powrotu do poprzedniej wersji.
PO CO
Chcę opublikować projekt bezpiecznie. Jeśli nowa wersja zacznie sprawiać
problemy, muszę umieć szybko wrócić do poprzedniej.
KONTEKST / MATERIAŁY
Projekt w tym folderze, po kontroli i poprawkach z kontrola.md.
OGRANICZENIA
- Nie publikuj niczego sam. Przycisk naciskam ja.
WARUNEK UKOŃCZENIA
- Aktualna wersja jest zapisana (commit).
- Wiem krok po kroku, co muszę zrobić, żeby opublikować projekt.
- Instrukcja powrotu do poprzedniej wersji jest dopisana do CLAUDE.md,
żeby była pod ręką.
- Powrót do poprzedniej wersji przećwiczyliśmy raz u mnie na komputerze.Jedno zdanie z ograniczeń mówi tu wszystko: „Przycisk naciskam ja”. Tak jak w całym systemie: Claude przygotowuje, a decydujesz ty.
Krok 6. Utrzymanie: pałeczka wraca na start
Projekt działa, użytkownicy z niego korzystają. Prędzej czy później ktoś zgłosi, że coś nie działa. Albo poprosi o nową funkcję. Z takim zgłoszeniem nie czekaj, aż znajdziesz czas. Wklej je od razu do promptu poniżej.
Kiedy coś się psuje, Claude zachowuje się jak dobry deweloper: zanim cokolwiek ruszy, chce zrozumieć, co się stało. Najpierw tylko bada sprawę i niczego nie zmienia, dopóki się nie zgodzisz.
REZULTAT
Diagnoza problemu opisanego niżej i propozycja, co dalej.
PO CO
Zanim cokolwiek zmienimy, chcę wiedzieć, co się stało i czy to mała
poprawka, czy większa zmiana.
KONTEKST / MATERIAŁY
Problem: [opisz problem]
OGRANICZENIA
- Niczego nie zmieniaj w kodzie, dopóki się nie zgodzę.
- Nie nadpisuj istniejącego intent.md.
WARUNEK UKOŃCZENIA
- Wiem, co najprawdopodobniej jest przyczyną, na czym opierasz
diagnozę i jak bardzo jesteś jej pewny.
- Jeśli to mała poprawka: jest opisana i czeka na moją zgodę.
- Jeśli to większa zmiana: jest zapisana jako nowy plik
intent-[krótka nazwa zmiany].md, w tym samym formacie co intent.md.Co dalej, zależy od tego, co Claude znajdzie. Mała poprawka przechodzi przez kroki 4 i 5: test, poprawka, kontrola, publikacja. Większa zmiana, na przykład nowa funkcja, to tak naprawdę nowy pomysł. Claude zapisał ją już jako intent-[krótka nazwa zmiany].md, obok pierwszego opisu. Przeczytaj ten plik i popraw to, co Claude źle zrozumiał, tak jak w kroku 1. Potem idziesz z nim dalej, od kroku 2. W promptach podajesz nazwę nowego pliku zamiast intent.md, a Claude dopisze zmianę do spec.md i plan.md.
I tu sztafeta zamienia się w pętlę. Pałeczka wraca do pierwszego biegacza, a cykl zaczyna się od nowa. Tym razem z plikami, w których jest już zapisane wszystko, co ustaliłeś.
Od czego zacząć?
Zacznij od czegoś małego. Wybierz projekt, który da się zbudować w tydzień. Na pierwszy raz najlepiej coś wewnętrznego, bez danych klientów, na przykład listę zadań dla zespołu albo kalkulator wyceny. Tam najszybciej zobaczysz, jak pliki przechodzą z kroku do kroku i w którym miejscu sam masz ochotę coś przeskoczyć.
Pobaw się promptami. Jeśli nie wiesz, po co jest któreś zdanie, wklej prompt do Claude i zapytaj: co zrobisz, jeśli dostaniesz ode mnie taki prompt, i po co jest w nim to zdanie? Claude wytłumaczy ci to prostymi słowami.
Przerób prompty pod siebie. To schemat do przerobienia. Sam zdecyduj, co z nich weźmiesz, co dopiszesz, a co wyrzucisz, żeby pasowały do twojego celu. Zostaw tylko zawsze część PO CO, bo z niej Claude rozumie, do czego zmierzasz.
Nie przeskakuj kroków. To jest w tym systemie najtrudniejsze. Pokusa, żeby od razu napisać „zbuduj mi aplikację”, jest ogromna. Kilka minut na opis pomysłu i plan oszczędza godziny poprawiania rzeczy, które od początku szły w złą stronę.
Jeśli masz projekt rozpoczęty według artykułu „Jak budować projekt AI od A do Z”, dokończ go tamtą metodą, a następny zacznij według tego. Pliki nazywają się tu trochę inaczej: PRD z tamtego artykułu dzieli się na intent.md i spec.md, a plan wdrożenia i dokument procesu łączą się w jeden plan.md.
Powodzenia!