Procedury Claude Code: uruchamiaj swojego agenta kodowania według harmonogramu w chmurze

Każda z trzech części pełni konkretną rolę:

• Prompt. Najważniejszy element, bo procedura działa bez twojej akceptacji na każdym kroku. Prompt musi nieść całe zadanie i definicję ukończenia.
• Repozytoria. Claude klonuje je na początku każdego uruchomienia i pracuje wewnątrz nich.
• Konektory. Integracje claude.ai na twoim koncie, takie jak Slack czy Linear, z których procedura może czytać i do których może pisać podczas działania. Procedura triażująca wsparcie może na przykład czytać kanał Slacka i tworzyć zgłoszenia w Linear.

Konektory dla procedur dodaje się na platformie claude.ai, podobnie jak serwery MCP. Twoje lokalne konfiguracje nie są przenoszone.

Procedurę można uruchomić na trzy sposoby: według harmonogramu, przez wywołanie API lub poprzez zdarzenie GitHub. Jedna procedura może łączyć wszystkie trzy.

Procedury kontra /loop

Istnieje różnica między /loop a /schedule, bo rozwiązują różne problemy.

Zadanie /loop żyje w twojej bieżącej sesji. Uruchamia się tylko wtedy, gdy Claude Code działa i jest w stanie bezczynności na twojej maszynie, a zamknięcie terminala je zatrzymuje. To sprawia, że dobrze nadaje się do odpytywania buildu, który właśnie obserwujesz.

Więcej o /loop i innych ważnych komendach znajdziesz w naszym tutorialu Claude Code Terminal.

Procedura działa w chmurze i jest niezależna od jakiejkolwiek sesjin:

Jest też trzecia, lokalna opcja. Zadania harmonogramu na pulpicie działają na twoim własnym komputerze — dla pracy, która potrzebuje lokalnych plików i narzędzi. Uruchamiają się tylko, gdy komputer nie śpi, ale nie wymagają otwartej aplikacji Claude.

Procedura, którą zbudujemy

Model mentalny gotowy. Teraz potrzebujesz czegoś, nad czym procedura popracuje. Na potrzeby tego tutorialu zbudowaliśmy pr-review-demo, mały projekt w Pythonie z jednym otwartym pull requestem.

Zawiera pakiet cartlib obsługujący koszyk: przechowuje ceny jako całkowite centy, stosuje zniżki członkowskie i ilościowe oraz dodaje stanowy podatek obrotowy, by uzyskać końcową kwotę. Pakiet na gałęzi głównej jest poprawny.

Otwarty pull request dodaje kupon na darmową wysyłkę i zawiera prawdziwy błąd, który umieściliśmy celowo. To niezgodność jednostek między plikami, niewidoczna w pojedynczym pliku, a widoczna dopiero przy prześledzeniu wartości przez dwa pliki. Dzięki temu procedura ma coś realnego do zrobienia w dalszej części tutorialu.

Zrób forka repo, aby podążać na własnej kopii. To repo do wyrzucenia, a wzorce przeniosą się na dowolne repozytorium, które wskażesz procedurze.

Wymagania wstępne, by nadążać

Potrzebujesz konta claude.ai w planie Pro, Max, Team lub Enterprise z włączonym Claude Code w przeglądarce. Procedury znajdziesz pod adresem claude.ai/code/routines.

Komenda /schedule uwierzytelnia się loginem do twojej subskrypcji claude.ai, a nie kluczem Anthropic API ani autoryzacją Bedrock, Vertex czy Foundry. Wymaga też aktualnego CLI, więc uruchom claude update, jeśli masz stare.

Są też dwa osobne wymagania dotyczące GitHuba. Po pierwsze, /web-setup przyznaje dostęp do klonowania, którego potrzebuje procedura według harmonogramu. Po drugie, osobno instalowana aplikacja Claude GitHub App umożliwia wyzwalacz GitHub omówiony później.

Budowanie procedur Claude Code z /schedule

Mając repo do wskazania, zbuduj procedurę z poziomu CLI. Uruchom /schedule w dowolnej sesji. Możesz od razu przekazać opis:

/schedule daily PR review at 9 am

Claude przechodzi wtedy przez te same pola, które zbiera formularz w sieci: nazwa, prompt, repozytorium, środowisko, konektory i harmonogram. Potwierdza harmonogram w twojej lokalnej strefie i konwertuje go za ciebie, więc 9:00 staje się właściwym wyrażeniem crona bez pisania go samodzielnie.

Jeśli twoje konto nie ma jeszcze połączenia z GitHubem, Claude poprosi o uruchomienie /web-setup. Uruchom je, a potem ponownie /schedule, aby kontynuować, gdzie przerwałeś.

Pisanie promptu, który działa bez ciebie

