Claude Code je skvělý asistent. Napíšete prompt, dostanete odpověď. Řeknete mu „oprav tohle”, opraví to. Ale pořád je to ping-pong — vy hrajete, on reaguje.

Jenže co když chcete, aby pracoval sám? Ne jako chatbot, ale jako agent — ten, který se podívá co je potřeba, naplánuje řešení, implementuje ho a uklidí po sobě?

Přesně tohle jsem chtěl. A přesně tohle jsem si postavil. (Víc o mně a mé práci s AI.)

Co je /loop

/loop je vestavěný příkaz Claude Code. Syntaxe je triviální:

/loop [interval] prompt

Vezme váš prompt a spouští ho opakovaně v zadaném intervalu. Jednoduché příklady:

/loop 5m run npm test and fix any failures
/loop 10m check build status and report

Samo o sobě to není žádná revoluce. Opakované spouštění promptu je jen cyklus. Ale klíčový insight je tohle: prompt může být vlastní skill. A skill může být celý autonomní workflow.

/loop 20m /improve-gitlab

Tenhle jeden řádek spustí agenta, který poběží celou noc a ráno vám připraví hotové merge requesty ke code review.

Evoluce: Od features.md ke GitLab Issues

Neskočil jsem rovnou na GitLab. První verze byla mnohem jednodušší — a její omezení mě naučila, co vlastně potřebuju.

V1: /improve-jiridolejs

První iterace používala soubor features.md s checkboxy:

## Need Approval
- [ ] Přidat dark mode toggle
- [ ] Optimalizovat obrázky na homepage

## Approved
- [x] Opravit mobilní menu
- [x] Přidat structured data pro blog

Agent četl soubor, vzal první approved úkol a implementoval ho. Všechno šlo do jedné větve agent-features. Výzkum běžel přes Playwright persony — agent se „převlékl” za mobilního uživatele, accessibility auditora nebo SEO experta a procházel web.

Fungovalo to. Ale mělo to problémy:

Žádné code review. Změny šly rovnou do kódu bez lidského oka.
Jedna větev pro všechno. Merge konflikty. Nedalo se cherry-picknout jeden fix.
Těžko sledovatelné. Co agent udělal? Kdy? Proč? Odpovědi byly v git logu, ale to není workflow.

V2: /improve-gitlab

Druhá verze přesunula všechno do GitLab Issues. Každý úkol je issue s labely:

Needs Approval — agent navrhl, čeká na člověka
Planned — agent napsal plán implementace
Approved — člověk schválil, agent může implementovat

Každý issue dostane vlastní branch a merge request. Člověk reviewuje MR jako u jakéhokoliv jiného kódu.

Proč tohle funguje líp? Traceabilita. Vidím celou historii — od návrhu přes plán po implementaci. Paralelní práce. Každý issue je izolovaný. Review před mergem. Žádný kód nejde do produkce bez lidského oka.

Anatomie jednoho cyklu

Tohle je jádro celého systému. Každých 20 minut se spustí jeden cyklus /improve-gitlab. Tady je co se děje.

Pre-flight check

Než agent utratí jediný token na LLM, pošle jeden API call na GitLab. Zkontroluje tři věci:

Existují approved issues k implementaci?
Jsou tu issues čekající na schválení?
Přibyly nové lidské komentáře?

Pokud je odpověď na všechny tři „ne” — agent se zastaví. Žádná práce, žádné tokeny, žádné náklady. Tenhle pattern je kritický. Bez něj by agent každých 20 minut zbytečně procházel codebase a generoval plány na nic.

Housekeeping (úklid dočasných souborů, prořezávání větví) se spouští maximálně jednou za 24 hodin — není důvod uklízet při každém cyklu.

Bootstrap

Pokud pre-flight check najde práci, agent se připraví:

Přepne se na main a stáhne poslední změny
Načte agent-knowledge.md — perzistentní paměť mezi cykly
Ověří, že běží dev server, Playwright a glab (GitLab CLI)

Orient — rozhodovací engine

Agent se podívá na všechny issues a rozhodne, co má nejvyšší prioritu:

Approved — implementace schváleného úkolu (vždy první)
Plan Refinement — přepracování plánu na základě lidských komentářů
Planning — napsání implementačního plánu pro nový úkol
Housekeeping — údržba repozitáře
Research — průzkum webu a hledání zlepšení
Content Research — vyhodnocování témat pro nový obsah

Approved vždy první. Logika je jednoduchá: někdo si dal tu práci, schválil issue a napsal komentáře. To je signál, že na tom záleží.

Planning

Když agent najde issue bez plánu, analyzuje codebase a napíše implementační plán:

Které soubory bude měnit
Jaký přístup zvolí
Jaká jsou kritéria úspěchu

Plán připojí jako komentář k issue a posune label na Planned. Já si ho přečtu, případně okomentuju („tohle ne, radši takhle”), a když sedí, posunu na Approved.

Development

Tady se děje hlavní práce. Agent vezme approved issue a:

