Lygiagretus darbas su Claude Code: worktree, Agents ir Workflows

Praktinė medžiaga apie darbą su agentais lygiagrečiai: Ailoot dokumentacija.

Šiame vadove sudėta praktinė patirtis ir apžvelgta, kur šie įrankiai praverčia. Keturi oficialūs Claude Code elementai, jų taikymo apžvalga ir ažiotažą slopinantis orientyras, padedantis nustatyti, kiek lygiagrečių agentų iš tiesų reikia vibe coder. Visi skaičiai ir citatos susieti su pirminiais Anthropic šaltiniais.

Kas yra multi-agent Claude Code aplinkoje ir kodėl tai nereiškia „1000 agentų“#

Multi-agent aplinka – tai tokia, kurioje užduotis padalijama į kelias nepriklausomas darbo kryptis: kiekviena atlieka savo dalį ir grąžina rezultatą. Paprasčiausias pavyzdys: viename Claude Code lange rašote frontendą, o kitame – backendą tame pačiame kompiuteryje, jiems naudojant bendrą git saugyklą. Tai jau multi-agent, nors žodis „orkestravimas“ čia būtų perteklinis.

Sudėtingesnė aplinka: vienoje Claude Code sesijoje paleidžiate penkis skirtingus vaidmenis turinčius subagentus (frontend kūrėją, backend kūrėją, saugumo tikrintoją, testuotoją ir dokumentuotoją), ir kiekvienas į bendrą pokalbį grąžina savo rezultato dalį. Tai tas pats multi-agent metodas, tik su vienu valdymo tašku.

Dar sudėtingiau: pasakote Claude: „kas savaitę atlik mano projekto visų 500 failų saugumo auditą“, ir jis parašo JavaScript orkestravimo scenarijų. Vykdymo aplinka fone paleidžia kelias dešimtis agentų, kiekvienas tikrina savo dalį, tada nepriklausomi agentai patikrina vieni kitų išvadas, o jūs gaunate vieną ataskaitą. Tai Dynamic Workflows, kuriuos Anthropic išleido 2026 m. gegužės 28 d. Išsamus funkcijos aprašymas pateiktas atskirame Dynamic Workflows vadove.

Šie trys scenarijai skiriasi ne agentų skaičiumi. Jie skiriasi tuo, kas nusprendžia, ką darys kitas agentas. Pirmame scenarijuje – jūs. Antrame – Claude, pokalbiui vykstant. Trečiame – Claude parašytas JavaScript scenarijus.

Beje, „1000 agentų“ yra tikras skaičius. Tai vieno Claude Code Dynamic Workflow viršutinė riba. Oficialioje Anthropic dokumentacijoje rašoma:

Kitaip tariant, tai techninė apsauga nuo nekontroliuojamo veikimo, o ne rekomenduojamas darbo krūvis. Praktiškai 95 % užduočių įvykdo 2–8 lygiagrečios darbo kryptys. Jei planuojate daugiau, pirmiausia paklauskite savęs, ką jos veiks.

4 Claude Code elementai: subagentai, skills, agent teams, workflows#

Claude Code turi keturis oficialius elementus, kuriais vieną užduotį galima paskirstyti keliems agentams. Anthropic juos palygino lentelėje Dynamic Workflows dokumentacijoje. Štai palyginimas paprastais žodžiais:

Kiekvienas iš šių elementų sprendžia kitokią problemą. Subagentai skirti 2–3 patikroms deleguoti atliekant vieną užduotį. Skills tinka, kai turite paruoštas instrukcijas, kuriomis Claude turėtų vadovautis (pavyzdžiui, „atlik PR peržiūrą naudodamasis šiuo kontroliniu sąrašu“). Agent teams tinka, kai kelios produkto dalys yra skirtinguose languose ir reikia vieno koordinatoriaus. Workflows tinka, kai užduotis per didelė vienam konteksto langui.

Apie subagentus išsamiai rašoma Claude Code Subagents 2026 vadove. Sprendimų medis, padedantis pasirinkti įrankį konkrečiai užduočiai, pateiktas Skills, Subagents, MCP, Plugins vadove. Šiame vadove aprašoma, kaip visa tai sujungti į multi-agent aplinką naudojant git worktree.

1 lygis: subagentai vienoje sesijoje – lengviausia pradėti#