To prompt decyduje, czy procedura się powiedzie, czy nie.

Zwykła sesja to rozmowa, więc możesz korygować Claude na bieżąco. Procedura nie ma nikogo, kto ją poprawi. Startuje na zimno, działa do końca i nie może zadać pytania doprecyzowującego. Prompt musi nazwać zadanie, repozytorium i to, jak wygląda zakończone uruchomienie.

Porównaj te dwa. Pierwszy zostawia zbyt wiele niedopowiedziane:

Review the open PR.

Nie nazywa repo ani kryteriów recenzji, nie wskazuje miejsca na komentarze i nie ma definicji ukończenia. Zimny start nie wypełni tych luk. Drugi prompt odpowiada na wszystko:

Review the open pull request in pr-review-demo. The cartlib package works entirely in integer cents. Read the checkout flow and the values it pulls from config.py, and check that every amount stays in cents end to end. If any value is mixed in using the wrong unit, leave an inline comment on that line explaining the error and its effect on the customer's total. Then, post a summary comment stating whether the PR is safe to merge.

Ten prompt nazywa repo i stawia niezmiennik, którego kod musi przestrzegać: wszystkie kwoty w centach. Wskazuje dwa kluczowe pliki i definiuje „gotowe” jako komentarz inline plus werdykt o scaleniu. Dzięki temu uruchomienie ma cel, który może osiągnąć samodzielnie. Wklej go, gdy /schedule zapyta, co agent ma zrobić.

Domyślnie dołączone są wszystkie twoje konektory, więc świeża procedura ma już dostęp do wszystkiego, z czym łączy się twoje konto. Na razie to w porządku, a późniejsza sekcja zawęzi listę.

Po zakończeniu Claude zapisze procedurę i potwierdzi, że jest aktywna, wraz z repozytorium, harmonogramem, modelem i czasem następnego uruchomienia.

Procedura pojawia się także na liście pod adresem claude.ai/code/routines. Otwórz jej stronę szczegółów, by zobaczyć wszystko w jednym miejscu. To obejmuje status, repozytorium, harmonogram, konektory, pełen prompt oraz przycisk Uruchom teraz.

Kliknij Uruchom teraz, aby uruchomić natychmiast, zamiast czekać do 9:00.

Czytanie przebiegu

Uruchomienie startuje ze świeżego klonu twojego repozytorium, pobranego z domyślnej gałęzi. Wszystko, co zacommitowałeś, tam jest. Czegokolwiek skonfigurowałeś tylko lokalnie — nie ma, więc procedura widzi repo tak jak twoi współpracownicy.

Po zakończeniu lista uruchomień pokazuje zielony status. Zielony oznacza, że sesja uruchomiła się i zakończyła bez błędu infrastruktury. Nie znaczy jednak, że zadanie z promptu się powiodło. Za zielonym haczykiem mogą kryć się trzy rodzaje niepowodzeń, widoczne tylko w transkrypcie:

• Żądanie sieciowe zablokowane przez środowisko.
• Narzędzie konektora, którego procedura oczekiwała, ale nie mogła osiągnąć.
• Porażka na poziomie zadania, gdzie przebieg zakończył się czysto, ale zrobił coś niewłaściwego.

Dlatego otwórz uruchomienie, by je potwierdzić. Kliknij dowolne, aby czytać je jak pełną sesję: zobaczysz, co zrobił Claude, przejrzysz diff, otworzysz pull request albo poprowadzisz rozmowę dalej.

W repo demo transkrypt pokazuje błąd. Claude czyta checkout.py i znajduje, że kupon ma wartość 5 zamiast 500. Wyjaśnia, że stosuje to 5$ jako 5 centów, zawyżając klientowi rachunek o 4,95$ na zamówienie, oraz podaje jednolinijkową poprawkę. Następnie publikuje recenzję w PR przez konektor GitHub.

Zarządzanie procedurami Claude Code z CLI

Gdy procedura już istnieje, zarządzasz nią tą samą komendą. Uruchom /schedule list, by zobaczyć wszystkie, /schedule update, aby zmienić jedną, i /schedule run, by uruchomić natychmiast.

Gotowe presety harmonogramu to hourly, daily, weekdays i weekly. Dla własnego interwału, np. co 2 godziny albo pierwszego dnia miesiąca, najpierw wybierz najbliższy preset. Potem uruchom /schedule update, by ustawić wyrażenie crona bezpośrednio. Minimalny interwał to 1 godzina — szybsze są odrzucane.

Procedury wliczają się też w dzienny limit uruchomień twojego konta, a w trakcie research preview zdarzenia GitHub mają godzinowe limity. Zdarzenia powyżej limitu są porzucane, nie kolejkowane. Aktualne liczby zależą od planu i widnieją na claude.ai/code/routines.