Vytvoří branch issue/<IID>-<slug>
Spustí implementační subagenta s jasným zadáním
Po implementaci spustí quality gate — build musí projít, Playwright pořídí screenshoty
Pushne branch, vytvoří merge request s „Closes #IID”

“
Ráno otevřete GitLab a máte čerstvé merge requesty. Váš job je reviewovat, ne programovat.
”

Quick-win issues (weight 1) jdou před komplexnějšími (weight 2, 3). Logika: malé změny rychle mergnu, velké si zaslouží víc pozornosti.

Research

Výzkumná fáze používá rotaci perspektiv. Agent se „převlékne” za různé persony:

First-time visitor — co vidím, je mi jasné, kam kliknout?
Mobilní uživatel — funguje layout, jsou tapnutelné cíle dostatečně velké?
Accessibility auditor — kontrast, alt texty, navigace klávesnicí?
SEO expert — meta tagy, structured data, rychlost?

Každá persona projede web přes Playwright (desktop i mobile viewporty). Nálezy se automaticky zapíšou jako nové issues s labelem Needs Approval. Já pak rozhodnu, co stojí za implementaci.

Housekeeping

Údržba, která by jinak zabrala půl hodiny týdně:

Smazání dočasných souborů a artefaktů
Prořezání merged a stale větví
Aktualizace knowledge base (co se naučil, co se změnilo)
Uzavření zastaralých issues

Content Research

Nejzajímavější fáze. Agent svolá virtuální C-level panel — CEO, CTO, CFO, CHRO a COO persony, které hodnotí potenciální témata pro blog. Každá persona posuzuje z perspektivy své role: CEO se ptá „je to strategické?”, CFO „jaký je ROI?”, CTO „je to technicky relevantní?”

Pokud 2+ persony schválí téma, agent vytvoří content issue. Vznikají tak témata, o kterých bych sám nepřemýšlel — protože vidím web hlavně očima vývojáře, ne očima HR ředitele.

Jak to vypadá v praxi

Můj typický den s /improve-gitlab:

Večer: Zkontroluju issues v GitLab. Schválím, co dává smysl. Okomentuju plány, kde něco nesedí. Spustím /loop 20m /improve-gitlab.

Ráno: Otevřu GitLab. Nové merge requesty, každý s popisem co se změnilo a proč. Projdu diff, otestuju na preview, mergnu. Hotovo.

Během dne: Přijde mi issue typu „Needs Approval” — agent při nočním researchi našel, že mobilní menu má problém s kontrastem. Podívám se na screenshot, schválím, a agent to opraví v dalším cyklu.

Moje role se změnila. Místo „programátor, který občas reviewuje” jsem „reviewer, který občas směruje”. A to je zásadní rozdíl v produktivitě.

Patterny, které můžete ukrást

Nemusíte stavět celý /improve-gitlab. /loop je užitečný i s jednoduchými prompty:

CI babysitter

/loop 5m check if build passed, if not analyze the failure and fix it

Agent sleduje CI pipeline a automaticky opravuje failing buildy.

Continuous testing

/loop 10m run the full test suite, fix any regressions

Nechte agenta hlídat testy, zatímco vy píšete nové features na jiné větvi.

Site audit

/loop 30m audit the site for accessibility issues and create gitlab issues

Pravidelný accessibility audit, který by jinak nikdo nedělal.

Doc freshness

/loop 1h compare documentation against actual code and flag drift

Dokumentace, která se nikdy nerozjede s realitou.

Kdy /loop NEpoužívat

/loop není zadarmo. Každý cyklus stojí API tokeny. Bez pre-flight checku utratíte za noc víc, než kolik stojí junior developer.

Nepoužívejte /loop když:

Úkol vyžaduje lidský úsudek v každém kroku. Pokud musíte schvalovat každou změnu, /loop vám nepomůže — jen přidá overhead.
Nemáte guardrails. Agent bez quality gate (build check, testy, screenshots) může generovat tech debt rychleji, než ho stihnete splácet.
Nemáte jasný scope. „Zlepši web” je příliš vágní. „Najdi a oprav accessibility issues na homepage” je správná granularita.

Pre-flight check pattern je proto tak důležitý. Levná kontrola na začátku ušetří drahý LLM cyklus, když není co dělat.

Závěr

/loop je most mezi asistentem a agentem. Samotný příkaz je jednoduchý — opakuje prompt v čase. Ale skutečné odemčení přichází, když ho zkombinujete s dobře navrženým skillem.

Můj /improve-gitlab je jeden příklad. Váš skill může řešit něco úplně jiného — monitoring, testování, generování reportů. Princip je stejný: definujte cyklus, přidejte pre-flight check, nastavte quality gate a nechte agenta pracovat.

Pokud vás zajímají další nástroje, které jsem pro Claude Code postavil, podívejte se na 5 nástrojů, které používám každý den.

A pokud chcete rychlý přehled příkazů a technik — stáhněte si AI tahák pro vývojáře. Zdarma.

/loop — Jak jsem z Claude Code udělal autonomního agenta