Subagentas – paprasčiausias būdas padalyti užduotį. Pagrindinis pokalbis atlieka koordinatoriaus vaidmenį. Pagrindinis agentas darbo metu paleidžia laikinus darbuotojus – subagentus.

Konkretus aprašyto projekto pavyzdys. Parengus pirmąjį vadovo juodraštį, peržiūra organizuojama taip: Claude gauna užklausą „lygiagrečiai paleisk šešis subagentus: vienas ieško AI požymių, antras tikrina teisinę leksiką, trečias – balsą ir toną, ketvirtas tikrina faktus naudodamas WebFetch, penktas peržiūri SEO struktūrą, o šeštas tikrina nuorodų tikslumą“. Kiekvienas pateikia ataskaitą, po to pritaikomi pakeitimai.

Techniškai tai daroma naudojant failus .claude/agents/[subagent-name].md, kuriuose aprašomas vaidmuo ir įrankiai. Pagrindiniame pokalbyje kviečiama naudojant įrankį Agent. Claude nusprendžia, kada siųsti užklausą subagentui.

Kur tai veikia. Užduotys, kuriose reikia lygiagrečiai atlikti 3–7 vieno artefakto (kodo, teksto, dizaino) patikras. Kiekviena patikra nepriklausoma. Rezultatai telpa pagrindiniame konteksto lange.

Kur prasideda problemos. Jei turite 50+ failų arba kiekvienai patikrai reikia atskiro 50K tokenų konteksto, pagrindinis langas užsipildys. Jums reikia workflows arba agent teams.

Pagrindinė rizika. Kiekvienas subagentas tokenus naudoja atskirai. Jei 200 failų projekte paleidžiate šešis subagentus ir kiekvienas iš naujo perskaito visus 200 failų, mokate 6× daugiau. Todėl PRIVALOTE tiksliai nurodyti, kuriuos failus subagentas turi tikrinti. Išsamiau žr. Kur dingsta Claude Code tokenai.

2 lygis: git worktree – failų izoliavimas tarp lygiagrečių sesijų#

Kai subagentų nepakanka ir reikia, kad dvi pilnavertės Claude Code instancijos skirtinguose terminaluose dirbtų su ta pačia saugykla, iškyla klasikinė problema. Jos pradeda redaguoti tą patį failą; viena išsaugo pirmoji, o antroji jį perrašo. Praėjusią savaitę klientas paklausė palaikymo komandos: „5 vienu metu perrašo viena kitą“.

Sprendimas – git worktree. Tai integruota git funkcija, leidžianti turėti kelias tos pačios saugyklos darbines kopijas, kiekvieną atskiroje šakoje, bendrinant .git saugyklą. Vienas pradinis taškas, skirtingi katalogai diske, jų failai nesikerta. Pats mechanizmas išsamiai aprašytas Git worktree Claude Code aplinkoje vadove.

Komandos, skirtos penkių minučių sąrankai:

# From the main project directory
cd ~/projects/my-app

# Create a worktree for feature/auth
git worktree add ../my-app-auth feature/auth

# Create a worktree for feature/billing
git worktree add ../my-app-billing feature/billing

# Open two terminal windows
cd ~/projects/my-app-auth && claude   # first Claude Code
cd ~/projects/my-app-billing && claude # second Claude Code

Kiekviena kopija yra atskiroje šakoje. Kiekviena Claude Code instancija rašo į savo katalogą. Baigę darbą, iš jos šakos paleiskite git push, o tada – git worktree remove ../my-app-auth.

Ką reikia žinoti. Worktree nekopijuoja node_modules, .venv ar kitų .gitignore išvardytų failų. Jei reikia nepriklausomų priklausomybių (skirtingos bibliotekos versijos kiekvienoje šakoje), pridėję worktree, naujame kataloge atskirai paleiskite npm install.

Kiek worktrees vienam žmogui. Remiantis 2026 m. komandų apklausomis, praktinė riba vienam kūrėjui – 4–8 lygiagretūs worktrees. Ribojantis veiksnys yra ne Claude, o žmogaus gebėjimas peržiūrėti ir priimti rezultatus. Jei turite 10 worktrees, jie laukia peržiūros.

