Oma Coordination
Piano passo-passo per suddividere una funzionalità multi-dominio tra agenti PM, dev e QA.
Richiede configurazione
Cosa fa
Trasforma una richiesta di funzionalità multi-dominio in una sequenza di coordinamento multi-agente manuale: prima la decomposizione PM, i task raggruppati in livelli di priorità, gli agenti dello stesso livello generati in parallelo in workspace separati, il contratto API congelato prima dell'inizio del lavoro frontend/mobile e un passaggio QA finale. Si attiva quando un task coinvolge backend, frontend, mobile e QA e l'utente desidera un controllo passo-passo sull'ordine di generazione degli agenti anziché un'automazione completamente automatica. Emette comandi `oma agent:spawn` e nomina i file di progresso da monitorare; per l'esecuzione completamente automatizzata si affida alla skill oma-orchestrator.
Rapporto di test
Clonato il repo e installato generated/agent-skills/oma-coordination in una HOME temporanea — frontmatter analizzato per {name, description} esatti, e l'unico file referenziato (resources/examples.md) ha restituito HTTP 200; nessun curl|sh, base64 o gestione di segreti nel corpo della skill. Ho eseguito la CLI reale in sandbox (`bunx oh-my-agent@latest agent:spawn --help` in una HOME temporanea) e ho confermato che i quattro flag citati in SKILL.md — -m/--model, -w/--workspace, --isolation worktree, --read-only — esistono tutti come documentato; non ho eseguito uno spawn effettivo, poiché ciò richiede una CLI di vendor autenticata, e `oma` non è nel PATH dopo una semplice copia della skill. Baseline vs skill sullo stesso task (aggiungere notifiche in tempo reale a un'app React web + Flutter mobile + FastAPI): la baseline era di 227 parole di prosa con 0 comandi eseguibili, nessun passo PM e "concordare la forma JSON in anticipo" come consiglio; l'artefatto della skill era di 780 parole con 8 invocazioni concrete `oma agent:spawn`, un ID di sessione, una decomposizione PM che produceva 6 task in 4 livelli di priorità, un gate P1→P2 rigido che blocca web/mobile fino a quando il contratto backend non è congelato, `--isolation worktree` sui due spawn paralleli, file progress-{agent}-{sessionId}.md nominati da monitorare e uno spawn QA --read-only per ultimo. Output e documentazione penalizzati perché circa un terzo dell'artefatto della skill è boilerplate di schema (tabella primitive SSL, tabella scope risorse) che non ha cambiato alcuna decisione, e perché SKILL.md elenca gli agenti 'sibling' e la CLI come "Dependencies" senza dire che una semplice copia della skill lascia ogni comando emesso come 'command-not-found'.
Testato il: 2026-07-21 · Claude Code 2.x (agent harness)
Installazione
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
Comandi e prompt di esempio
/oma-coordinationPiano passo-passo per suddividere una funzionalità multi-dominio tra agenti PM, dev e QA.
Gli skill si attivano con richieste in linguaggio naturale, senza comandi da ricordare. Dopo l'installazione, prompt come questi lo attivano (in inglese):
Coordinate the frontend and backend agents on this taskWalk me through assigning work to QA agentsHelp me manage this multi-agent project workflow