oma-coordination
Skill223 starsChanged 28 days agoMITView on GitHub
Coordinate assigned specialist tasks and handoffs manually. Use when supervising a multi-agent project step by step.
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 10 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 59
FINALIZE: Run QA review and coordinate remediation.
- Distinctive: line 62
If task is simple, route to one specialist.
- Distinctive: line 63
If user wants automated execution, use orchestrator.
- Distinctive: line 64
If QA reports a blocking defect or required verification gap, route the affected work to the responsible agent within the existing recovery …
- Distinctive: line 67
If contracts diverge, pause downstream frontend/mobile work until backend/API contract is reconciled.
- Distinctive: line 68
If agent workspaces conflict, split ownership boundaries.
- Distinctive: line 69
If progress stalls, inspect progress files and reissue focused instructions.
- Very specific: line 101
When native runtime dispatch is available (per-agent target vendor equals the current runtime vendor), prefer the runtime's native subagent …
- Very specific: line 128
Follow ../_shared/core/code-intelligence.md: discover configured tools, do not auto-install or track, and use native search only for paths …
- Distinctive: line 142
If the target vendor equals the current runtime vendor and a native subagent path exists, use native dispatch
- Very specific: line 155
Read injected run artifacts and receipts.
- Distinctive: line 156
Verify API contracts align between agents
- Distinctive: line 157
Ensure shared data models are consistent
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Multi-Agent Workflow Guide
Scheduling
Goal
Guide manual multi-agent coordination for complex work that spans PM, frontend, backend, mobile, and QA responsibilities.
Intent signature
- User wants step-by-step coordination, manual agent spawning, or multi-domain work planning without full automation.
- Task spans multiple specialist agents and requires contract alignment.
When to use
- Complex feature spanning multiple domains (full-stack, mobile)
- Coordination needed between frontend, backend, mobile, and QA
- User wants step-by-step guidance for multi-agent coordination
When NOT to use
- Simple single-domain task -> use the specific agent directly
- User wants automated execution -> use orchestrator
- Quick bug fixes or minor changes
Expected inputs
- Complex feature or project goal
- Required domains and priority tiers
- Workspace/session constraints and API/data contract needs
Expected outputs
- Manual coordination sequence
- PM task decomposition, agent spawn order, monitoring guidance, and QA review step
- API/data contract alignment checkpoints
Dependencies
- PM, frontend, backend, mobile, QA, and orchestrator skills
- CLI
oma agent spawnand progress/result memory conventions
Control-flow features
- Branches by task complexity, priority tiers, dependency ordering, and whether automation is desired
- Spawns independent same-priority tasks in parallel when appropriate
- Monitors progress files and contract alignment
Structural Flow
Entry
- Confirm the task is complex enough for multi-agent coordination.
- Reuse a current plan and handoff state; use PM when task decomposition or contract changes are needed.
- Identify priority tiers and shared contracts.
Scenes
- PREPARE: Define session, domains, and task decomposition needs.
- ACT: Spawn agents by priority with separate workspaces.
- VERIFY: Monitor progress and API/data contract alignment.
- FINALIZE: Run QA review and coordinate remediation.
Transitions
- If task is simple, route to one specialist.
- If user wants automated execution, use orchestrator.
- If QA reports a blocking defect or required verification gap, route the affected work to the responsible agent within the existing recovery budget.
Failure and recovery
- If contracts diverge, pause downstream frontend/mobile work until backend/API contract is reconciled.
- If agent workspaces conflict, split ownership boundaries.
- If progress stalls, inspect progress files and reissue focused instructions.
Exit
- Success: specialist outputs are coordinated and QA-reviewed.
- Partial success: blocked agents, contract conflicts, or QA failures are explicit.
Logical Operations
Actions
| Action | SSL primitive | Evidence |
| Read request and domains | READ | User prompt and project context |
| Select agent plan | SELECT | PM decomposition and priority tiers |
| Spawn agents | CALL_TOOL | oma agent spawn |
| Monitor progress | READ | injected task/run-scoped progress, claims, and receipts |
| Validate contracts | VALIDATE | API/data model alignment |
| Notify coordination status | NOTIFY | Final coordination summary |
Tools and instruments
oma agent spawn, PM/frontend/backend/mobile/QA agents- Memory/progress/result files
- Configured code intelligence, with native fallback per
../_shared/core/code-intelligence.md
Canonical command path
# If planning is required, dispatch the declared PM task first; otherwise reuse the current plan.
oma agent spawn pm <pm-prompt-file> <session-id> --task-id <plan.pm_task.id> -w ./pm
oma agent spawn backend <backend-prompt-file> <session-id> --task-id <plan.backend_task.id> -w ./backend &
oma agent spawn frontend <frontend-prompt-file> <session-id> --task-id <plan.frontend_task.id> -w ./frontend &
waitWhen native runtime dispatch is available (per-agent target vendor equals the current runtime vendor), prefer the runtime's native subagent path and use oma agent spawn as the cross-vendor fallback — same resolution rule as oma-orchestration.
Useful agent spawn options: --vendor <vendor> (CLI vendor override), --isolation worktree (git worktree per spawn, prevents file conflicts), --read-only (non-destructive tools only, e.g. for review/QA passes).
Resource scope
| Scope | Resource target |
LOCAL_FS | Progress/result files and workspaces |
PROCESS | Agent spawn commands |
MEMORY | Session state and task board |
CODEBASE | Shared contracts and implementation areas |
Preconditions
- Task requires multiple domains.
- A current plan identifies task ownership, acceptance checks, dependencies, and priority tiers.
Effects and side effects
- Spawns or guides multiple agents.
- Coordinates workspace ownership and QA feedback.
Guardrails
- Reuse a valid plan; call PM only when decomposition or contract changes are required
- Spawn independent tasks in parallel (same priority tier)
- Reuse or update contracts for changed API boundaries before dependent frontend/mobile work
- QA review is always the final step
- Assign separate workspaces to avoid file conflicts (or use
--isolation worktreefor a git worktree per spawn) - Follow
../_shared/core/code-intelligence.md: discover configured tools, do not auto-install or track, and use native search only for paths outside this project or ignored paths when unavailable or timed out - Resume from the current handoff state and execute applicable steps in dependency order; record why a branch is not applicable
Workflow
Step 1: Plan with PM Agent
Reuse an existing valid plan. Otherwise, PM analyzes requirements and creates the task breakdown, acceptance checks, contracts, and priorities. Preserve injected session/task/run IDs; do not regenerate a plan already frozen by dispatch.
Step 2: Spawn Agents by Priority
Resolve the dispatch path per agent, then spawn:
- Resolve the per-agent target vendor from oma-config.yaml (
agents:override, elsemodel_preset) - If the target vendor equals the current runtime vendor and a native subagent path exists, use native dispatch
- Otherwise use
oma agent spawnfor that agent - Spawn all same-priority tasks in parallel using background processes
# Example: spawn backend and frontend in parallel
oma agent spawn backend backend-prompt.md session-id --task-id plan.backend_task.id -w ./backend &
oma agent spawn frontend frontend-prompt.md session-id --task-id plan.frontend_task.id -w ./frontend &
waitStep 3: Monitor & Coordinate
- Read injected run artifacts and receipts. Human-readable progress/results use
{memoryConfig.basePath}/progress-{agentId}-{taskId}-{runId}-{sessionId}.mdand the correspondingresult-name; see../_shared/runtime/memory-protocol.md. Keep the structured claim path unchanged. - Verify API contracts align between agents
- Ensure shared data models are consistent
Step 4: QA Review
Review the coordinated deliverables with QA. Resolve blocking defects and required verification gaps through the responsible agents; rerun affected checks before finalizing.
Automated Alternative
For fully automated execution without manual spawning, use the orchestrator skill instead.
References
Other versions3 projects use a version of this.
Word for word · 2
- first-fluke/oh-my-ag★ 1.3k100% same
- first-fluke/oh-my-agent★ 1.3k100% same
Edited · 1
- deathrashed/agents★ 171% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository131 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .cursor/rules/backend.mdcCursor rule
- .cursor/rules/branching-strategy.mdcCursor rule
- .cursor/rules/build-guide.mdcCursor rule
- .cursor/rules/commit.mdcCursor rule
- .cursor/rules/database.mdcCursor rule
- .cursor/rules/debug.mdcCursor rule
- .cursor/rules/design.mdcCursor rule
- .cursor/rules/design-tokens-guide.mdcCursor rule
- .cursor/rules/dev-workflow.mdcCursor rule
- .cursor/rules/frontend.mdcCursor rule
- .cursor/rules/i18n-arb.mdcCursor rule
- .cursor/rules/i18n-guide.mdcCursor rule
- .cursor/rules/infrastructure.mdcCursor rule
- .cursor/rules/lint-format-guide.mdcCursor rule
- .cursor/rules/market.mdcCursor rule
- .cursor/rules/mobile.mdcCursor rule
- .cursor/rules/preferred-editing-tools.mdcCursor rule
- .cursor/rules/quality.mdcCursor rule
- .cursor/rules/test-guide.mdcCursor rule
- oma-academic-writingSkill
- oma-architectureSkill
- oma-backendSkill
- oma-brainstormSkill
- oma-dbSkill
- oma-debugSkill
- oma-deepsecSkill
- oma-designSkill
- oma-dev-workflowSkill
- oma-docsSkill
- oma-explanationSkill
- oma-frontendSkill
- oma-hwpSkill
- oma-imageSkill
- oma-marketSkill
- oma-mobileSkill
- oma-observabilitySkill
- oma-orchestrationSkill
- oma-pdfSkill
- oma-pmSkill
- oma-qaSkill
- oma-recapSkill
- oma-refactorSkill
- oma-scholarSkill
- oma-scmSkill
- oma-searchSkill
- oma-skill-creationSkill
- oma-slideSkill
- oma-tf-infraSkill
- oma-translationSkill
- oma-videoSkill
- oma-voiceSkill
- architectureSkill
- brainstormSkill
- commitSkill
- convertSkill
- coordinate-proSkill
- coordinateSkill
- debugSkill
- deepinitSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