Aprašytoje praktikoje žmonės paprastai naudoja 2–3 lygiagrečius worktrees. Vieną pagrindinį worktree aktyviam darbui, vieną atsarginį skubiems pataisymams ir vieną eksperimentui (naujai funkcijai, dėl kurios abejojate). Daugiau nereikia.

3 lygis: agent teams – keli langai, vienas vadovaujantis agentas#

Agent teams yra palyginti naujas elementas. Idėja tokia: vienas vadovaujantis agentas bendrą planą laiko užduočių sąraše, o kelios lygiavertės sesijos atskiruose languose imasi vadovo paskirtų užduočių. Jos visos dirba toje pačioje failų sistemoje ir mato viena kitos tarpinius artefaktus.

Tai naudinga, kai užduotis suskaidoma į 3–5 dideles darbo kryptis, kurių kiekviena trunka valandas (didelio modulio perkėlimas, posistemės perrašymas, išsamus saugumo auditas). Tokiu atveju vadovaujantis agentas laiko planą viename bendrame užduočių faile absoliučiu keliu už worktree ribų. Vykdytojai tą kelią skaito ir praneša rezultatus; tik vadovas atnaujina būsenas, kad koordinavimo faile nekonkuruotų rašymai.

Techniškai agent teams – tai keli langai, veikiantys per git worktree ir turintys vieną bendrą planavimo tašką. Praktiškai 80 % žmonių agent teams valdo rankiniu būdu (kaip aprašyta pirmiau, naudojant worktree) ir nenaudoja jokios specialios „teams framework“. Tai visiškai priimtina.

Jei nesate tikri, ar jums apskritai reikia framework, beveik neabejotinai jo nereikia. Naudokite rankinį worktree ir vieną vadovaujantį agentą pagrindiniame kataloge.

4 lygis: Dynamic Workflows – Claude parašo JS orkestravimo scenarijų#

Visų trijų ankstesnių lygių planas laikomas pokalbyje: pagrindinio agento galvoje arba vadovaujančio agento užduočių sąraše. Dynamic Workflows perkelia planą į kodą. Claude užduotį pateikia kaip JavaScript scenarijų, vykdymo aplinka jį paleidžia izoliuotoje aplinkoje, tarpiniai rezultatai laikomi scenarijaus kintamuosiuose, o ne jūsų kontekste, ir sesija lieka interaktyvi, kol agentai dirba fone.

Konkretus pavyzdys iš oficialios dokumentacijos. Sakote:

ultracode: audit every API endpoint under src/routes/ for missing auth checks

Claude parašo maždaug tokios logikos JavaScript scenarijų: „paimk visus failus iš src/routes/, suskirstyk juos į grupes po 30 endpointų, kiekvienai grupei paleisk agentą, kad atliktų tą pačią patikrą, tada paleisk du nepriklausomus vertinimo agentus, kad patikrintų jų išvadas, ir parenk galutinę ataskaitą“. Scenarijus paleidžiamas. Gaunate rezultatų lentelę ir endpointų, kuriuos tikrai reikia peržiūrėti, sąrašą.

Kur tai praverčia.

• Viso projekto auditas, ieškant vienos problemos (saugumo, tipavimo, nebenaudojamų API).
• Didelės migracijos (500+ failų, kuriems taikoma bendra taisyklė).
• Tyrimų klausimai, kuriuos reikia patikrinti keliais nepriklausomais aspektais (Anthropic tai daro naudodama įtaisytąją /deep-research komandą).

Išsamų Dynamic Workflows aprašymą, jų ribas ir ultracode veikimą rasite atskirame Claude Code Dynamic Workflows vadove.

Kada NENAUDOTI. Kai užduotis linijinė ir aiški. Workflow nereikia tokiai užduočiai kaip „užbaik šį komponentą“. Workflow prasmingas tada, kai užduotis padalijama į 10+ nepriklausomų smulkesnių užduočių ir jas reikia kryžmiškai patikrinti.

Pagrindinis apribojimas. Workflow sunaudoja gerokai daugiau tokenų nei įprasta sesija. Anthropic savo dokumentacijoje rekomenduoja:

Kitaip tariant, pirmą workflow paleiskite viename kataloge, o ne visame projekte. Patikrinkite, kiek tai kainavo, tada nuspręskite, ar verta plėsti.

Outcomes: kriterijų sąrašas ir nepriklausomas tikrintojas#

