Jak zbudować pipeline w Claude Routines

Wczoraj postawiłem swoją pierwszą Claude Routine. Nic skomplikowanego — codziennie o 2:00 w nocy Routine przechodzi po świeżych nowościach ze świata AI i Claude Code, wybiera kilka tematów, które warto opisać, i dopisuje je do backlog.md w moim prywatnym repo na GitHubie. Otwiera PR-a, ja rano klikam merge i mam gotową listę tematów do postów i filmów zamiast scrollowania X czy LinkedIna.

Odpaliłem. Zadziałało. Dwa tematy z tego PR-a poszły dziś do sieci.

Ale potem siedziałem i pomyślałem to, co pewnie pomyśli każdy programista po pierwszym takim eksperymencie. OK, spoko, ale to jest jedna rutyna z jednym promptem. A gdybym chciał to ułożyć w łańcuch? Zrobić jakąś namiastkę n8n albo OpenClaw? Rutyna A szuka, rutyna B od razu rozpisuje jeden z tematów— zarys wpisu, szkic scenariusza, listę źródeł do weryfikacji. Tak żebym rano miał nie listę, tylko gotowy do obróbki draft.

I okazało się, że to jest kilka kliknięć roboty. Claude Routines mają trigger typu API, który daje ci unikalny URL i token. Wywołujesz ten URL strzałem HTTP POST z bearer tokenem — rutyna się odpala. W prompcie poprzedniej rutyny każesz jej zrobić ten strzał jako ostatni krok. I masz pipeline. Bez Zapiera, bez n8n, bez stawiania własnego serwera.

Opowiem ci, jak to wygląda krok po kroku, bo to jest jedna z tych rzeczy, które wyglądają na bardziej skomplikowane niż są naprawdę.

Najpierw — jakie tu masz triggery

Każdy Routine ma jeden albo więcej triggerów. Trigger mówi kiedy Routine ma się odpalić. Do wyboru masz trzy rodzaje:

Schedule — cyklicznie, najszybciej co godzinę. Presety: hourly, daily, weekdays, weekly. Dowolny harmonogram ustawiasz komendą /schedule update w CLI po stworzeniu rutyny.
GitHub — w reakcji na event z podpiętego repo (push, open PR, comment itp.).
API — unikalny URL, który odpala rutynę po przyjęciu HTTP POST.

Sam API to jest tym czego potrzebujemy do uruchomienia pipeline’a. Dodajesz trigger API do istniejącej rutyny, dostajesz endpoint typu:

POST https://api.anthropic.com/v1/claude_code/routines/trig_01ABCDEFGHJKLMNOPQRSTUVW/fire

Trigger ID (trig_01...) jest unikalny dla tego konkretnego triggera. Do tego dostajesz bearer token — pokazuje się raz i potem już nie da się go odzyskać, więc albo kopiujesz od razu, albo regenerujesz. Token ma scope do odpalenia tej konkretnej rutyny — nie daje żadnego innego dostępu.

Udany request zwraca JSON z ID i URL-em nowej sesji:

{
  "type": "routine_fire",
  "claude_code_session_id": "session_01HJKLMNOPQRSTUVWXYZ",
  "claude_code_session_url": "https://claude.ai/code/session_01HJKLMNOPQRSTUVWXYZ"
}

Czyli od razu dostajesz link, pod którym możesz podejrzeć, co B robi w trakcie.

Tu jest istotna rzecz: źródło requestu nie musi być żadnym zewnętrznym systemem. To może być inna Claude Routine, która w swoim prompcie ma po prostu „gdy skończysz, wywołaj ten URL”.

Prosty pipeline na bazie tego, co już mam

Pokażę na swojej rutynie — tej nocnej, która dopisuje tematy do backlogu.

Mój wariant przed pipelinem:

2:00 → Routine "backlog-ai-news"
         → przegląd nowości
         → dopisanie 3-5 tematów do backlog.md
         → PR

Mój wariant po pipelinie, który właśnie stawiam:

2:00 → Routine A: "backlog-ai-news"
         → przegląd nowości
         → dopisanie tematów do backlog.md
         → wybór JEDNEGO najważniejszego tematu
         → HTTP POST do URL Routine B (w body: temat + źródła)
         → PR z nowym backlogiem

~2:15 → Routine B: "topic-draft"
         → odbiera temat i źródła z body
         → otwiera plik `drafts/YYYY-MM-DD-<slug>.md`
         → rozpisuje outline wpisu (hak, 3-4 sekcje, CTA)
         → dopisuje listę źródeł do weryfikacji
         → PR z draftem

