Oma Coordination
Plan krok po kroku podziału funkcji wielodomenowej między agentów PM, dev i QA
Działa po konfiguracji
Co robi ten skill
Przekształca żądanie funkcji wielodomenowej w ręczną sekwencję koordynacji wielu agentów: najpierw dekompozycja PM, zadania pogrupowane w poziomy priorytetów, agenci z tego samego poziomu uruchamiani równolegle w oddzielnych przestrzeniach roboczych, umowa API zamrożona przed rozpoczęciem prac frontend/mobile, a na końcu faza QA. Uruchamia się, gdy zadanie obejmuje backend, frontend, mobile i QA, a użytkownik chce mieć kontrolę krok po kroku nad kolejnością uruchamiania agentów, zamiast automatyzacji bezobsługowej. Emituje polecenia `oma agent:spawn` i nazywa pliki postępu do monitorowania; dla w pełni zautomatyzowanego wykonania odwołuje się do umiejętności oma-orchestrator.
Raport z testu
Sklonowano repozytorium i zainstalowano generated/agent-skills/oma-coordination w tymczasowym HOME — frontmatter sparsowany dokładnie do {name, description}, a jeden odwołany plik (resources/examples.md) pobrano z HTTP 200; brak curl|sh, base64 lub obsługi tajemnic w treści umiejętności. Uruchomiłem prawdziwe CLI w piaskownicy (`bunx oh-my-agent@latest agent:spawn --help` w tymczasowym HOME) i potwierdziłem, że wszystkie cztery flagi wymienione w SKILL.md — -m/--model, -w/--workspace, --isolation worktree, --read-only — istnieją zgodnie z dokumentacją; nie wykonałem faktycznego uruchomienia, ponieważ wymaga to uwierzytelnionego CLI dostawcy, a `oma` nie znajduje się w PATH po zwykłym skopiowaniu umiejętności. Porównanie bazowe vs umiejętność dla tego samego zadania (dodanie powiadomień w czasie rzeczywistym do aplikacji React web + Flutter mobile + FastAPI app): bazowe to 227 słów prozy z 0 wykonywalnymi poleceniami, bez kroku PM i z poradą „agree on the JSON shape early”; artefakt umiejętności to 780 słów z 8 konkretnymi wywołaniami `oma agent:spawn`, identyfikatorem sesji, dekompozycją PM produkującą 6 zadań w 4 poziomach priorytetów, twardą bramką P1→P2 blokującą web/mobile do momentu zamrożenia kontraktu backendu, `--isolation worktree` dla dwóch równoległych uruchomień, nazwanymi plikami progress-{agent}-{sessionId}.md do monitorowania i ostatnim uruchomieniem QA z --read-only. Obniżono ocenę wyjścia i dokumentacji, ponieważ mniej więcej jedna trzecia artefaktu umiejętności to boilerplate schematu (tabela prymitywów SSL, tabela zakresu zasobów), który nie zmienił żadnej decyzji, oraz ponieważ SKILL.md wymienia agentów siostrzanych i CLI jako „Dependencies” bez informowania, że zwykłe skopiowanie umiejętności pozostawia każde wyemitowane polecenie jako command-not-found.
Testowano: 2026-07-21 · Claude Code 2.x (agent harness)
Instalacja
git clone --depth 1 https://github.com/first-fluke/oh-my-agent.git /tmp/oma-coordination-src mkdir -p ~/.claude/skills cp -R /tmp/oma-coordination-src/generated/agent-skills/oma-coordination ~/.claude/skills/oma-coordination # The skill body emits `oma agent:spawn ...` commands. That CLI is NOT installed by the copy above. # To make the emitted commands runnable, install the harness in your project (needs bun + uv): # cd /path/to/your/project && bunx oh-my-agent@latest # Verified flags used by this skill: -m/--model <vendor>, -w/--workspace <path>, # --isolation worktree, --read-only (confirmed via `oma agent:spawn --help`). # The skill also assumes sibling agents exist: pm, backend, frontend, mobile, qa, orchestrator. # Get them all with: cp -R /tmp/oma-coordination-src/generated/agent-skills/oma-* ~/.claude/skills/ # Alt distribution (skills only, no CLI): apm install first-fluke/oh-my-agent
Komendy i przykładowe prompty
/oma-coordinationPlan krok po kroku podziału funkcji wielodomenowej między agentów PM, dev i QA
Skille uruchamiają się na zwykłe polecenia — bez komend do zapamiętania. Po instalacji aktywują go prompty takie jak te (po angielsku):
Coordinate the frontend and backend agents on this taskWalk me through assigning work to QA agentsHelp me manage this multi-agent project workflow