CLI tworzy tylko procedury według harmonogramu. Aby dodać wyzwalacz GitHub lub API, edytuj procedurę w aplikacji webowej.

Wyzwalanie procedur Claude Code z GitHub i HTTP

Harmonogram uruchamia procedurę według zegara. Dwa inne wyzwalacze pozwalają, by ta sama procedura była wyzwalana przez GitHub lub twoje systemy. Procedura recenzji PR może działać co noc, reagować na każdy nowy PR i startować ze skryptu wdrożeniowego — jednocześnie.

Oba dodasz, edytując procedurę na claude.ai/code/routines.

Reaguj na pull requesty wyzwalaczem GitHub

Wyzwalacz GitHub wymaga zainstalowanej aplikacji Claude GitHub App w repozytorium, które chcesz subskrybować. Jeśli aplikacji brakuje, konfiguracja wyzwalacza poprosi o instalację. Zauważ, że /web-setup z wcześniejszego kroku nadaje tylko dostęp do klonowania. Nie instaluje aplikacji ani nie dostarcza webhooków, więc jej uruchomienie nie pokrywa tego etapu.

Gdy aplikacja jest zainstalowana, dodaj wyzwalacz i wybierz zdarzenie. Zdarzenia dzielą się na dwie kategorie: pull requesty i wydania, a w każdej wybierasz konkretną akcję. Interfejs pokazuje popularne jako presety, np. PR opened, PR merged i Release published, plus opcję Custom dla pozostałych.

Potem zawężasz filtrami. Dla pull requestów możesz filtrować po autorze, tytule, treści, gałęzi bazowej, gałęzi źródłowej, etykietach, is-draft i is-merged. Wszystkie warunki muszą pasować, by procedura się uruchomiła.

Operator matches regex testuje całe pole, nie podciąg. Aby dopasować dowolny tytuł zawierający hotfix, napisz .*hotfix.*. Zwykłe hotfix pasuje tylko do tytułu dokładnie takiego i żadnego innego.

Wyzwalacz GitHub ustawiony na nowe pull requesty, przefiltrowany do gałęzi main i konkretnego autora.

Dla repo demo ustaw zdarzenie na otwarcie pull requesta i pozostaw filtry otwarte. Teraz każdy nowy PR uruchamia przygotowaną wcześniej recenzję — bez nikogo w terminalu. Procedura śledzi jednostkę kuponu między plikami, zostawia komentarz inline przy błędzie i publikuje werdykt o scaleniu. 

Każde pasujące zdarzenie startuje własną sesję, więc dwa PR-y pod rząd wygenerują dwa niezależne uruchomienia.

Wyzwól procedurę przez HTTP

Wyzwalacz API pozwala twoim narzędziom uruchamiać procedurę. Wybierz API w selektorze wyzwalacza i kliknij Generate token. Token pokazuje się raz i nie można go później odzyskać, więc od razu zapisz go w magazynie sekretów twojego narzędzia alertującego.

Następnie wykonaj POST na endpoint wyzwalający procedurę z tokenem i treścią text:

curl -X POST https://api.anthropic.com/v1/claude_code/routines/$ROUTINE_ID/fire \
  -H "Authorization: Bearer $ROUTINE_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: experimental-cc-routine-2026-04-01" \
  -H "Content-Type: application/json" \
  -d '{"text": "Sentry alert SEN-4521 fired in prod. Stack trace attached."}'

Wartość text jest przekazywana jako dosłowny ciąg i nie jest parsowana, więc pisz zwykłą prozę zamiast JSON. Ustrukturyzowane wejście dociera jako surowy tekst, a procedura czyta je dosłownie. 

Nagłówek anthropic-beta jest wymagany, a API ma charakter eksperymentalny, więc sprawdź referencję API, zanim podepniesz je do CI. Stamtąd narzędzie monitorujące może wywołać ten endpoint przy alercie i sprawić, że procedura sama otworzy szkic PR-a z poprawką.

Określanie zakresu dostępu procedur Claude Code

Procedura działa samodzielnie, więc zanim wskażesz jej prawdziwe repo, ogranicz to, do czego ma dostęp. Dokumentacja ujmuje to w czterech kontrolkach:

• Kogo procedura „udaje”, przez twoją tożsamość GitHub i konektory.
• Do których gałęzi może wypychać zmiany.
• Jakich konektorów może używać.
• Do których hostów środowisko pozwala jej sięgać po sieci.

Ogranicz każdy z nich do tego, czego procedura faktycznie potrzebuje.

Tożsamość procedury

Tożsamość jest pierwsza, bo to ją zauważy współpracownik w dzielonym repo. Wszystko, co procedura robi przez twoją tożsamość GitHub lub konektory, wygląda jakbyś zrobił to ty. 

