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
resources/examples.md
- CLI
oma agent:spawn and 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.
- Start with PM task decomposition.
- 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 finds CRITICAL issues, re-spawn responsible agents.
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 |
progress-{agent}.md |
| 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
- Serena MCP for exploration and modification when used by specialists
Canonical command path
oma agent:spawn pm "<planning task>" <session-id> -w ./pm
oma agent:spawn backend "<backend task>" <session-id> -w ./backend &
oma agent:spawn frontend "<frontend task>" <session-id> -w ./frontend &
wait
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.
- PM decomposition can identify independent priority tiers.
Effects and side effects
- Spawns or guides multiple agents.
- Coordinates workspace ownership and QA feedback.
Guardrails
- Always start with PM Agent for task decomposition
- Spawn independent tasks in parallel (same priority tier)
- Define API contracts before frontend/mobile tasks
- QA review is always the final step
- Assign separate workspaces to avoid file conflicts
- Always use Serena MCP tools as the primary method for code exploration and modification
- Never skip steps in the workflow; follow each step sequentially without omission
Workflow
Step 1: Plan with PM Agent
PM Agent analyzes requirements, selects tech stack, creates task breakdown with priorities.
Step 2: Spawn Agents by Priority
Spawn agents via CLI:
- Use
oma agent:spawn for each task
- CLI selection follows
model_preset (and per-agent overrides) in oma-config.yaml
- Spawn all same-priority tasks in parallel using background processes
# Example: spawn backend and frontend in parallel
oma agent:spawn backend "task description" session-id -w ./backend &
oma agent:spawn frontend "task description" session-id -w ./frontend &
wait
Step 3: Monitor & Coordinate
- Use memory read tool to poll
progress-{agent}.md files
- Verify API contracts align between agents
- Ensure shared data models are consistent
Step 4: QA Review
Spawn QA Agent last to review all deliverables. Address CRITICAL issues by re-spawning agents.
Automated Alternative
For fully automated execution without manual spawning, use the orchestrator skill instead.
References
- Workflow examples:
resources/examples.md
1---2name: oma-coordination3description: Guide for coordinating PM, Frontend, Backend, Mobile, and QA agents on complex projects via CLI. Use for manual step-by-step coordination and workflow guidance.4---5
6# Multi-Agent Workflow Guide
7
8## Scheduling
9
10### Goal
11Guide manual multi-agent coordination for complex work that spans PM, frontend, backend, mobile, and QA responsibilities.
12
13### Intent signature
14- User wants step-by-step coordination, manual agent spawning, or multi-domain work planning without full automation.
15- Task spans multiple specialist agents and requires contract alignment.
16
17### When to use
18
19- Complex feature spanning multiple domains (full-stack, mobile)
20- Coordination needed between frontend, backend, mobile, and QA
21- User wants step-by-step guidance for multi-agent coordination
22
23### When NOT to use
24
25- Simple single-domain task -> use the specific agent directly
26- User wants automated execution -> use orchestrator
27- Quick bug fixes or minor changes
28
29### Expected inputs
30- Complex feature or project goal
31- Required domains and priority tiers
32- Workspace/session constraints and API/data contract needs
33
34### Expected outputs
35- Manual coordination sequence
36- PM task decomposition, agent spawn order, monitoring guidance, and QA review step
37- API/data contract alignment checkpoints
38
39### Dependencies
40- PM, frontend, backend, mobile, QA, and orchestrator skills
41- `resources/examples.md`
42- CLI `oma agent:spawn` and progress/result memory conventions
43
44### Control-flow features
45- Branches by task complexity, priority tiers, dependency ordering, and whether automation is desired
46- Spawns independent same-priority tasks in parallel when appropriate
47- Monitors progress files and contract alignment
48
49## Structural Flow
50
51### Entry
521. Confirm the task is complex enough for multi-agent coordination.
532. Start with PM task decomposition.
543. Identify priority tiers and shared contracts.
55
56### Scenes
571. **PREPARE**: Define session, domains, and task decomposition needs.
582. **ACT**: Spawn agents by priority with separate workspaces.
593. **VERIFY**: Monitor progress and API/data contract alignment.
604. **FINALIZE**: Run QA review and coordinate remediation.
61
62### Transitions
63- If task is simple, route to one specialist.
64- If user wants automated execution, use orchestrator.
65- If QA finds CRITICAL issues, re-spawn responsible agents.
66
67### Failure and recovery
68- If contracts diverge, pause downstream frontend/mobile work until backend/API contract is reconciled.
69- If agent workspaces conflict, split ownership boundaries.
70- If progress stalls, inspect progress files and reissue focused instructions.
71
72### Exit
73- Success: specialist outputs are coordinated and QA-reviewed.
74- Partial success: blocked agents, contract conflicts, or QA failures are explicit.
75
76## Logical Operations
77
78### Actions
79| Action | SSL primitive | Evidence |
80|--------|---------------|----------|
81| Read request and domains | `READ` | User prompt and project context |
82| Select agent plan | `SELECT` | PM decomposition and priority tiers |
83| Spawn agents | `CALL_TOOL` | `oma agent:spawn` |
84| Monitor progress | `READ` | `progress-{agent}.md` |
85| Validate contracts | `VALIDATE` | API/data model alignment |
86| Notify coordination status | `NOTIFY` | Final coordination summary |
87
88### Tools and instruments
89- `oma agent:spawn`, PM/frontend/backend/mobile/QA agents
90- Memory/progress/result files
91- Serena MCP for exploration and modification when used by specialists
92
93### Canonical command path
94```bash
95oma agent:spawn pm "<planning task>" <session-id> -w ./pm
96oma agent:spawn backend "<backend task>" <session-id> -w ./backend &
97oma agent:spawn frontend "<frontend task>" <session-id> -w ./frontend &
98wait
99```
100
101### Resource scope
102| Scope | Resource target |
103|-------|-----------------|
104| `LOCAL_FS` | Progress/result files and workspaces |
105| `PROCESS` | Agent spawn commands |
106| `MEMORY` | Session state and task board |
107| `CODEBASE` | Shared contracts and implementation areas |
108
109### Preconditions
110- Task requires multiple domains.
111- PM decomposition can identify independent priority tiers.
112
113### Effects and side effects
114- Spawns or guides multiple agents.
115- Coordinates workspace ownership and QA feedback.
116
117### Guardrails
118
1191. Always start with PM Agent for task decomposition
1202. Spawn independent tasks in parallel (same priority tier)
1213. Define API contracts before frontend/mobile tasks
1224. QA review is always the final step
1235. Assign separate workspaces to avoid file conflicts
1246. Always use Serena MCP tools as the primary method for code exploration and modification
1257. Never skip steps in the workflow; follow each step sequentially without omission
126
127### Workflow
128
129### Step 1: Plan with PM Agent
130
131PM Agent analyzes requirements, selects tech stack, creates task breakdown with priorities.
132
133### Step 2: Spawn Agents by Priority
134
135Spawn agents via CLI:
136
1371. Use `oma agent:spawn` for each task
1382. CLI selection follows `model_preset` (and per-agent overrides) in oma-config.yaml
1393. Spawn all same-priority tasks in parallel using background processes
140
141```bash
142# Example: spawn backend and frontend in parallel
143oma agent:spawn backend "task description" session-id -w ./backend &
144oma agent:spawn frontend "task description" session-id -w ./frontend &
145wait
146```
147
148### Step 3: Monitor & Coordinate
149
150- Use memory read tool to poll `progress-{agent}.md` files
151- Verify API contracts align between agents
152- Ensure shared data models are consistent
153
154### Step 4: QA Review
155
156Spawn QA Agent last to review all deliverables. Address CRITICAL issues by re-spawning agents.
157
158### Automated Alternative
159
160For fully automated execution without manual spawning, use the **orchestrator** skill instead.
161
162## References
163
164- Workflow examples: `resources/examples.md`