Pavojingiausia dirbant su keliais agentais – pasitikėti jų rezultatais. Kiekvienas agentas pateikia tekstą, kuris atrodo kaip užbaigtas darbas. Citata atrodo teisinga, ataskaita išsami, migracija užbaigta. Kai dirba vienas agentas, galite viską patikrinti patys. Kai jų 10 – nebegalite, nes nespėsite.

Anthropic šią problemą sprendžia naudodama Outcomes – Managed Agents funkciją, išleistą 2026 m. gegužės 6 d. Idėja paprasta: sesijoje dalyvauja ANTRAS agentas (vertintojas), kurio vienintelė užduotis – patikrinti pirmojo agento darbą pagal griežtus kriterijus.

Kaip tai veikia techniškai. Parašote kriterijų sąrašą – markdown dokumentą, kuriame išsamiai išvardyta, ką reiškia „atlikta“, kokius šaltinius tikrinti ir kokias etiketes naudoti. Platforma automatiškai sukuria vertinimo agentą naujame konteksto lange. Jis gauna tik kriterijų sąrašą ir rezultatą, nieko daugiau. Po kiekvieno pagrindinio agento (rengėjo) bandymo vertintojas iš naujo perskaito rezultatą ir arba jį patvirtina, arba grąžina punktų sąrašą, kas dar nebaigta.

Citata iš Anthropic Cookbook:

Faktiniai poveikio skaičiai: integravus Outcomes į Claude Managed Agents, AI bendrovės Harvey užduočių atlikimo rodiklis išaugo maždaug 6×. Wisedocs (medicininė dokumentacija) dokumento peržiūrai skiriamas laikas sumažėjo 50 %. Šie skaičiai pateikti oficialiame funkcijos pranešime.

Kas svarbu vibe coder, o ne didelei įmonei. Outcomes yra metodas, o ne vien konkreti funkcija. Galite sukurti savo vertinimo agentą, aprašę tuos pačius kriterijus faile .claude/agents/grader.md ir paprašę pagrindinio agento paleisti jį po kiekvieno bandymo. Tai veikia su bet kokia multi-agent aplinka, ne tik su Managed Agents.

Pagrindinė kriterijų rašymo taisyklė iš cookbook – nurodyti tai, ką galima patikrinti, o ne bendrybę. Ne „patikrink, ar santraukoje aptariamas atsiskaitymas“, o „atidaryk santrauką, rask atsiskaitymo skyrių ir patvirtink, kad jame nurodyta suma $ arba pajamų procentinė dalis“. Pagal pirmą instrukciją vertintojas gali peržvelgti tekstą ir pažymėti langelį. Antroji priverčia atidaryti dokumentą ir rasti konkretų skaičių.

Antipavyzdys: „50 agentų daro nesąmones“#

Tai pagrindinis multi-agent antipavyzdys. Kažkas sužino, kad Claude Code gali vienu metu paleisti 16 agentų, o Dynamic Workflows – 1000 per vieną paleidimą, todėl atsisėda ir juos paleidžia. Rezultatas: nulis. Tokenų sunaudojama 10× daugiau nei įprastoje sesijoje.

Paprastas testas. Paimkite popieriaus lapą ir kiekvienam agentui nupieškite langelį. Įrašykite į kiekvieną:

1. Ką tiksliai jis daro (vienu sakiniu).
2. Kuriuos failus jis paliečia.
3. Ką grąžina.
4. Kas tai patikrina.

Jei negalite per 30 sekundžių atsakyti bent į vieną iš šių klausimų, tokio agento neturėtumėte turėti. Ši taisyklė tinka visiems lygiams: subagentams, agent teams ir Dynamic Workflows.

Antras antipavyzdys – lygiagrečiai vykdyti darbus, kurie turėtų būti atliekami nuosekliai. Jei frontendui pirmiausia reikia backendo, nes jis skaito API schemą, nepaleiskite jų lygiagrečiai. Pirmiausia atlikite backendą, tada frontendą. Lygiagrečiai galima vykdyti tik nepriklausomas užduotis.