Commity i pull requesty mają twojego użytkownika GitHub, a wiadomości Slack i tickety w Linear używają twoich połączonych kont.  Współpracownicy widzą twoje imię przy tych commitach i PR-ach, więc nazywaj gałęzie i tytuły tak, by sygnalizować, że utworzyła je procedura.

Gałęzie, do których procedura może pushować

Gałęzie są kolejne. Uruchomienie to pełna sesja w chmurze bez monitów o uprawnienia, więc nigdy nie zatrzyma się, by zapytać przed edycją pliku czy otwarciem pull requesta. 

Barierą jest gałąź, do której może pisać. Domyślnie Claude pushuje tylko do gałęzi z prefiksem claude/, co trzyma go z dala od chronionych lub długowiecznych gałęzi jak main. 

Ustawienie per-repozytorium, Zezwól na nieograniczone pushowanie do gałęzi, usuwa to ograniczenie. Włącz je świadomie, tylko dla repo, które tego potrzebuje.

Konektory, z których procedura może korzystać

Konektory są z tej czwórki najbardziej ryzykowne. Domyślnie dołączone są wszystkie twoje konektory claude.ai, a Claude może użyć każdego narzędzia z dołączonego konektora, łącznie z zapisami, bez pytania w trakcie uruchomienia. 

Dlatego przytnij listę do tego, czego procedura potrzebuje. Procedurze recenzji PR wystarczy GitHub i niewiele więcej. Przypadkowy konektor e-mail czy kalendarza to dostęp, którego procedura nie wykorzysta, a wstrzyknięcie promptu ukryte w PR może obrócić ten dostęp przeciwko tobie.

Dostęp sieciowy

Dostęp sieciowy to ostatnia kontrolka. Środowisko Default używa zaufanego dostępu sieciowego, który sięga po wbudowaną listę dozwolonych rejestrów pakietów, API dostawców chmury, rejestrów kontenerów i popularnych domen developerskich, blokując resztę. 

Zablokowane żądanie kończy się 403 i x-deny-reason: host_not_allowed. Poszerzaj tylko, gdy procedura musi sięgnąć twoich usług. W przeciwnym razie to ciche niepowodzenie — widoczne w transkrypcie, a nie jako oczywisty błąd.

Pomysły na kolejne procedury Claude Code

Potrafisz zbudować, uruchomić i ograniczyć procedurę. Te przykłady z oficjalnej dokumentacji łączą zadanie z pasującym wyzwalaczem:

• Szyta na miarę recenzja kodu. Wyzwalacz GitHub na otwarcie PR. Stosuje checklistę recenzji twojego zespołu, zostawia komentarze inline dotyczące bezpieczeństwa, wydajności i stylu oraz dodaje podsumowanie. To demo uogólnione do twoich realnych standardów.
• Utrzymanie backlogu. Wyzwalacz harmonogramu, w każdy dzień roboczy wieczorem. Czyta zgłoszenia otwarte od ostatniego uruchomienia, nakłada etykiety, przypisuje właścicieli na podstawie obszaru kodu i publikuje podsumowanie na Slacku.
• Weryfikacja wdrożenia. Wyzwalacz API z potoku CD po każdym wdrożeniu produkcyjnym. Uruchamia smoke testy na nowej wersji, skanuje logi błędów pod kątem regresji i publikuje go/no-go na kanale wydaniowym.
• Dryf dokumentacji. Wyzwalacz harmonogramu, co tydzień. Skanuje zmerge’owane PR-y od ostatniego uruchomienia, oznacza dokumenty odnoszące się do zmienionych API i otwiera PR-y z aktualizacjami w repo dokumentacji.

Procedury pasują do pracy bez nadzoru, powtarzalnej i związanej z wyraźnym wynikiem. Jeśli potrafisz zapisać kryteria sukcesu w promptcie — tak jak w recenzji PR — zadanie się nadaje. Praca wymagająca bieżącej, ludzkiej oceny — nie.

Zakończenie

Procedury zmieniają to, jak spędzasz czas na powtarzalnej pracy. Zamiast uruchamiać każde zadanie w terminalu, piszesz je raz i przeglądasz to, co już się wykonało. Zbudowana recenzja PR uruchamia się przy zamkniętym laptopie, a ty czytasz werdykt, kiedy ci pasuje.

Aby pójść dalej z Claude Code, poniższe tutoriale dobrze się z tym łączą:

• Claude Code best practices — jak wycisnąć więcej z każdej sesji.
• Pisanie pliku CLAUDE.md, by dać twoim procedurom i sesjom wspólny kontekst.
• Spec-driven development — dla zadań, które warto opisać, zanim je zautomatyzujesz.
• Tryb Auto i kanały — by uruchamiać Claude Code z mniejszym nadzorem.