Cursor pro týmy: Composer 2.0 a cloud agenti v praxi

Každý týmový vývoj má své opakující se bolesti: někdo musí projít PR, opravit drobné bugy, aktualizovat dokumentaci nebo připravit novou funkci podle zadání. Cursor v roce 2026 tyhle úkoly přestává řešit jen jako lepší editor. Díky Composer 2.0 a cloud agentům se z něj stává vývojové centrum, kde AI dělá rutinu a ty se soustředíš na architekturu a rozhodnutí.

V tomto návodu ti ukážu tři konkrétní workflow, které v týmu nasadíš během jednoho dne. Nepůjde o teoretické sliby — každý krok lze spustit přímo v Cursoru.

01Co Cursor v roce 2026 umí navíc oproti klasickému IDE

Cursor už dávno není jen editor s autocomplete. Klíčové posuny, které mění týmovou dynamiku:

• Composer 2.0/2.5 — multi-file editor, který z jednoho promptu upraví frontend, backend i testy najednou.
• Cloud agenti a subagenti — dlouhotrvající úkoly běží na serveru, ne na tvém laptopu.
• /automate skill — vytvoříš automatizaci přirozeným jazykem, například pro Slack nebo GitHub.
• /review s Bugbotem — před pushnutím projde kód bezpečnostní a logickou kontrolou.
• /babysit pro PR — cloud agent iteruje na PRku, dokud není připraveno na merge.

Výsledek? Méně přepínání mezi okny, méně rutinních review a rychlejší dodání funkcí.

02Workflow 1: Zadání nové funkce z Jiry/GitHubu přímo do kódu

Nejčastější scénář: product manager ti hodí ticket s popisem funkce. Místo ručního rozepisování do souborů použij Composer.

Postup

1. Otevři Composer (Cmd/Ctrl + I) a vlož celé zadání z issue.
2. Přidej kontext: @docs/architektura.md, @tests/feature.test.ts, @package.json.
3. Zadej prompt: "Vytvoř login endpoint s JWT, přidej validaci emailu, napiš testy a aktualizuj OpenAPI dokumentaci."
4. Composer navrhne změny napříč soubory. Projdij je, uprav a potvrď.

Proč to zrychluje tým

• Jeden zdroj pravdy — zadání z issue jde přímo do kódu, nikdo nepřepisuje mezi kanály.
• Konzistentní struktura — Composer respektuje existující patterns v projektu.
• Méně chyb — testy se generují současně s implementací, ne až na konci.

Co dát do promptu, aby výsledek stál za to

Obecný prompt vrátí obecný kód. Pro týmové použití buď konkrétní:

Vytvoř login endpoint v /api/auth/login podle existující struktury v /api/users.
Použij JWT s expirací 24 hodin, validaci emailu přes zod schéma z @src/validators/.
Napiš unit testy pro service a e2e testy pro endpoint.
Aktualizuj OpenAPI dokumentaci v @docs/openapi.yml.
Nepoužívej externí knihovny, které už nejsou v package.json.

Čím víc kontextu dáš, tím méně času strávíš opravováním. Dobrý zvyk je také připojit příklady existujících endpointů, které se ti líbí — Composer pak kopíruje styl, který máš v týmu nastavený.

Tip: Ulož si často používané prompty jako .cursorrules soubor v repu. Tým tak bude mít společný styl generování kódu. Zároveň si vytvoř složku .cursor/prompts/ s připravenými šablonami pro opakující se úkoly — například "Vytvoř CRUD endpoint", "Přidej migraci a entitu" nebo "Napiš Cypress test pro novou stránku".

03Workflow 2: Cloud agenti běží na pozadí, zatímco ty děláš něco jiného

Dlouhé úkoly — refaktoring, aktualizace závislostí, příprava velkého PR — tradičně blokují tvůj editor. Cursor to řeší cloud agenty.

Jak to použít

1. V promptu napiš /in-cloud a zadej úkol.
2. Cursor vytvoří subagenta ve vlastní VM.
3. Agent pracuje na pozadí, ty mezitím řešíš jiný task.
4. Až skončí, dostaneš notifikaci s výsledkem a diffem.

Praktický příklad

Potřebuješ aktualizovat Next.js z 14 na 15 a opravit všechny breaking changes:

• Lokální řešení: hodiny práce, během kterých nemůžeš dělat nic jiného.
• Cloud agent: zadáš úkol, jdeš na schůzku, po návratu máš PR s opravenými importy a aktualizovanými testy.

