O czym jest ten film
- Jak przygotować się do pracy z Claude Code, zanim w ogóle wpiszemy pierwszy prompt (zrzut myśli, szkic, tryb planowania).
- Skąd czerpać inspirację i jak przekazać ją modelowi w postaci zrzutów ekranu i skopiowanych stylów.
- Dlaczego precyzja polecenia decyduje o jakości efektu i oszczędności tokenów.
- Jak dać Claude’owi „oczy” — Chrome DevTools MCP i samodzielne robienie zrzutów ekranu do iteracji.
- Biblioteki gotowych komponentów (21st.dev) i zasada wybierania dwóch–trzech sekcji na stronę.
- Tworzenie pliku style guide jako jedynego źródła prawdy o wyglądzie strony.
- Eksperymentowanie z wariacjami w Claude Design zamiast bałaganu w plikach projektu.
- Hosting przez GitHub i Hostinger — publikacja i aktualizacja strony z poziomu Claude Code.
- Utrwalanie wiedzy w CLAUDE.md i skillach, aby agent uczył się na błędach.
- Integracje (mailing, analityka, formularze, szybkie demo) oraz zaawansowane techniki: pętla
/loopi subagent do testowania odporności strony.
Redakcyjne tłumaczenie
Cześć, moi drodzy. Dzisiaj w tym krótkim — mam nadzieję, że konkretnym — filmie chciałem podzielić się z wami ponad dziewiętnastoma trikami, sztuczkami i sposobami na to, jak najlepiej budować strony z Claude Code. Sam przez ostatnie miesiące zbudowałem takich stron dziesiątki, a jeszcze trzy lata temu zawodowo budowałem i projektowałem strony internetowe, więc co nieco potrafię. Bez przedłużania — zapraszam.
Nie zaczynaj z pustymi rękoma
Pierwsza bardzo ważna rzecz: nie zaczynaj pracy nad nową stroną z czystą kartką i pustymi rękoma. Nie wchodź do Claude Code bez niczego — otwórz jakikolwiek plik tekstowy (ja robię to akurat w Obsidianie) i wypisz sobie założenia. Taki zrzut myśli: własnymi słowami spisz to, co ma się znaleźć na stronie, do kogo jest skierowana, jakie sekcje chcesz na niej mieć — jeśli potrafisz je nazwać. Po prostu to, co siedzi ci w głowie.
Zauważyłem, że kiedy sam wypiszę wszystko łopatologicznie, w punktach — wszystkie moje przemyślenia — to później nie gubią się one w prompcie i nie są spłaszczane przez AI. Strona po prostu wychodzi dużo bardziej taka, jak chcę.
(Informacja dodatkowa: Obsidian to popularny program do notatek oparty na plikach Markdown.)
Naszkicuj to na kartce
Drugi, pomniejszy trik: można otworzyć zeszyt albo kartkę papieru i fizycznie naszkicować to, co chcemy otrzymać — choćby pierwszą sekcję, tak jak ją sobie wyobrażamy. Taki szkic można załączyć w pliku tekstowym i dopiero z nim wejść do Claude Code. Model potrafi patrzeć na zdjęcia i wyciągać z nich wnioski, więc jeśli powiemy mu, żeby wzorował się dokładnie na tym, co mu przedstawiamy, stworzy stronę albo sekcję zgodnie z rysunkiem.
Brainstorming, plugin Context7 i tryb planowania
Trzecie usprawnienie dotyczy momentu, gdy jesteśmy już w Claude Code, ale wciąż chcielibyśmy coś dopracować. Często używam wtedy czegoś, co nazywa się Superpowers — a dokładniej trybu brainstormingu. Jeśli wpiszę manage plugins, dostaję listę wtyczek, które mogę zainstalować. Przydatny jest właśnie oficjalny plugin Superpowers.
Przy okazji: równie przydatny jest Context7 — plugin, który umożliwia pobieranie na bieżąco dokładnej dokumentacji tego, jak działają poszczególne narzędzia i biblioteki. Jeśli tego nie rozumiecie, nie przejmujcie się — Claude’owi na pewno się przyda.
(Informacja dodatkowa: Context7 to serwer MCP dostarczający modelowi aktualną dokumentację bibliotek. Superpowers to zestaw rozszerzeń dla Claude Code.)
Wracając do brainstormingu: gdy dopiszemy słowo brainstorming na końcu naszej wiadomości i to odpalimy, Claude przemyśli z nami całość krok po kroku, będzie zadawał pytania uzupełniające i po prostu będzie dużo bardziej „myślący”. Oczywiście nie wysyłamy samego słowa „brainstorming” — najpierw opisujemy, co chcemy osiągnąć albo przedyskutować, a dopiero na końcu wiadomości dopisujemy „brainstorming”.
I jeszcze w ramach tego punktu: na początku każdego projektu z Claude Code warto włączyć tryb planowania. Model napisze sobie wtedy checklistę rzeczy do odhaczenia, zamiast od razu zakasywać rękawy i działać. Jeśli działa od razu, popełnia dużo więcej błędów. A jeśli najpierw napisze plan, to my wiemy, co będzie robił, on sam też to wie — dzięki czemu nie marnuje tylu tokenów i mniej nas frustruje.
Czerp z bibliotek inspiracji
Czwarte usprawnienie znów nawiązuje do tego, żeby nie zaczynać z pustymi rękoma i od razu coś Claude’owi pokazać. Bardzo ułatwiają to strony zrzeszające inspiracje — jakościowe projekty stron internetowych. Kiedy robimy pierwsze strony, trudno jest opisać dokładnie to, czego chcemy, więc lepiej załączyć obrazek i do niego się odnieść.
Strony, które mogę polecić: sitepire.com oraz landbook.com. Mógłbym też polecać bardziej wydziwiaste serwisy, jak awwwards.com, który zrzesza nagradzane strony — ale one są zwyczajnie niefunkcjonalne. Są ładne, jednak nie ma sensu ich odtwarzać; zależy nam głównie na stronach funkcjonalnych. Takie znajdziemy na przykład w szablonach Webflow (webflow.com/templates), gdzie mamy przejrzyście podzielone kategorie — na przykład Technology. Wchodzimy w „view details” i „preview in browser”, dzięki czemu podejrzymy stronę bezpośrednio w przeglądarce.
Przekaż stronę jako zrzut ekranu i skopiowane style
Kiedy mamy już wybraną stronę, która nam się podoba, moglibyśmy zrobić zwykły zrzut ekranu, wrócić do Claude’a i powiedzieć: „O, to mi się podoba, tu masz screenshot”. Ale to nie jest optymalne. Skoro spotykamy się, żeby dzielić się trikami — polecam zrobienie zrzutu całej strony za pomocą wtyczki GoFullPage. Ona „pożre” całą stronę, zrobi zrzut całościowy i można go po prostu skopiować („copy image”). Ważne, żeby poczekać, aż się skopiuje.
(Informacja dodatkowa: GoFullPage to rozszerzenie do przeglądarki robiące zrzut całej długości strony, nie tylko widocznego fragmentu.)
To jednak jeszcze nie wszystko, bo można też pobawić się w inspektora. Wracamy na stronę, klikamy prawym przyciskiem myszy → „Zbadaj”, zaznaczamy element body, ponownie prawy przycisk → „Copy” → „Copy styles”. Skopiujemy w ten sposób style tej strony. Wklejamy je Claude’owi i mamy wszystko pięknie opisane — jak strona wygląda.
Wtedy mówimy: „To jest strona, którą chciałbym, żebyś odtworzył. Nie powielaj tekstu, ale chciałbym, żeby była jota w jotę jak na załączonym obrazku. Załączam też style”.
Precyzja polecenia to podstawa
I teraz pytanie do was: co jest nie tak z takim moim poleceniem? Wysłałem cały styl i załączyłem przykładowe zdjęcie — a mimo to coś jest nie tak.
Otóż chciałbym was uczulić: pracując ze stronami i współpracując z Claude Code, wyrażajcie się bardzo precyzyjnie co do tego, co chcecie otrzymać. Nazywajcie rzeczy po imieniu. Nie mówcie „ładna strona”, „nowoczesna strona”. W moim przykładzie nie opisałem, jakie chcę mieć sekcje, ile ich ma być, jak to ma wyglądać ani po co to wszystko jest. Bardzo krótkie, bardzo proste polecenie. Tak nie należy robić — to marnowanie tokenów i czasu, bo model będzie błądził, krążył, a my będziemy musieli raz po raz go nakierowywać. Lepiej na początku poświęcić tę minutę czy dwie dłużej, żeby precyzyjnie się wysłowić i dokładnie określić, czego oczekujemy.
Daj Claude’owi oczy — Chrome DevTools MCP i zrzuty ekranu
Mamy pierwszą wersję strony i całe szczęście, że model nie dał sobie rady — dzięki temu mogę pokazać kolejne przydatne zastosowanie: Chrome DevTools MCP (link będzie w opisie). Kiedy zainstalujemy to w Claude Code, model będzie mógł otworzyć własną instancję przeglądarki Chrome, poruszać się po niej i sprawdzić, czy kod, który pisze, faktycznie wygląda tak, jak myśli. Na ten moment pisze kod na ślepo — nie widzi, że głównego przycisku nie da się kliknąć, bo zasłania go jakieś okienko.
(Informacja dodatkowa: Chrome DevTools MCP to serwer MCP dający modelowi bezpośredni dostęp do przeglądarki i jej narzędzi deweloperskich.)
Wystarczy skopiować link i powiedzieć: „Połącz się z tym”. Model otworzy Chrome i zobaczy, czy strona na pewno tak wygląda. Żeby to sprawdził skutecznie, warto go poinformować, że może samodzielnie robić zrzuty ekranu i je oglądać. To jest trik numer 7 (Chrome DevTools MCP) i numer 8 (nakazanie mu robienia zrzutów ekranu i „karmienia się” nimi).
Powiedziałem mu więc: „Otwórz to w przeglądarce Chrome i rób zrzuty ekranu, dopóki nie uznasz, że wygląda to jak załączony przykład — bo na razie nie wygląda aż tak dobrze. Sprawdzaj na Chromie, dopóki nie będziesz wystarczająco dumny, żeby powiedzieć, że jest gotowe”. Wysyłamy — i widać, że odpalił Chrome, ogląda, co się dzieje, i robi zrzuty ekranu, iterując na bieżąco.
Gotowe komponenty z 21st.dev
Przejdźmy do triku numer 9 — strony 21st.dev. To także biblioteka inspiracji, ale inna niż poprzednie, bo znajdziemy tu gotowe komponenty: pojedyncze przyciski, sposoby na wyszukiwarki, sekcje, bloczki, cenniki. Świetne, jeśli chcemy rozszerzyć stronę o fajne funkcjonalności.
Klikam na przykład „latest components”, przechodzę do kategorii — powiedzmy „images”. Jeśli podoba nam się jakiś wizualny sposób prezentacji zdjęć, klikamy w niego (być może trzeba założyć konto), kopiujemy kod i demo, wracamy do Claude Code i mówimy: „To mi się podoba, chcę to”. To naprawdę ogromna biblioteka ciekawych sekcji — możemy je przeglądać i zapisywać na później, budując własną kolekcję.
Ważna uwaga: gdy pierwszy raz to odpalicie, nie dajcie się przytłoczyć — tego jest mnóstwo. Radziłbym wybierać dwie–trzy ciekawe sekcje na stronę, żeby skupić się na faktycznym jej zbudowaniu, a nie na tym, by miała najbardziej bajeranckie efekty ze wszystkich. Nadmiar efektów gorzej wpływa na funkcjonowanie strony i sprawia, że jest mniej czytelna dla użytkowników.
Style guide jako jedyne źródło prawdy
Mamy przyzwoitą pierwszą wersję strony. Gdybym szedł z nią na produkcję, jeszcze bym trochę dyskutował z modelem i poprawiał to, co mi się nie podoba. Ale jeśli chcemy poeksperymentować i zobaczyć inne wariacje, świetnym sposobem jest wyeksportowanie tego do Claude Design.
Zanim to zrobimy — porada numer 10: stwórzcie plik style guide, w którym umieścicie wszystkie zasady projektowe. Dzięki temu, tworząc nowe strony, sekcje czy dokumenty, wszystko będzie w tym samym, określonym stylu, a Claude nie będzie sobie niczego zmyślał ani nie będziemy musieli za każdym razem podawać mu wytycznych.
Mówimy więc: „Stwórz plik style-guide.html, w którym ujmiesz wszystkie najważniejsze zasady projektowe”. Warto dodać, że będzie to jedyne źródło prawdy o wyglądzie strony. Powstaje zwykła strona internetowa, którą możemy podejrzeć — z kolorami, czcionkami, odstępami, promieniami zaokrągleń i cieniami. Wszystko, co przyda się i nam, i AI w przyszłych iteracjach.
Wariacje w Claude Design
Skoro działamy w Claude Code, mamy ten plik w naszym folderze — przechodzimy do Claude Design i po prostu go załączamy. Trik numer 11 polega na tym, że nie musimy tworzyć nowych wariacji wewnątrz Claude Code, bo tam wszystko się miesza i robi się bałagan w plikach. Możemy zrobić bałagan w Claude Design, a gdy coś nam się spodoba, przenieść to z powrotem do Claude Code. Sposobów na przeniesienie jest mnóstwo — możemy pobrać plik, połączyć się, zsynchronizować. Nie ma jedynego słusznego sposobu.
Mając załączony plik, możemy powiedzieć na przykład: „Chcę, żebyś wygenerował mi pięć zupełnie różnych, zupełnie nowych wariacji efektownej sekcji hero na górze strony. Zależy mi, żeby styl był zgodny ze style-guide.html i żeby wszystkie pięć wersji było zupełnie różnych”.
(Informacja dodatkowa: sekcja „hero” to główny, najbardziej widoczny obszar na górze strony — zwykle z nagłówkiem i wezwaniem do działania.)
Hosting przez GitHub i Hostinger
Rzecz numer 12: pracując nad stronami, zawsze warto założyć konto na GitHubie i się z nim połączyć — stworzyć osobne repozytorium (osobny projekt/folder) z naszymi najważniejszymi plikami. Dzięki temu możemy hostować stronę bezpośrednio albo łatwo załączyć ją jako kontekst, między innymi w Claude Design. Po połączeniu z GitHubem możemy w jednym miejscu wgrać cały projekt, bez ręcznego załączania plików.
W Claude Code mówimy: „Stwórz nowe repozytorium na GitHubie o nazwie na przykład »strona demonstracyjna« i umieść w nim wszystko, żebym mógł hostować swoją stronę na hostingu w Hostingerze”. Dzięki połączeniu z GitHubem możemy z poziomu Claude Code zarządzać całą stroną, która później idzie na żywo. Warto stworzyć zasadę, żeby przy każdej nowej wersji strony model pytał, czy wysyłamy ją na GitHub — bo wysłanie na GitHub oznacza, że strona będzie na żywo pod naszą domeną. Tak zarządzam wszystkimi swoimi stronami: tworzę je w Claude Code, iteruję, a gdy coś mi się spodoba, mówię „wysyłamy na GitHub”.
Kiedy repozytorium jest gotowe, możemy podejrzeć, czy na pewno zawiera stronę demonstracyjną i wszystkie pliki. Teraz sprawiamy, żeby te dane zaciągały się pod naszą domenę — możemy zrobić to z naszym hostingiem, na przykład w Hostingerze (który jest sponsorem tej części wideo; mam z nim partnerstwo długoterminowe). Możecie użyć dowolnego hostingu, ale z Hostingerem jest to po prostu łatwe.
(Informacja dodatkowa: poniższy fragment to instrukcja konfiguracji i materiał sponsorowany.)
Pokrótce: wybieramy plan (pakiet bez limitu pozwala tworzyć nieograniczoną liczbę stron; jest 30-dniowy okres zwrotu bez pytań). Pod polem kodu rabatowego warto wpisać MIKOLAJ10, żeby zaoszczędzić dodatkowe 10%. W panelu przechodzimy do „Strony internetowe”, wybieramy domenę, wchodzimy w panel sterowania → „Zaawansowane” → „Git” → „Połącz się z GitHub”. Wybieramy dostęp tylko do wybranych repozytoriów, wskazujemy nasze repozytorium („strona demonstracyjna”), instalujemy i autoryzujemy. Gałąź zwykle main — bez kombinowania. Ewentualnie moglibyśmy zmienić podstronę, pod którą strona się znajdzie. Wdrażamy — i strona jest pod naszą domeną.
Gdybyśmy chcieli coś zmienić, znów w Claude Code mówimy, co poprawić, i „wyślij to na GitHub” — po minucie–pięciu zmiana pojawi się na stronie. Połączenie z GitHubem przyda się każdemu, nawet bez hostingu w Hostingerze — jest przydatne nie tylko do hostowania, ale też do dzielenia się projektami i łączenia się z nimi z innego komputera.
Utrwalaj wiedzę w CLAUDE.md i skillach
Porada numer 13: regularnie zapamiętuj i wyciągaj wnioski z tego, co przerobiliście, przekształcając je w plik CLAUDE.md albo w skille. Zasada jest prosta. Po jakiejś rozmowie mówimy: „Podsumuj wszystko, czego nauczyłeś się z tej rozmowy, i zadaj sobie pytanie, jak moglibyśmy dotrzeć do tego etapu dwa–trzy razy szybciej. Wyciągnij wnioski w punktach”. A gdy je wyciągnie: „Okej, dodaj to do CLAUDE.md”.
(Informacja dodatkowa: CLAUDE.md to plik z instrukcjami wczytywany do kontekstu przy każdej wiadomości — dobre miejsce na trwałe zasady projektu.)
CLAUDE.md wczytuje się przy każdej wiadomości i zawsze jest czytany przez Claude’a. To dobre miejsce na wnioski, żeby model nie powtarzał tych samych błędów i wiedział, jak łatwiej dojść do celu. Mówimy więc: „Stwórz plik CLAUDE.md i dodaj te wnioski w skróconej wersji” — skróconej, bo najlepiej, żeby plik miał maksymalnie 200 linijek. Aktualizowanie go jest absolutnie niezbędne, żeby agent był coraz bardziej „agentowy” i uczył się na błędach.
Drobna rada: jeśli coś ma formę checklisty — jest procesem, na przykład obsługą narzędzia albo testowaniem strony — to zamiast dodawać to do CLAUDE.md, lepiej ubrać to w skill. Skille lepiej sprawdzają się przy powtarzalnych procesach i listach rzeczy do odhaczenia. Wystarczy powiedzieć: „Stwórz mi skill z tego i tego”. A jeśli to zestaw reguł i wniosków — niech zostanie w CLAUDE.md.
Deleguj integracje: mailing
Kolejny przydatny trik, a może przypomnienie: pracując z Claude Code, wiele rzeczy możemy oddelegować — nie musimy wszystkiego robić ręcznie. Jeśli tworzymy automatyzację mailową (na przykład zapis na listę oczekujących albo do newslettera), nie musimy tego ręcznie klepać w MailerLite. Możemy połączyć się z MCP MailerLite, dzięki czemu Claude Code stworzy taką automatyzację za nas. W przypadku MailerLite model nie może pisać za nas maili — jedyne, co musimy zrobić, to napisać maila i włączyć automatyzację, upewniając się, że wszystko jest dobrze skonfigurowane. Takie połączenie usuwa dużo bolączki związanej z klikaniem. Polecam poszukać MCP dla waszego konkretnego dostawcy automatyzacji mailowych.
Analityka (Umami) i formularze (Web3Forms)
Rada numer 15 to moja polecajka: strona Umami — przejrzysta, nieskomplikowana analityka do waszej strony. Wystarczy przejść do dokumentacji, skopiować całość lub sam link, wrócić do Claude Code i powiedzieć: „Połącz mnie z tą analityką, dodaj odpowiednie klasy w odpowiednich miejscach, żebym mógł śledzić najważniejsze wskaźniki”. Warto dodać: „Zanim to zrobisz, wypisz mi w tabeli rzeczy, które chcesz śledzić, a ja ci powiem, czy na pewno są dla mnie najważniejsze”. Model przeczyta dokumentację, poprosi o ID konta i wszystko dostosuje.
Skoro jesteśmy przy polecankach — przyda się też Web3Forms, umożliwiające łatwe tworzenie formularzy wysyłanych na waszego maila. W darmowej wersji jest chyba 250 wypełnień miesięcznie, co na początek w zupełności wystarcza. Jest to jeszcze prostsze niż MailerLite, gdzie trzeba uwierzytelnić domenę i trochę się znać. Jeśli się nie znacie, a chcecie zbierać kontakty do potencjalnych klientów, Web3Forms daje bardzo łatwą integrację — wszystkie powiadomienia trafiają na waszą skrzynkę.
Szybkie demo: Here.now
Godna polecenia jest też strona Here.now, która umożliwia jeszcze prostsze dzielenie się projektem z innymi. Kopiujemy dokumentację, wracamy do Claude Code, otwieramy nową rozmowę (nie tę, w której wyciągaliśmy wnioski), wklejamy dokumentację i mówimy: „Wyślij moją stronę na domenę w Here.now”. Po dwóch minutach strona jest pod testową domeną — możemy się nią z kimś podzielić i zapytać, co o niej myśli. To bardzo, bardzo łatwe.
Zaawansowane: pętla /loop z mierzalnym celem
Zostały dwie bardziej zaawansowane porady. Pierwsza: otwieramy terminal, wpisujemy claude, żeby się połączyć, wpisujemy „tak, ufam temu folderowi”, a następnie używamy komendy /loop, która pozwala zapętlić Claude’a, żeby zrobił coś konkretnego. To typowa pętla, ale trzeba umieć się nią posługiwać, żeby nie spaliła wszystkich tokenów na koncie.
Aby kontrolować pętlę, musimy dać jej jasny, mierzalny cel. Nie możemy powiedzieć „popraw tę stronę, dopóki nie będzie ładna” — bo jak zdefiniować „ładna”? Wtedy AI samo musi ocenić, że strona jest ładna, a tego nie chcemy, bo trochę się boję tego, co model uzna za ładne. Musimy więc powiedzieć na przykład: „Iteruj tę stronę, dopóki wynik SEO nie osiągnie takiej i takiej wartości” albo „dopóki wskaźniki szybkości Lighthouse nie będą takie i takie”. To można osiągnąć z /loop: dokładnie opisujemy, co chcemy otrzymać, i pozwalamy modelowi działać — dzięki czemu docelowo nie spalimy aż tylu tokenów. Warto to doglądać, ale jeśli dobrze opiszemy cel, znając się na tym, co opisujemy, wyniki będą bardzo fajne.
(Informacja dodatkowa: Lighthouse to narzędzie Google mierzące m.in. szybkość i jakość stron w wymiernych punktach.)
Zaawansowane: subagent testujący odporność strony
Ostatnia rada to tworzenie subagentów — a szczególnie jednego subagenta, który będzie regularnie próbował złamać naszą stronę. Tworzymy nowy folder o nazwie .claude, w nim kolejny folder agents, a w środku umieszczamy naszego subagenta, którego głównym zadaniem będą regularne próby zepsucia strony: sprawdzanie, czy coś może pójść nie tak. Na przykład wypełnienie formularza w dziwny sposób albo zmniejszenie okna przeglądarki, żeby coś się gdzieś załamało. Chcemy mieć takiego agenta, który jest naszym agentem — a nie użytkownikiem próbującym stronę złamać — i który sprawdzi, czy coś może potencjalnie pójść nie tak.
Powiemy więc Claude’owi: „Chciałbym, żebyś stworzył subagenta i umieścił go w folderze agents. Jego jedynym zadaniem ma być testowanie i stres-testowanie naszej strony oraz sprawdzanie, czy da się ją jakoś złamać — wypełnianie formularzy w dziwny sposób, zmniejszanie przeglądarki, robienie niespotykanych akcji. Chcę, żeby moja strona była na to odporna i żeby ten agent zawsze to testował. Może działać na jakimś modelu Sonnet, żeby nie był zbyt drogi. Chcę, żeby był bezwzględny”.
Model stworzy wtedy odpowiednio sformatowanego agenta, którego możemy wzywać w odpowiednim momencie. Możemy też zrobić mikroautomatyzację, żeby agent wzywał się sam co kilka powtórzeń lub co kilka zmian w kodzie. Możliwości jest mnóstwo, ale najłatwiej na początku po prostu wzywać go ręcznie i mieć takiego pomocnika do dyspozycji.
Zakończenie
I to by było na tyle na dzisiaj. Ze swojej strony zapraszam do newslettera „Chłopski rozum” oraz na stronę Cloudmaster, gdzie możecie dołączyć do warsztatów lub kursu z Claude Code dla nieprogramistów. Bardzo wam dziękuję. Mam nadzieję, że te rady trochę wam pomogły — miłego dnia. Cześć!
10 najważniejszych takeaways — z kontekstem zastosowania
1.Zacznij od zrzutu myśli i szkicu, nie od pustego promptu
Na czym polega: Przed wejściem do Claude Code spisz w pliku tekstowym założenia strony — cel, grupę docelową, sekcje — własnymi słowami, a nawet naszkicuj układ na kartce i załącz zdjęcie.
Jak stosować: Wypunktuj wszystko łopatologicznie w Obsidianie lub dowolnym edytorze, dołącz szkic i dopiero to podaj modelowi jako podstawę pracy.
Na co uważać: Bez tego przemyślenia gubią się w prompcie i są spłaszczane przez AI. Szkic działa tylko wtedy, gdy wyraźnie każesz modelowi się na nim wzorować.
2.Wymuszaj planowanie i myślenie przed działaniem
Na czym polega: Tryb planowania oraz tryb brainstormingu (plugin Superpowers) sprawiają, że model najpierw układa checklistę i zadaje pytania, zamiast od razu pisać kod.
Jak stosować: Na starcie projektu włącz tryb planowania; przy trudniejszych decyzjach opisz problem i dopisz na końcu wiadomości słowo „brainstorming”.
Na co uważać: Nie wysyłaj samego „brainstorming” bez kontekstu. Model działający od razu popełnia więcej błędów i marnuje tokeny.
3.Przekaż inspirację precyzyjnie: zrzut całej strony plus skopiowane style
Na czym polega: Zamiast opisywać słowami „ładną stronę”, pokaż konkret — pełny zrzut ekranu (wtyczka GoFullPage) i skopiowane style CSS z inspektora przeglądarki.
Jak stosować: Zrób „copy image” całej strony, w DevTools zaznacz body → „Copy styles”, wklej oba do Claude’a i poproś o wierne odtworzenie układu bez kopiowania tekstu.
Na co uważać: Poczekaj, aż zrzut się skopiuje. Sam obrazek to za mało — dołączenie stylów daje modelowi wymierne dane o kolorach i odstępach.
4.Formułuj polecenia bardzo precyzyjnie
Na czym polega: Jakość efektu zależy od precyzji promptu — trzeba nazwać sekcje, ich liczbę, cel strony i wygląd, zamiast mówić „nowoczesna, ładna strona”.
Jak stosować: Poświęć minutę–dwie dłużej na dokładny opis: jakie sekcje, po co, w jakim stylu, dla kogo.
Na co uważać: Ogólnikowe polecenia to marnowanie tokenów i czasu — model błądzi, a ty musisz go wielokrotnie naprowadzać.
5.Daj modelowi oczy — Chrome DevTools MCP i samodzielne zrzuty ekranu
Na czym polega: Bez podglądu Claude pisze kod „na ślepo” i nie widzi np. przycisku zasłoniętego okienkiem. Chrome DevTools MCP daje mu przeglądarkę i możliwość weryfikacji efektu.
Jak stosować: Zainstaluj Chrome DevTools MCP, każ modelowi otworzyć Chrome i robić zrzuty ekranu, iterując, „dopóki nie będzie dumny”, że wygląda jak wzorzec.
Na co uważać: Trzeba wprost polecić robienie i oglądanie zrzutów — inaczej model nie sprawdzi własnej pracy. Wskaż mierzalny warunek zakończenia.
6.Korzystaj z gotowych komponentów, ale z umiarem
Na czym polega: 21st.dev to biblioteka gotowych sekcji i komponentów (cenniki, galerie, przyciski), które można wkleić do projektu.
Jak stosować: Przeglądaj kategorie, zapisuj ulubione komponenty do własnej kolekcji, kopiuj kod i demo, a potem poproś Claude’a o wdrożenie.
Na co uważać: Nie przeładuj strony efektami — wybieraj dwie–trzy sekcje na stronę. Nadmiar bajerów pogarsza działanie i czytelność.
7.Zbuduj style guide jako jedyne źródło prawdy i eksperymentuj w Claude Design
Na czym polega: Plik style-guide.html z kolorami, czcionkami, odstępami i cieniami utrzymuje spójność wszystkich stron; wariacje warto generować w Claude Design, nie w plikach projektu.
Jak stosować: Poproś o utworzenie style guide jako jedynego źródła prawdy, załącz go w Claude Design i generuj np. pięć różnych wersji sekcji hero zgodnych ze stylem.
Na co uważać: Robienie wielu wariantów wprost w Claude Code tworzy bałagan w plikach. Do projektu przenoś dopiero to, co wybierzesz.
8.Hostuj i aktualizuj stronę przez GitHub z poziomu Claude Code
Na czym polega: Osobne repozytorium GitHub pozwala publikować stronę na żywo, łatwo załączać ją jako kontekst i zarządzać nią bez ręcznego wgrywania plików.
Jak stosować: Każ modelowi utworzyć repozytorium i wgrać projekt, połącz repo z hostingiem (np. Hostinger → Git → gałąź main), a zmiany publikuj poleceniem „wyślij na GitHub”.
Na co uważać: Ustaw zasadę, żeby model pytał przed wysłaniem — wysłanie na GitHub oznacza publikację na żywo. GitHub przydaje się nawet bez konkretnego hostingu.
9.Utrwalaj wiedzę w CLAUDE.md i skillach
Na czym polega: Regularne przekształcanie wniosków z rozmów w plik CLAUDE.md (reguły) lub skille (powtarzalne procesy/checklisty) sprawia, że agent uczy się na błędach.
Jak stosować: Poproś o podsumowanie „jak dojść do tego etapu 2–3 razy szybciej”, dodaj wnioski do CLAUDE.md; procesy krok-po-kroku ubieraj w osobne skille.
Na co uważać: Trzymaj CLAUDE.md w ryzach — najlepiej do 200 linijek. Reguły do CLAUDE.md, checklisty do skilli; mieszanie obniża skuteczność.
10.Kontroluj pętlę /loop mierzalnym celem i testuj odporność subagentem
Na czym polega: /loop zapętla pracę modelu do osiągnięcia celu, a dedykowany subagent w .claude/agents próbuje „złamać” stronę (dziwne dane w formularzach, zmniejszanie okna).
Jak stosować: Zadawaj pętli mierzalne warunki stopu (np. wynik SEO lub Lighthouse). Stwórz „bezwzględnego” subagenta stres-testującego, uruchamianego ręcznie lub automatycznie.
Na co uważać: Nigdy nie każ pętli działać „aż będzie ładna” — subiektywny cel spala tokeny. Doglądaj przebiegu; subagenta uruchamiaj na tańszym modelu (Sonnet).