Rano siadam do dwóch PR-ów: jeden z backlogiem, drugi z gotowym outlinem jednego z tematów. Dwa zamiast jednego. Oba na tym samym darmowym narzędziu. Będę jeszcze testował jak ominąć robienie Pull Requestów (jest checkbox czy pozwalamy Claude’owi na takie szalone rzeczy jak commit do dowolnego brancha), bo na razie średnio się mnie słucha akurat w tym temacie.

Jak technicznie spiąć A z B

Krok 1: przygotuj własne Environment. To jest moment, który mnie zaskoczył, a dokumentacja mówi o nim jednym zdaniem między innymi. Domyślne środowisko (Default) nie pozwala dodać własnych zmiennych środowiskowych ani setup scriptu. Żeby mieć sekrety w sesji, musisz najpierw utworzyć własne Environment, zanim podepniesz je pod Routine A.

W edycji Routine A klikasz pole środowiska i wybierasz New Environment (albo idziesz w ustawienia konta i tworzysz je niezależnie). W nowym environment masz trzy rzeczy do ustawienia:

Network access — musi mieć wyjście na świat (rutyna będzie wołać api.anthropic.com).
Environment variables — tu wrzucasz DRAFT_ROUTINE_URL i DRAFT_ROUTINE_TOKEN (wartości dostaniesz w kroku 2). Są szyfrowane, nie pokazują się w logach sesji.
Setup script — opcjonalnie, jeśli chcesz zainstalować cokolwiek przed sesją (dla tego pipeline’a zwykle nic nie trzeba).

Zapisujesz environment, potem wracasz do Routine A i wybierasz go z listy. Na Default po prostu nie masz gdzie wkleić tokena.

Krok 2: postaw Routine B z triggerem API. Wchodzisz na claude.ai/code/routines, New routine, normalna konfiguracja (prompt, repo, environment). Zapisujesz rutynę — URL i token dla triggera API są generowane dopiero po zapisie, bo zależą od ID rutyny. Potem otwierasz rutynę ponownie w trybie edycji, w sekcji Select a trigger dodajesz API, kopiujesz URL i klikasz Generate token. Token pokaże się raz — zapisz go od razu. Jeśli zgubisz, musisz w tym samym modalu kliknąć Regenerate (co unieważnia poprzedni).

Krok 3: wklej URL i token do environment Routine A. Wracasz do environmentu z kroku 1, edytujesz dwie zmienne:

DRAFT_ROUTINE_URL = https://api.anthropic.com/v1/claude_code/routines/trig_01ABC.../fire
DRAFT_ROUTINE_TOKEN = sk-ant-oat01-xxxxxxxxxxxxxxxxxxxx

Krok 4: w prompcie Routine A dopisz ostatni krok. Tu jest drugi ważny szczegół z dokumentacji: endpoint /fire przyjmuje tylko jedno opcjonalne pole — text, wolny tekst. Jeśli wrzucisz strukturalny JSON, dojdzie jako literalny string. Nie da się przekazać ustrukturyzowanych pól, które Routine B odczyta „po nazwach”. Piszesz płaski tekst tak, żeby druga rutyna umiała go rozparsować. Po prostu traktuj to jak automatycznie wpisany prompt dla kolejnej rutyny.

Na końcu promptu Routine A dajesz instrukcję typu:

Gdy zakończysz zapis backlog.md i otworzysz PR, wybierz JEDEN
temat z tych, które właśnie dopisałeś — ten, który wygląda na
najbardziej wartościowy do opisania w najbliższych dniach.

Następnie odpal drugą rutynę przekazując jej opis wybranego
tematu. Użyj komendy:

curl -X POST "$DRAFT_ROUTINE_URL" \
  -H "Authorization: Bearer $DRAFT_ROUTINE_TOKEN" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d @- <<'EOF'
{
  "text": "Temat: <tytuł roboczy>\nSlug: <hyphenated-slug>\nKąt: <jedno zdanie>\nŹródła:\n- <link 1>\n- <link 2>"
}
EOF

Udany request zwraca JSON z polem claude_code_session_url.
Dopisz tę wartość do pliku pipeline.log w repo (append, nie
nadpisuj) razem z datą i wybranym tematem.

Jeśli curl zwróci błąd HTTP albo odpowiedź nie zawiera
claude_code_session_url — zapisz treść odpowiedzi do pipeline.log
i kończ sesję normalnie. Nie otwieraj osobnego PR-a dla logu,
dopisuj do istniejącego.