Podobně funguje /babysit: hodíš na agenta otevřené PR, které potřebuje doladit podle komentářů reviewerů. Agent iteruje, dokud není PR připraveno k merge.

Kdy cloud agenty opravdu využít

Cloud agenti nejsou všelék. Nejlepší fungují na úkoly, které jsou:

• dlouhé — trvají desítky minut až hodiny,
• dobře specifikované — víš, jak má výsledek vypadat,
• bezpečné — pokud selžou, nic se nerozbije.

Typické případy: aktualizace závislostí, refaktoring starého modulu, generování dokumentace z kódu, migrace mezi frameworky nebo příprava boilerplate pro novou funkci. Naopak pro architektonická rozhodnutí, kde záleží na kontextu businessu, je lepší zůstat u lokálního rozhodování s kolegy.

Jak hlídat náklady a bezpečnost

Cloud agenti běží na infrastruktuře Cursoru, takže si dobře nastav:

• scope — omez agenta na konkrétní složky nebo soubory,
• oprávnění — nepouštěj agenty v repozitářích s citlivými daty, dokud si neověříš, jak se data zpracovávají,
• review — výsledek vždy projdi před merge, nespoléhej se na automatiku slepě.

Dobrý kompromis je používat cloud agenty jako "první nástřel", který pak člověk doladí. Ušetříš hodiny mechanické práce, ale zachováš kontrolu nad výsledkem.

04Workflow 3: Automatizace review a bezpečnostní kontroly

Code review je kritické, ale časově náročné. Cursor ho umí z velké části automatizovat.

/review před pushnutím

Před tím, než odešleš kód do repa, spusť:

/review

Bugbot projede změny a označí:

• potenciální bezpečnostní díry,
• logické chyby,
• nekonzistentní naming,
• chybějící testy.

Výstup vypadá jako komentáře od zkušeného kolegy. Ty je buď opravíš, nebo označíš jako irelevantní.

GitHub triggery

Cursor v roce 2026 podporuje GitHub triggery. Můžeš nastavit, že například:

• nový komentář v issue spustí agenta, který analyzuje požadavek,
• dokončený workflow run vyvolá review nového kódu,
• reakce na PR review comment aktivuje /babysit.

To znamená, že část týmové komunikace kolem kódu probíhá automaticky, bez nutnosti ručně přeposílat zadání.

Jak /review změní dynamiku v týmu

Když každý vývojář spustí /review před vlastním PR, seniorní členové týmu přestanou řešit formální chyby a mohou se soustředit na architekturu a business logiku. Review se tak posouvá z "našel jsi tu chybu" na "tady bych zvážil jiné řešení".

Doporučený postup pro zavedení do týmu:

1. Týden 1 — dobrovolné používání /review, sbíráme feedback.
2. Týden 2 — nastavíme /review jako doporučený krok v PR checklistu.
3. Týden 3 — pokud výsledky dávají smysl, stane se povinným před každým pushnutím.

Nechť si každý nastaví vlastní pravidla pro Bugbota podle stacku. Pro JavaScript/TypeScript projekty můžeš například zvýraznit nebezpečné eval, nekontrolované vstupy od uživatele nebo chybějící error handling. Pro Python zase SQL injection patterns nebo nevalidované serializace.

05Jak začít v týmu už dnes

Nasazení Cursoru v týmu neznamená přes noc změnit celý proces. Začni takhle:

1. Vyber jeden projekt — ideálně menší repo, kde si tým může funkce vyzkoušet.
2. Nastav .cursorrules — definuj coding style, konvence pro názvy a pravidla pro generování testů.
3. Zkus Composer na jednom ticketu — ideálně na funkci, která zasahuje do více souborů.
4. Otestuj /review na několika PR, než ho začneš používat jako povinný krok.
5. Až budete ready, zapni cloud agenty pro dlouhé úkoly a uvolni tak lokální stroje vývojářů.

06Co si z toho odnést

Cursor v roce 2026 není konkurentem vývojáře — je to nástroj, který odstraňuje tření v týmovém workflow. Composer 2.0 zrychluje implementaci, cloud agenti běží na pozadí a /review zlepšuje kvalitu kódu ještě před tím, než ho někdo uvidí.

Nejdůležitější je začít s jedním workflowem. Nečekej, že celý tým přejde na AI-driven vývoj za týden. Vyber si jeden proces, otestuj ho a postupně přidávej další. Za měsíc zjistíš, že se tým dostal dál s menším množstvím ruční práce.

A jaký první krok zkusíš ty? Composer na novou funkci, /review na existující PR, nebo rovnou cloud agenta na nějakou nudnou aktualizaci?