القائمة
Dispatch parallel subagents for independent tasks. Use when 2+ tasks have no shared state or sequential dependencies.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | godmode-parallel |
| description | Dispatch parallel subagents for independent tasks. Use when 2+ tasks have no shared state or sequential dependencies. |
Dispatch one agent per independent domain. Let them work concurrently.
Use when:
.ctx/GODMODE.tasks.yaml have no shared depends_onDo NOT use when:
Find all tasks where depends_on is empty or all dependencies are done. Group into chains.
Chains with no shared nodes are independent.
Each agent prompt must be self-contained, scoped to one crate or domain, explicit about
exact file paths and test names, and constrained: "Do NOT modify files outside crates/<crate>/."
Write .ctx/wave-status.json before dispatching:
{
"wave": 1,
"agents": {
"<crate>": { "status": "pending", "branch": "", "commits": [] }
}
}
Cap at 5 concurrent agents. Always pass allowedTools explicitly — agents do NOT inherit
Bash permissions from parent.
After all agents report:
status: "pending" or empty commits list.cargo nextest run --workspace
cargo clippy --workspace -- -D warnings
--no-ff (never octopus-merge)..ctx/GODMODE.tasks.yaml: mark completed tasks done.mv .ctx/wave-status.json .ctx/wave-<N>-complete.jsonBLOCKED.md → stop. Do not retry with identical parameters.git branch --show-current before every commit. If main — stop.Write an implementation plan as a markdown file, then immediately serialize it to a timestamped YAML task file in .ctx/tasks/. Use before touching any code when given a spec or approved design.
Design-first workflow for new features, components, or architecture decisions. Use before writing any code — get explicit approval on a design first.
Commit-and-push workflow with validation. Use when asked to "cap", "commit and push", or "ship it".
Systematic debugging for Rust. Use before proposing any fix — establish root cause first, then write a failing test, then fix.
Task graph management for a session. Use to create tasks, track progress, execute the next unblocked task, or manage dependencies between work items.
Test-driven development workflow for Rust. Use before writing any implementation code — write a failing test first, then implement, then refactor.