Trečias antipavyzdys – multi-agent naudojimas vien dėl greičio. Tai veikia tik iki tam tikros ribos. Padalijus užduotį į keturias nepriklausomas darbo kryptis, jos bus atliktos maždaug per tiek laiko, kiek užtruktų viena kryptis (pridėjus minimalią koordinavimo sąnaudą). Tačiau jei viename kompiuteryje veikia 50 krypčių, kiekviena veiks lėčiau, nes jos dalijasi CPU. Praktinė nešiojamojo kompiuterio riba – 4–6 vienu metu veikiančios Claude Code instancijos; viršijus ją prasideda našumo ribojimas.

Kiek tai kainuoja ir kaip neišeikvoti savo limitų?#

2026 m. gegužę–birželį pramonė susidūrė su tikrove, kad programavimas naudojant AI kainuoja daugiau nei tikėtasi.

Viena įprasta Claude Code pokalbio sesija kainuoja palyginti nedaug. Įjunkite Dynamic Workflows visam repozitoriumui ir gausite 20× didesnę sąskaitą. Iš oficialios Anthropic dokumentacijos:

Ką daryti praktiškai. Taupymo taisyklės, paremtos aprašyta patirtimi.

1. Tiksliai nurodykite kiekvieno agento failus. Ne „peržvelk projektą ir rask problemas“, o „peržiūrėk src/auth/*.ts ir patikrink, ar kiekviena funkcija tikrina userId“. Antroji užklausa pateiks būtent tą darbą, už kurį mokate.

2. Workflow visada pirmiausia išbandykite viename kataloge. Ne visame src/. Pradėkite nuo src/auth/. Jei rezultatai patinka ir suprantate kainą, išplėskite taikymą.

3. Pagal numatytuosius nustatymus naudokite /effort high, o ultracode – tik sąmoningai. /effort ultracode reiškia xhigh ir automatinį orkestravimą. Tai labai brangu. Naudokite, kai užduočiai tikrai reikia kelių lygiagrečių darbo krypčių.

4. Kur galite, perjunkite subagentus į mažesnį modelį. Jei šeši subagentai peržiūri vieną vadovą, nei QA agentui, ieškančiam AI požymių, nei nuorodų tikrintojui nereikia Opus. Pakaks Sonnet. Taip naudojimas sumažėja 3–5×.

Išsamesnė tokenų taupymo apžvalga pateikta Kur dingsta Claude Code tokenai vadove ir Kaip neišeikvoti Claude Code limitų vadove.

Nuo ko pradėti šiandien: 30 minučių kontrolinis sąrašas#

1. Atnaujinkite Claude Code į v2.1.154+

   Tai minimali versija, palaikanti Dynamic Workflows. Terminale paleiskite claude update.

2. Įjunkite Dynamic Workflows skiltyje /config

   Pro plane jie išjungti pagal numatytuosius nustatymus. Atidarykite /config, raskite eilutę „Dynamic workflows“ ir įjunkite. Max, Team ir Enterprise planuose jie jau įjungti.

3. Sukurkite pirmąjį worktree

   Pagrindiniame projekto kataloge paleiskite git worktree add ../<project>-experiment <branch>. Atidarykite antrą terminalo langą šiame kataloge. Paleiskite claude.

4. Pridėkite bendrą užduočių sąrašą

Naudokite vieną absoliutų kelią už visų worktree ribų. Kiekviename worktree esantis tasks.md yra atskiras failas ir automatiškai nesinchronizuoja. Tik vadovaujanti sesija turi jį rašyti; vykdytojai skaito bendrą sąrašą ir praneša rezultatus.

Koordinavimo katalogą ir sąrašą sukurkite vieną kartą:

```bash
mkdir -p "$HOME/projects/my-app-coordination"
printf '%s\n' '# Tasks' '- Auth: assigned to the auth worktree' '- Billing: assigned to the billing worktree' > "$HOME/projects/my-app-coordination/tasks.md"
```

Pirmame terminale:

```bash
cd "$HOME/projects/my-app-auth"
printf 'Shared task list: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
claude
```

Antrame terminale:

```bash
cd "$HOME/projects/my-app-billing"
printf 'Shared task list: %s\n' "$HOME/projects/my-app-coordination/tasks.md"
claude
```

Abiejose sesijose agentui pateikite **tą patį pirmiau išvestą išskleistą absoliutų kelią**: „Perskaityk šį bendrą užduočių sąrašą. Dirbk tik su savo paskirta užduotimi ir failais. Sąrašo neredaguok; apie užbaigimą ir kliūtis pranešk vadovui, kuris valdo atnaujinimus.“ Prieš darbą patvirtinkite, kad abu agentai gali skaityti būtent tą failą; leidimo klausimą reikia išspręsti tam keliui. Sąrašas koordinuoja būseną, o kodo pakeitimai vis tiek lieka atskiruose worktree.

5. Taip dirbkite savaitę

   Neskubėkite diegti GUI apvalkalo. Savaitę dirbkite rankiniu būdu su dviem worktrees. Pamatysite, ko trūksta; tada pasirinkite įrankį konkrečiai problemai spręsti.

6. Tik tada įjunkite `/effort ultracode`

   Pasirinkite vieną užduotį, pavyzdžiui, „rask visus API endpointus be auth patikrų src/routes/“. Įjunkite /effort ultracode. Pažiūrėkite, kokį workflow Claude parašo, kiek jis kainuoja ir kokį rezultatą pateikia. Tai bus jūsų pirmasis Dynamic Workflow.

Kas toliau: atmintis tarp sesijų, Code Review, Multi-Agent v2#

Kas pasirodė 2026 m. gegužę–birželį ir kur link juda multi-agent Claude Code aplinkoje.

Managed Agents su Dreaming. Išleista 2026 m. gegužės 6 d. renginyje Code with Claude. Suplanuotas procesas, kuris tarp sesijų skaito ankstesnius agento transkriptus, aptinka pasikartojančius šablonus ir atnaujina jo atmintį. Būtent po Dreaming AI bendrovės Harvey užduočių atlikimas išaugo šešis kartus. Funkcija vis dar yra tyrimų peržiūros stadijoje.

Outcomes kaip Managed Agents funkcija. Aprašyta pirmiau. Prieinama per Claude Agent SDK, bet ne tiesiogiai Claude Code CLI. Tą patį metodą galite jau dabar taikyti rankiniu būdu, naudodami vertinantį subagentą.

Multi-Agent Orchestration v2 Claude Agent SDK. Vadovaujantis agentas pats deleguoja užduotis subagentams, naudodamas bendrą failų sistemą. Tai žingsnis nuo „rankiniu būdu paleisk N subagentų“ prie „aprašyk užduotį, o vadovas pats nuspręs, kam ir ką deleguoti“. Jei tik mokotės naudoti subagentus, dėl v2 dar nesijaudinkite. Išmokite klasikinio modelio – „vienas pagrindinis agentas + 3–5 skirtingų vaidmenų subagentai“ – o prie v2 pereikite natūraliai po 3–6 mėnesių.

Code Review, atliekamas agentų komandos. Anthropic renginyje Code with Claude paskelbė apie automatinę kodo peržiūrą, kai atidaromas PR. AI agentų komanda lygiagrečiai tikrina diff, ieško klaidų, tarpusavyje patikrina išvadas ir surikiuoja jas pagal rimtumą. Prieinama Team ir Enterprise planuose, bet dar ne Pro.

Plugin Marketplace. Paleista 2026 m. gegužės 23 d. versijose v2.1.128-136. Kai kurie marketplace įskiepiai yra paruoštos multi-agent aplinkos (parallel-review, security-audit, migration-helper). Juos galite įdiegti naudodami /plugin install <name>@claude-plugins-official ir peržiūrėti, kaip jie sukurti – tai geras būdas išmokti rašyti savus.

Multi-agent Claude Code aplinkoje vis dar yra skirtingos brandos stadijos elementų rinkinys. Subagentai ir git worktree yra stabilūs, patikrinti ir veikia visur. Agent teams veikia pusiau automatiškai, pusiau rankiniu būdu. Dynamic Workflows yra tyrimų peržiūros stadijoje ir sparčiai keičiasi. Managed Agents v2 skirti tik įmonėms. Tai reiškia, kad per ateinančius metus optimali vibe coder aplinka bus ne naujausia versija, o minimali sąranka, kurios reikia konkrečiai užduočiai. Mėnesiui aktyvaus darbo pakanka dviejų worktrees ir vieno vertinančio subagento. Sudėtinginkite aplinką tik tada, kai pajusite, kad jos riboja.

Veikianti vibe coding aplinka#

Praktinė medžiaga: Ailoot dokumentacija.

Daugiau medžiagos ir įrankių: Ailoot.