W poprzednim poście opisywałem komendy devopsowe: wieloagentową diagnostykę, pipeline’y wdrożeń, runbooki dla konkretnych środowisk. Poważne rzeczy. Wspomniałem wtedy, że kategoria Toggl jest “zupełnie inna w charakterze” i że niektóre komendy są “prawie żenująco proste”.

To była szczera zapowiedź. Oto one.

Dlaczego w ogóle owijać API do śledzenia czasu

Śledzę czas w Toggl. To nawyk z projektów klientskich, gdzie liczyły się godziny do zafakturowania, i zachowałem go nawet przy wewnętrznych projektach, bo pokazuje mi, gdzie naprawdę idą dni, w odróżnieniu od tego, gdzie myślę, że idą. Odpowiedź jest zwykle niewygodna.

Problem z webowym UI Toggl to kolejna zakładka. Siedzisz głęboko w sesji debugowania, naprawiasz problem, alt-tab do przeglądarki, klikasz stop, startujesz nowy timer, wpisujesz opis, wracasz. Przerwa jest mała i nawyk i tak pęka.

Alternatywa to API. Toggl ma przyzwoite REST API. Wszystko, co robię w UI, mogę zrobić przez curl. Więc wrzuciłem wywołania curl do plików z komendami.

Ograniczenie narzędzi w frontmatter ma tu znaczenie (jak działa frontmatter opisałem w poście o własnych komendach):

1
2
3
4

---
allowed-tools: Bash(curl:*)
description: Start a Toggl timer
---

Zablokowanie komendy wyłącznie do curl oznacza, że Claude nie pójdzie zrobić czegoś niespodziewanego z szerszym zestawem narzędzi. To ograniczenie, które jednocześnie służy jako dokumentacja: ta komenda robi jedną rzecz, jednym mechanizmem.

Te proste

Pięć z ośmiu komend to jedno wywołanie API opakowane w instrukcje. Obiecałem, że będą prawie żenujące, więc oto są.

/toggl:current pyta API Toggl o aktywny timer i pokazuje opis oraz czas, który upłynął. To tyle.

/toggl:stop pobiera ID bieżącego timera, wywołuje endpoint stop, pokazuje ile czasu minęło.

/toggl:start [opis] startuje nowy wpis z tekstem, który podasz. Payload API wygląda tak:

1
2
3
4
5
6

{
  "description": "Debugowanie modułu autentykacji",
  "duration": -1,
  "start": "2026-03-05T16:00:00Z",
  "workspace_id": 12345678
}

duration: -1 to sposób Toggl na powiedzenie “nadal trwa”. Skończony wpis ma dodatnią liczbę całkowitą. Komendy to obsługują, żebym nie musiał tego pamiętać.

/toggl:update [nowy opis] zmienia opis aktywnego timera. Przydatne, gdy wystartowałeś timer jako “patrzę na tę rzecz” i zadanie stało się czymś konkretnym.

/toggl:describe [id_wpisu] [opis] aktualizuje poprzedni wpis. ID dostajesz z /toggl:list.

Te pięć to cienkie nakładki. Oszczędzają mi alt-tab i zmianę kontekstu w przeglądarce. Nie wiele więcej.

Te, które coś robią

/toggl:setup to bootstrapper konfiguracji. Prosi o token API, uderza w GET /me żeby go zwalidować, wyciąga workspace ID z odpowiedzi i zapisuje obydwa do ~/.toggl_config. Każda inna komenda czyta stamtąd.

To dwa wywołania API i trochę pisania do pliku, ale uruchamia się tylko raz. Po setup wszystko po prostu działa.

/toggl:list [dni] i /toggl:summary [dni] to miejsca, gdzie robi się odrobinę ciekawiej.

list pobiera wszystkie wpisy z ostatnich N dni (domyślnie 7) i formatuje je jako tabelę: ID, opis, czas trwania, czas startu. Wyświetlanie czasu trwania obsługuje przypadek duration: -1 i pokazuje “Running” zamiast ujemnej liczby. Drobiazg, ale surowa wartość z API jest bezużyteczna jako output.

summary robi ten sam fetch, ale agreguje: łączny śledzony czas, podział per opis, jeśli kilka razy uruchamiałeś ten sam typ wpisu. Uruchomienie /toggl:summary 30 przed wystawieniem faktury to część mojej rutyny na koniec miesiąca. Mówi mi, czy naleciałem wystarczająco godzin i do których zadań poszły.

Gdzie widać różnicę

Komendy devopsowe mają 150 linii. Komendy Toggl średnio 15. Devopsowe koordynują wiele agentów, parsują złożony output i mają bramy potwierdzenia przed każdą destruktywną akcją. Togglowe wywołują jeden endpoint API i formatują odpowiedź.

Różnica w złożoności wynika po prostu z domeny. API Toggl jest czyste, wybaczające, a operacje z natury mało ryzykowne. Nie da się niczego zepsuć. Start timera nie wymaga potwierdzenia. Stop nie potrzebuje pre-flight check.

Komendy devopsowe zastąpiły dokumenty. Komendy Toggl zastąpiły zakładkę w przeglądarce. Obie warto mieć, ale rozwiązują różne problemy. Togglowe nie robią wrażenia. Po prostu usuwają tarcie.

Używam /toggl:start pewnie piętnaście razy dziennie. Nie myślę o tym. To jest cel.

Wzorzec konfiguracji

Jedna rzecz, którą setup Toggl wprowadził i którą od tamtej pory stosowałem gdzie indziej: zapisywanie konfiguracji do pliku w katalogu domowym zamiast pytania o dane uwierzytelniające za każdym razem.

1
2
3

~/.toggl_config:
TOGGL_API_TOKEN="twój_token"
TOGGL_WORKSPACE_ID="12345678"

Każda komenda Toggl czyta ten plik na starcie. Jeśli go nie ma, komunikat błędu mówi żeby uruchomić /toggl:setup. To prosta zależność, która działa bez żadnego stanu w samym Claude Code.

Alternatywa to hardkodowanie poświadczeń w plikach komend, co jest oczywiście złe, albo pytanie użytkownika za każdym razem, co neguje sens. Plik konfiguracyjny w katalogu domowym to nudna, właściwa odpowiedź.

Szczera wersja

Mógłbym udawać, że te komendy są częścią jakiegoś wielkiego zunifikowanego workflow. Nie są. To osiem małych plików, które sprawiają, że wywołanie REST API jest odrobinę wygodniejsze niż otwieranie zakładki w przeglądarce.

To, co naprawdę jest użyteczne, to posiadanie ich w tym samym interfejsie co wszystko inne. O to właśnie chodziło w przeglądzie setupu: wszystko żyje w jednym miejscu. Kiedy jestem w sesji Claude Code i debuguję coś, mogę /toggl:start Debugowanie problemu z auth bez wychodzenia z terminala, naprawić problem i /toggl:stop kiedy skończę. Kontekst zostaje w jednym miejscu.

I tyle. Żadnej wieloagentowej orkiestracji. Żadnej strategii rozumowania. Tylko wywołania curl w plikach markdown.

Dalej

Komendy content to te, z których korzystam najczęściej poza pracą devopsową: /humanize, /translate, /extract-wisdom, /youtube-summary. Tam dzieje się więcej niż w Toggl. Niektóre używają strategii rozumowania wprost, jedna uruchamia podagenty żeby utrzymać czysty główny kontekst. Warto osobnego posta.