Opisujesz zwykłymi zdaniami proces, który dziś robisz ręcznie. Chwilę później w twoim n8n stoi gotowy workflow: wyzwalacz, dwa agenty AI, prompty wpisane w odpowiednie pola, wysyłka maila na końcu. Nie przeciągnąłeś ani jednego węzła. Brzmi jak obietnica z reklamy, ale mechanizm jest prosty i da się go powtórzyć. Ma też jedną cenę: to, co zbuduje agent, nadal musisz przejrzeć sam, bo nie wszystko ustawi tak, jak prosiłeś.
Pokażę ci, co Claude Code dostaje, żeby rozumieć n8n, jak ustawić projekt, dlaczego zaczynasz od planu, co sprawdzasz przed włączeniem workflowu i gdzie są granice tej metody.
Ręce i wiedza: czego Claude Code brakuje do n8n
Najpierw dwa pojęcia. Workflow w n8n to zautomatyzowany przepływ: ciąg kroków, które uruchamiają się same, na przykład codziennie rano albo po przyjściu formularza. Każdy krok to węzeł (po angielsku node): pobierz dane, zapytaj model AI, wyślij maila.
Claude Code sam z siebie jest bystry i zna format JSON, w którym n8n zapisuje workflowy. Nie zna jednak dobrze konkretnych węzłów, ich parametrów ani składni wyrażeń. Wyrażenie to krótki zapis w polu węzła, który mówi „weź tu wynik z poprzedniego kroku”. Bez tej wiedzy agent zgaduje, a zgadywanie w konfiguracji kończy się workflowem, który nie startuje.
Dlatego dajesz mu dwie rzeczy.
Ręce, czyli serwer MCP dla n8n. MCP to standardowy sposób podłączania modelu do zewnętrznych narzędzi. Serwer MCP to wtyczka, przez którą agent może coś sprawdzić albo zrobić poza rozmową. Serwer dla n8n daje mu katalog węzłów z opisem parametrów, bibliotekę gotowych szablonów workflowów do podejrzenia i, co najważniejsze, dostęp do twojej instancji n8n: może w niej tworzyć, aktualizować, walidować i włączać workflowy. Instancja to po prostu twoje konto n8n, w chmurze albo na własnym serwerze.
Wiedzę, czyli skille n8n. Skill to plik z instrukcjami, który agent czyta dopiero wtedy, gdy go potrzebuje. Zestaw dla n8n uczy go składni wyrażeń, korzystania z narzędzi serwera MCP, typowych wzorców workflowów, walidacji, konfiguracji węzłów oraz pisania węzłów z kodem w JavaScripcie i Pythonie. Ładowanie na żądanie ma znaczenie: gdyby agent przy każdej wiadomości czytał całą dokumentację wszystkich węzłów, zapchałby sobie pamięć roboczą i przepalał limity. Wie, że ta wiedza istnieje, i sięga po nią, kiedy zadanie tego wymaga.
Oba elementy są dostępne jako otwarte repozytoria na GitHubie. Razem sprawiają, że agent przestaje zgadywać, a zaczyna sprawdzać.
Projekt, CLAUDE.md i instalacja, którą zlecasz agentowi
Ustawienie samego Claude Code to temat na osobny tekst. W skrócie: instalujesz rozszerzenie Claude Code w edytorze, na przykład w VS Code, logujesz się swoim kontem i otwierasz pusty folder. Ten folder jest projektem: wszystko, co agent przygotuje, ląduje w nim jako pliki.
Pierwszy plik, jaki powinien tam powstać, to CLAUDE.md. Traktuj go jak stałą instrukcję systemową dla tego projektu: w jakim środowisku agent pracuje, po co ten projekt istnieje i jakich zasad ma się trzymać. Bez niego każda rozmowa zaczyna się od zera, a pliki mnożą się bez ładu.
Nie musisz pisać go sam. Przełączasz Claude Code w tryb planowania (agent wtedy tylko analizuje i proponuje, niczego nie zmienia) i piszesz wprost: pomóż mi stworzyć CLAUDE.md dla projektu, w którym będziesz budował workflowy w mojej instancji n8n, korzystając z serwera MCP i skilli n8n. Agent dopyta o szczegóły: jakie narzędzia dostanie, czy n8n działa w chmurze czy na twoim serwerze. Wklejasz mu adresy obu repozytoriów, a on sam je czyta. Dobrze przygotowany plik opisuje kolejność pracy: zrozum wymagania, przejrzyj szablony, sprawdź węzły, zbuduj, zwaliduj, wdróż. Do tego zasady bezpieczeństwa.
Instalację też zlecasz agentowi. Zamiast przepisywać instrukcje z repozytoriów, piszesz: zainstaluj ten serwer i te skille i upewnij się, że działają w tym projekcie. Agent zatrzyma się w momencie, w którym zabraknie mu danych. Tu zapyta o adres twojej instancji i o klucz API, czyli długi ciąg znaków, który działa jak hasło dla programów. Klucz tworzysz w ustawieniach n8n.
Ten klucz traktuj jak hasło do całej instancji, bo agent może przez niego tworzyć i zmieniać workflowy. Konfiguracja z kluczem trafia do pliku w projekcie, więc ten plik nie powinien trafić do wspólnego folderu ani do repozytorium. Nadaj kluczowi nazwę, po której poznasz projekt, i daj mu tylko te uprawnienia, których projekt wymaga, jeśli twój plan n8n na to pozwala. Gdy projekt się skończy, klucz kasujesz.
Po instalacji restartujesz Claude Code i sprawdzasz połączenie dwoma pytaniami. Pierwsze: wyszukaj przez serwer MCP węzeł webhook. Drugie: czy możesz tworzyć workflowy w mojej instancji i czy masz załadowane skille n8n. Jeśli na oba dostajesz konkretną odpowiedź, a nie zapewnienie, możesz budować.
Najpierw plan, potem budowa
Przykład, na którym widać całą metodę: codziennie o 7:00 agent badawczy szuka w sieci nowości z twojej branży, drugi agent zamienia wyniki w newsletter sformatowany w HTML, a całość przychodzi mailem przez Gmail. Dwa osobne agenty, każdy z modelem, który wskazujesz.
Taki opis wklejasz w trybie planowania, nie od razu do wykonania. Agent przegląda katalog węzłów, a potem dopytuje o to, czego nie napisałeś: na jaki adres wysłać newsletter, jakiego narzędzia użyć do wyszukiwania w sieci, w jakiej strefie czasowej liczyć 7:00. To są pytania, które przy ręcznym budowaniu odkryłbyś dopiero przy pierwszym błędzie.
Potem dostajesz plan: architekturę, listę węzłów, konfigurację każdego z nich. Przeczytaj go, zanim zaakceptujesz. W tym przykładzie plan zakładał przygotowanie workflowu jako pliku JSON na dysku, a nie w instancji n8n. Jedno zdanie korekty przed wykonaniem kosztuje mniej niż przerabianie gotowej pracy.
Dopiero gdy plan się zgadza, przełączasz agenta w tryb, w którym wykonuje kroki bez pytania o każdy z osobna. Automatyczne wykonanie włączasz tylko wtedy, gdy ufasz planowi. Nawet w tym trybie agent zatrzyma się i zapyta, jeśli czegoś mu brakuje.
W trakcie budowy widzisz jego listę zadań: utwórz workflow, zwaliduj go, zgłoś wynik. To walidacja robi tu najwięcej. Agent wysyła workflow do instancji, sprawdza go i czyta błędy: źle ustawione parametry węzła z kodem, nieprawidłowa konfiguracja węzła komunikatora. Każdy błąd poprawia sam i waliduje ponownie, aż konfiguracja przejdzie. Na koniec dostajesz link do workflowu i listę następnych kroków.
Przegląd przed włączeniem: każdy węzeł przechodzi przez twoje ręce
Workflow z linku wygląda na gotowy. Nie jest. Dwie rzeczy zostają po twojej stronie zawsze, a trzecia wyjdzie przy przeglądzie.
Dane logowania podłączasz sam. Agent buduje węzły, ale konta do wyszukiwarki, do dostawcy modeli i do poczty łączysz ręcznie w n8n. To dobry podział: agent nie musi znać twoich haseł do usług.
Model w każdym węźle agenta sprawdzasz sam. W tym przykładzie oba agenty dostały starsze wersje modeli niż te, które wskazywał opis. Agent dopisał też od siebie parametry, o które nikt nie prosił, jak limit długości odpowiedzi i temperaturę. Workflow działał, tylko nie tak, jak go zamówiłeś. Takiego błędu nie złapie żadna walidacja, bo dla n8n taka konfiguracja jest poprawna.
Prompty i wyrażenia czytasz w całości. Agent badawczy dostał sensowną rolę i listę tematów do przeszukania, z prośbą o podawanie źródeł. Agent piszący newsletter dostał w wiadomości wyrażenie, które wciąga wyniki z poprzedniego kroku, oraz instrukcję stylu HTML w prompcie systemowym. Sprawdź, czy wyrażenia wskazują właściwe pola. Zwróć też uwagę na decyzje podjęte za ciebie. W węźle Gmaila agent wyłączył dopisek n8n na końcu maila, choć nikt go o to nie prosił. Tu akurat dobrze, ale takie rzeczy chcesz wiedzieć, zanim workflow ruszy.
Potem uruchamiasz workflow ręcznie, tak jakby była już 7:00, i przechodzisz krok po kroku: co wyszukał agent badawczy, co dostał agent piszący, co wyszło w mailu. Dopiero po takim przebiegu włączasz harmonogram.
Poprawki zlecasz w tej samej rozmowie: zmień prompt, podmień narzędzie wyszukiwania, dodaj sekcję. Agent zmienia workflow w instancji, a ty widzisz zmianę w n8n. Ten sam przegląd robisz po każdej większej zmianie.
Granice: małe kawałki, szkic i pytania
Ta metoda ma limity i warto je znać, zanim na nie trafisz.
Nie zamawiaj wszystkiego naraz. Prośba o workflow na kilkadziesiąt węzłów w jednym podejściu potrafi położyć instancję. Agent wysyła duże zmiany, przekracza limity czasu, ponawia próbę i znowu, aż serwer przestaje odpowiadać. Instancja w chmurze n8n może po czymś takim leżeć długo i wymagać kontaktu z obsługą, bo nie zrestartujesz jej sam. Na własnym serwerze zrobisz to samodzielnie, ale problem wróci przy kolejnej zbyt dużej prośbie. Budujesz więc kawałkami: jeden fragment przepływu, przegląd, test, następny fragment.
Narysuj przepływ, zanim go opiszesz. Szkic na tablicy albo w dowolnym narzędziu do diagramów, nawet zrobiony na szybko, porządkuje twoje myślenie. Moim zdaniem zrzut takiego szkicu dołączony do opisu daje agentowi lepszy punkt startu, bo od razu widzi strukturę, którą masz w głowie: co uruchamia przepływ, gdzie się rozgałęzia, gdzie trafiają dane.
Pytaj, kiedy czegoś nie rozumiesz. Nie musisz czytać kodu, żeby pracować w ten sposób. Gdy agent zrobi coś niejasnego, piszesz: wyjaśnij mi to albo dlaczego tak to ustawiłeś. Bywa też, że agent proponuje, żebyś coś zainstalował albo ustawił sam. Wtedy wystarczy odpowiedzieć: zrób to ty.
Plan rośnie razem ze złożonością. Przy prostym workflowie tryb planowania oszczędza kilka poprawek. Przy bardziej złożonym, gdzie trzeba przemyśleć, co dzieje się z danymi po drodze, dopytuje o rzeczy, o których sam byś nie pomyślał.
Najcenniejsza umiejętność w tej pracy to jasny opis efektu, jakiego oczekujesz, tak jak opisałbyś go programiście albo kierownikowi projektu, i uczciwy przegląd tego, co dostałeś. Agent buduje, a ty zatwierdzasz. Zacznij od jednego małego procesu, który dziś robisz ręcznie: opisz go w trybie planowania i przejrzyj każdy węzeł, zanim go włączysz.