Blog
PLEN

claudeclaw + cron — Claude jako asystent który ma swój grafik

Claude Code potrafi pracować nie tylko gdy go odpalę. claudeclaw to mechanizm który zleca mu zadania na cron — codzienny briefing, przegląd PR-ów, audyt zależności. Pokazuję jak to działa u mnie.

·4 min read
#claude-code#cron#automatyzacja#self-hosted
claudeclaw + cron — Claude jako asystent który ma swój grafik

Domyślny model Claude Code to "ja siadam, ja pytam, agent odpowiada". claudeclaw odwraca tę zależność: agent ma swój kalendarz i sam mnie zaczepia gdy ma coś do powiedzenia. Mam u siebie cztery aktywne joby cron-owe i kilka one-shotów, pokażę jak to wygląda i czego się nauczyłem.

Co to claudeclaw

Plugin do Claude Code który dodaje:

  • daemon trzymający stan między sesjami
  • mechanizm definiowania jobów (cron expression + prompt + delivery)
  • integrację z Telegramem do dwustronnej komunikacji
  • heartbeat sprawdzający że demon żyje

Repozytorium konfiguracji u mnie:

~/.openclaw/cron/
├── jobs.json          # definicje jobów
└── runs/
    ├── morning.jsonl  # log uruchomień
    └── ...

Każdy job to obiekt JSON ze schematem:

{
  "id": "morning-briefing",
  "name": "Morning briefing",
  "agentId": "main",
  "enabled": true,
  "schedule": { "kind": "cron", "expr": "0 8 * * *", "tz": "Europe/Warsaw" },
  "payload": {
    "kind": "agentTurn",
    "message": "Sprawdź pogodę, kalendarz na dziś, status backupów, najnowsze maile (top 5). Krótkie podsumowanie.",
    "lightContext": true
  },
  "delivery": { "mode": "announce", "channel": "telegram", "to": "5094102576" }
}

Job 1: morning briefing

Codziennie 8:00. Agent sprawdza:

  • pogodę przez HA (czujnik na zewnątrz)
  • kalendarz Google (eventy dziś)
  • status backupów (Proxmox)
  • top 5 nieprzeczytanych maili

Wynik leci na Telegram jako jedna wiadomość ~150 słów. Brak filtrów, brak parsowania, model decyduje co jest istotne.

🌅 Dzień dobry. 8°C, mgliście do 11.
📅 Dzisiaj: 14:00 spotkanie #1, 17:00 trening.
💾 Backup VM proxmox: ✅ z 03:00.
📧 3 maile do uwagi: faktura X (deadline jutro), ...

To zastępuje rytuał "otwieram cztery aplikacje rano". Działa od 4 miesięcy, niezawodnie.

Job 2: code review po merge

Webhook z GitHuba odpala job z parametrem PR number. Agent:

  1. pobiera diff
  2. czyta CLAUDE.md projektu (konteksty stylu)
  3. uruchamia code-reviewer subagenta
  4. wysyła wynik na Telegram
{
  "id": "post-merge-review",
  "schedule": { "kind": "trigger", "via": "webhook" },
  "payload": {
    "kind": "agentTurn",
    "message": "Code review na PR ${PR_NUMBER} w ${REPO}. Skup się na: spójność z istniejącym stylem, security, brak silent failures."
  }
}

To nie zastępuje "prawdziwego" review (bot nie ma kontekstu intencji), ale łapie 1-2 niedociągnięcia per PR. Średnio.

Job 3: dependency audit

Tygodniowo, niedziela 22:00. Agent leci:

# Pseudokod tego co robi
for project in ~/projects/*; do
  cd "$project"
  npm audit --json
  pip-audit
done

Wynik: agregat CVE z severity HIGH/CRITICAL, posortowany po projekcie. Jeśli zero, krótka wiadomość "wszystko czyste". Jeśli coś, lista z linkami.

Często to false positive (pakiet z CVE używany tylko w devDeps). Ale czasami łapie realny problem zanim ja zauważę. Worth it.

Job 4: backup status

Codziennie, 6:00. Sprawdza:

  • czy snapshot Proxmox VM się wykonał
  • czy obsidian-livesync (CouchDB) jest aktualny
  • czy GitHub mirror działa

Output wysyła tylko gdy coś jest nie tak. To kluczowy szczegół: cisza znaczy "wszystko ok". Nie chcę 365 powiadomień rocznie z "backup OK".

Czego się nauczyłem

1. Light context to default. Każdy job startuje świeżą sesję bez historii. To upraszcza debugging (każdy run jest deterministyczny) i obniża koszt. Zostawiam pełny kontekst dla rzeczy które tego naprawdę wymagają (np. continuation).

2. Telegram > email do alertów. Email mam 200/dzień, Telegram od bota tylko od bota. Jak coś się tam pojawia, czytam.

3. Cron expression to nie wszystko. Mam też trigger-based joby (webhook GitHub, callback z systemd). claudeclaw obsługuje obie. Korzystam częściej z trigger niż z cron.

4. Failover na Telegram. Każdy job notyfikuje failure. Nie cichą śmiercią, tylko "job X padł, log w Y". Wcześniej miałem joby które miesiąc nie działały i nie wiedziałem.

Anti-patterny

Trzy rzeczy których wczesnie próbowałem i odrzuciłem:

1. "Inteligentne" interwały. "Uruchom job gdy CPU < 30%". Agent radzi sobie z modelem, nie z scheduling. Zostawiam to systemd timerom.

2. Jeden job, wiele odpowiedzialności. Miałem "monitoring-everything" który trwał 8 minut. Rozbiłem na 5 mniejszych, każdy < 90 sekund. Łatwiejsze do debugowania, każdy ma jasny owner.

3. Memory między runami. Próbowałem przekazywać stan przez plik. Skończyło się tym że agent go nie odczytywał konsekwentnie. Teraz każdy run jest stateless, jeśli potrzebuję ciągłości, używam db (sqlite) explicite.

Setup minimalny

Jeśli chcesz spróbować, najmniejszy sensowny setup:

# 1. Zainstaluj plugin
claude plugin install claudeclaw
 
# 2. Utwórz pierwszy job (morning ping)
claude jobs create \
  --name "morning-ping" \
  --cron "0 8 * * *" \
  --message "Powiedz dzień dobry. Sprawdź czy mam dziś coś w kalendarzu."
 
# 3. Sprawdź status
claude jobs list

Pierwszy job działa po jednej nocy. Jak Ci to wejdzie w nawyk, dodawaj kolejne.

claudeclaw to nie sci-fi ani autonomous agent. To zwykły cron z opakowaniem które gada do mnie po polsku. I to wystarcza żeby agent był pożyteczny gdy ja śpię.