メニュー
Use to actually launch multiple developer agents in parallel via the subagent tool (Task/Agent), given a sprint plan and board. Triggers from /app-build or when the tech-manager says "spawn the pod". Encapsulates the rules for safe concurrent agent execution.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | parallel-orchestrator |
| description | Use to actually launch multiple developer agents in parallel via the subagent tool (Task/Agent), given a sprint plan and board. Triggers from /app-build or when the tech-manager says "spawn the pod". Encapsulates the rules for safe concurrent agent execution. |
You launch IC agents concurrently. This skill exists because parallel agent launches need rules — without them, agents stomp each other.
Called from /app-build or by the tech-manager once docs/31-board.md has tickets in todo ready to start.
Read the board. Find tickets where Status = todo and all Depends on IDs are done.
Group by owner. One agent invocation per owner, batched. iOS dev gets all their ready tickets in one prompt; same for Android; same for backend.
Launch in a single message. Use the subagent tool (Task/Agent) with multiple invocations in the same assistant message so they run concurrently. This is the critical step — sequential launches give up the parallelism we just earned.
Each agent prompt includes:
DONE: APP-NNN ... or BLOCKED: APP-NNN ...)Stream the reviews — do not wait for the whole batch. As each developer Task returns DONE: APP-NNN, update the board row to Status = review and spawn a code-reviewer Task for that branch in the next message. Reviewers run in parallel with each other and with still-running developers. Waiting for the slowest dev before any review starts wastes wall-clock time.
Merge gate. Only APPROVED PRs go to tech-manager for merge → board moves review → qa. REQUEST CHANGES re-spawns the original developer with the reviewer's notes. The review-cycle cap (2 cycles, per /app-build step 4) is enforced by the orchestrator — past it, surface to the user.
Board ready state:
APP-001 todo ios-developer
APP-002 todo android-developer
APP-003 todo backend-developer
APP-004 todo ios-developer (depends on APP-001)
Correct launch:
[same message]
Agent(ios-developer, "Work APP-001, see board row + spec links ...")
Agent(android-developer, "Work APP-002 ...")
Agent(backend-developer, "Work APP-003 ...")
APP-004 is NOT launched until APP-001 reports DONE.
After all three return DONE:
[same message]
Agent(code-reviewer, "Review feat/APP-001-... for APP-001")
Agent(code-reviewer, "Review feat/APP-002-... for APP-002")
Agent(code-reviewer, "Review feat/APP-003-... for APP-003")
Then APP-004 launches with ios-developer, in parallel with whatever else is now ready.
Use before writing any code, spec, or store asset on a Mobify Studio app — loads the relevant House Knowledge Base pack(s) so output matches the studio's established conventions instead of generic defaults. Every IC and exec agent invokes this first.
Use when pointing the team at an EXISTING, already-built app instead of a blank project — detects the stack, reverse-engineers the as-built architecture, and classifies remediation work as safe-to-auto-fix vs risky-needs-approval. Triggered by /app-onboard, /app-audit, and by /app-run when it detects a non-empty app directory.
Use to produce the technical architecture doc and engineering principles for a mobile app. Used primarily by the CTO agent. Triggers on "design the architecture", "pick the stack", or as part of /app-plan.
Use to construct a complete Product Requirements Document for a mobile app from a vision file. Used primarily by the CPO agent. Triggers on requests to "write the PRD", "spec out the product", or as part of /app-plan.
Use at the very start of a new app project to convert a one-line idea or rough brief into a structured requirements document the CEO/CPO/CTO agents can act on. Triggers when the user says "build an app", "I have an idea for an app", or kicks off /app-init with a fuzzy prompt.
Use to convert the backlog into a runnable sprint with parallel ticket assignment and dependency tracking. Used primarily by the tech-manager. Triggers on "plan the sprint", "what does the pod do next", or as part of /app-build.