Uwaga o headerze anthropic-beta. Endpoint /fire jest dostępny pod beta headerem z datą. Anthropic zadeklarował, że breaking changes idą pod nowy, datowany header, a dwie poprzednie wersje dalej działają przez pewien czas, żeby dać czas na migrację. Znaczy to tyle, że header będziesz musiał raz na jakiś czas podbić — ale to kwestia miesięcy, nie dni.

Krok 5: w prompcie Routine B odbierz tekst. Payload z pola text trafia do Routine B razem z jej zapisanym promptem jako wolny tekst. Nie jest parsowany na pola. W prompcie B jasno opisujesz format, którego się spodziewasz:

Zostałaś odpalona z payloadem tekstowym o następującym formacie
(linie w kolejności, wartości po dwukropku):

  Temat: <tytuł roboczy>
  Slug: <hyphenated-slug>
  Kąt: <jedno zdanie>
  Źródła:
  - <link 1>
  - <link 2>

Zadanie:
1. Wyciągnij wartości z payloadu. Jeśli brakuje którejś z linii
   albo payload jest pusty — zakończ bez zmian, napisz w sesji
   "Brak lub niepełny payload. Nic nie robię".
2. Utwórz plik drafts/YYYY-MM-DD-<slug>.md.
3. Wygeneruj strukturę wpisu: hook na otwarcie, 3-4 sekcje H2,
   CTA.
4. Pod strukturą dopisz sekcję "Źródła do weryfikacji" z listą
   linków z payloadu.
5. NIE pisz pełnej treści. To ma być outline z notami, nie draft.
6. Otwórz PR z tytułem "[draft] <tytuł roboczy>".

Plain-text payload brzmi prymitywnie, ale ma jeden plus: pisząc to oczami człowieka, od razu widzisz, co Routine B dostanie do ręki. Zero zagadek.

Krok 6: test. Najpierw Run now na Routine B — podajesz ręcznym curl-em przykładowy text i patrzysz, czy drugi etap działa sam z siebie. Dopiero potem Run now na Routine A i obserwujesz, czy łańcuch się domknie. Logi obu sesji widać w panelu — każda odpala swoją pełną sesję Claude Code, więc widzisz dokładnie, co komu się wywaliło.

Rzeczy, o które można się potknąć

Limit dzienny jest per konto i zależy od planu. Dokumentacja mówi tyle: w oknie doby każde konto ma cap na liczbę odpaleń rutyn, a jego aktualną wartość widać na claude.ai/code/routines i w Settings > Usage. Pipeline dwuelementowy odpalany codziennie zjada dwa uruchomienia z tej puli. Zanim zaczniesz mnożyć łańcuchy, sprawdź ile ci zostaje — zwłaszcza przy planie startowym. Organizacje z włączonym extra usage mogą jeździć po metered overage, ale konta indywidualne dostają twardy odcięcie.
Brak gwarancji kolejności czasowej poza samym „B startuje po A”. Strzał HTTP jest synchroniczny w sensie „dostajesz odpowiedź z ID sesji”, ale sama Routine B leci w swojej niezależnej sesji. A kończy się po swoim, B leci dalej. To nie jest żaden problem dla mojego scenariusza, ale jeśli planujesz pipeline, który musi poczekać na rezultat poprzedniego kroku (nie sam fakt odpalenia) — potrzebujesz innego pomysłu. Można np. kazać B zapisać rezultat do repo i wtedy GitHub trigger odpali C.
Token się wyciekł jak nie uważałem. Wrzucenie tokenu „na chwilę” bezpośrednio w prompt aż prosi się o to, żeby o tym zapomnieć i potem gdzieś przypadkiem takim token z URLem do naszej rutyny pokazać publicznie. Sekrety trzymaj w environment, koniec. A jak już się wyciekł — Regenerate w tym samym modalu unieważnia stary.
Błędy curl nie przerywają sesji. Jeśli Routine B nie wstanie (np. token unieważniony), Routine A skończy się normalnie i PR z backlogu i tak wyląduje. Łatwo to przeoczyć. Dlatego w prompcie A mam explicit zapis statusu do pipeline.log — żeby rano po PR-ze widzieć, czy łańcuch zadziałał, czy pierwszy ogon odciął drugi.
Możesz zrobić pętlę. Jeśli A wywoła B, a B ma w swoim prompcie „na koniec wywołaj A”, odpali się cykl, który zje cały dzienny limit w kilka minut. Trzymaj pipeline jako DAG, nie jako cykl. Bardzo wczesne ograniczenie: jedna rutyna jednym strzałem wywołuje jedną kolejną rutynę, nigdy rutynę, która ją samą może odpalić.
Beta header. anthropic-beta: experimental-cc-routine-2026-04-01 — endpoint jest pod betą z datą. Breaking changes idą pod nową datę, dwie poprzednie wersje działają równolegle przez jakiś czas. W praktyce: raz na parę miesięcy sprawdzasz dokumentację i podbijasz header w environment.

Gdzie to się realnie opłaca

Moje trzy scenariusze, które leżą mi teraz na liście do przetestowania (prócz samego research → draft):

Research głęboki + research szeroki. Routine A o 2:00 robi szeroki przegląd (wiele źródeł, krótka lista). Routine B o 2:30 dla jednego wybranego tematu robi głęboki research — szuka 10 źródeł, porównuje, wrzuca notatki do repo. Różne Routines, różne prompty, różny charakter pracy. Nie da się tego zrobić jednym promptem bez rozmycia jakości.
Czyszczenie backlogu zadań w pet projekcie. Routine A co rano o 6:00 sprawdza w BACKLOG.md, które zadania są w toku od ponad 3 dni, i wypisuje listę. Routine B dostaje tę listę i dla każdego zadania próbuje postawić diagnozę — czy czeka na decyzję, czy utknęło na implementacji, czy to ja zapomniałem. PR z analizą co zablokowało co.
Release notes. Routine A po merge’u do main (trigger GitHub) zbiera commity z ostatniego tygodnia i przygotowuje surowy changelog. Routine B odbiera ten changelog i redaguje go na dwa sposoby: jeden techniczny na GitHuba, drugi ludzki na social media. Dwa różne tony, dwa różne PR-y, jeden trigger.

Zauważ jedną rzecz: we wszystkich tych przykładach każdy krok to inna praca. Inny prompt. Inny focus. Próba wciśnięcia dwóch prac w jeden prompt zwykle kończy się gorszą jakością obu. Łańcuch Routines pozwala trzymać każdy prompt skupiony.

Limity dzienne — pomyśl zanim się rozkręcisz

Powtórzę, bo to największa pułapka: cap dzienny jest per konto, nie per routine. Pipeline dwuelementowy odpalany codziennie to już dwa uruchomienia z dziennej puli. Jeśli do tego dołożysz testowe Run now w ciągu dnia i jeszcze jakąś ad-hoc rutynę — szybko podchodzisz pod limit.

Aktualną wartość swojego capu widać na claude.ai/code/routines oraz w Settings > Usage. Dokumentacja celowo nie podaje liczb na stałe, bo w research preview potrafią się ruszać razem z planami. Zanim zaczniesz budować pięć pipeline’ów, zrób sobie na kartce prostą sumę:

liczba_rutyn_w_pipelinie × liczba_odpaleń_na_dobę = użyte_uruchomienia

I porównaj z aktualnym limitem w twoim panelu z zapasem na testy i ad-hoc. Konta z włączonym extra usage mogą przekroczyć cap na metered overage — sprawdzisz to w Settings > Billing. Bez extra usage dostajesz twardy stop do rana.

Jedna rzecz do zapamiętania

Jeśli miałbyś wyjść z tego wpisu z jedną myślą, niech to będzie ta: Routines nie są osobnymi narzędziami do osobnych zadań. Są klockami. Jeden klocek robi jedną rzecz dobrze. Kilka klocków spiętych triggerem API daje ci pipeline, który wcześniej wymagałby serwera, schedulera i integracji z Anthropic API po twojej stronie. Tu masz to wszystko w jednym miejscu, za tokeny, za które i tak płacisz.

Tylko pilnuj dwóch rzeczy: trzymaj łańcuchy krótkie (2, może 3 klocki na start) i trzymaj je liniowe, bez pętli. Reszta to już tylko kwestia, co zautomatyzować.

A Ty?

Spinałeś już kilka rutyn w jeden pipeline? Jeśli tak — ciekawi mnie, ile uruchomień dziennie to realnie zjada i czy trafiłeś na jakieś pułapki, o których nie wspomniałem. A jeśli jeszcze nie — co byłoby twoim pierwszym łańcuchem, gdybyś miał postawić jeden dziś wieczorem? Daj znać w komentarzu.