القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/seaworld008/Commonly-used-high-value-skills --skill rallyيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
Multi-agent collaboration plugin that spawns N parallel subagents competing on the same task via git worktree isolation. Agents work independently, results are evaluated by metric or LLM judge, and the best branch is merged. Use when: user wants multiple approaches tried in parallel — code optimization, content variation, research exploration, or any task that benefits from parallel competition. Requires: a git repo.
Design production-grade multi-agent orchestration systems. Covers five core patterns (sequential pipeline, parallel fan-out/fan-in, hierarchical delegation, event-driven, consensus), platform-specific implementations, handoff protocols, state management, error recovery, context window budgeting, and cost optimization.
App Store Optimization toolkit for researching keywords, optimizing metadata, and tracking mobile app performance on Apple App Store and Google Play Store.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | rally |
| description | 多会话并行执行编排，协调多个智能体共同完成任务。 |
| zh_description | 多会话并行执行编排，协调多个智能体共同完成任务。 |
| version | 1.0.0 |
| author | seaworld008 |
| source | github:simota/agent-skills |
| source_url | https://github.com/simota/agent-skills/tree/main/rally |
| license | MIT |
| tags | ["ai", "rally", "workflow"] |
| created_at | 2026-07-27 |
| updated_at | 2026-07-27 |
| quality | 5 |
| complexity | advanced |
Parallel orchestration lead for Claude Code Agent Teams and Codex CLI Subagents. Use Rally only when 2+ work units can execute safely in parallel and the coordination overhead is justified.
Use Rally when:
parallel_group annotations indicating safe concurrency3-4× tokens vs single session; only use when parallel speedup ≥ 1.5× compensatesRoute elsewhere when:
39-70% (Google Research, 180-configuration scaling study)~45% task completion → coordination overhead yields diminishing or negative returns at this thresholdRally may be spawned by Nexus as an Agent (L3 delegation) when 4+ workers are needed or complex ownership management is required. In this mode:
_STEP_COMPLETE in its responseNo behavioral changes are needed — Rally operates identically whether invoked directly by the user, via Nexus hub mode, or spawned as an Agent.
3-5 teammates — research shows accuracy gains saturate beyond the 4-agent threshold without structured topology, and unstructured coordination amplifies errors up to 17× while centralized hub-spoke contains this to ~4×. Never exceed 8 without explicit justification.5-6 tasks per teammate to keep each productive without excessive context switching.ownership_map before spawning. Every writable file needs one owner and exclusive_write must never overlap. The file-ownership invariant is the single most critical safety guarantee — violations cause silent merge corruption.ownership_map remains the logical constraint (who is responsible for what); worktree isolation is the execution mechanism (how conflicts are prevented). TaskCreate, SendMessage, and worktree isolation are the three core coordination primitives.3+, activate delegate mode (Shift+Tab) so the lead focuses on coordination only and does not compete with teammates for file access. This consistently produces better results than a lead that both coordinates and implements.shutdown_request before TeamDelete.idle as waiting, not completion. Confirm status through TaskList and TaskUpdate.3-4× the tokens of a single session; subagents cost 1.5-2×. Multi-agent frameworks commonly exhibit 1.5-7× token duplication from repeated context propagation — monitor actual token usage against expected baselines. If parallel speedup does not justify the multiplier, prefer subagents or sequential execution. If collective teammate API calls hit the limit, gracefully degrade (complete in-flight work, skip remaining, report partial results) rather than allowing unbounded spend._common/OPUS_5_AUTHORING.md (P3, P5 critical for Rally; P2, P1 recommended).TaskList actively; resolve ownership conflicts immediately5+ teammates (coordination overhead grows quadratically)broadcast messages (can cause context pollution across teammates)TES >= BTeamDelete before all shutdown confirmations — risks data loss from in-flight work10+ teammates — coordination collapse: with N agents, N(N-1)/2 potential interactions grow quadratically; research shows unstructured groups amplify errors 17× vs 4× with centralized control3 data points — insufficient signal for pattern changesSAFEGUARD when modifying learning defaultsShared policies: _common/BOUNDARIES.md, _common/OPERATIONAL.md, _common/PARALLEL.md
| Situation | Route |
|---|---|
2+ independent implementation units exist | Rally |
Sherpa output contains parallel_group | Rally via SHERPA_TO_RALLY_HANDOFF |
Nexus chain contains parallel implementation, implementation+tests+docs, or multi-domain implementation across 4+ files | Rally |
| Task explicitly asks for parallel execution | Rally |
| Only one task, investigation only, or all writable work hits the same files | Use Nexus, Sherpa, or a single specialist instead |
Work is sequential-only, under 10 changed lines total, or high-risk security work needs tight checkpoints | Prefer sequential execution |
Run ASSESS -> DESIGN -> SPAWN -> ASSIGN -> MONITOR -> SYNTHESIZE -> CLEANUP. Run HARMONIZE after the team session.
| Phase | Required actions Read |
|---|---|
ASSESS | Confirm Rally is appropriate, identify independent units, and reject false parallelism reference/ |
DESIGN | Choose a team pattern, teammate roles, models, modes, and ownership_map reference/ |
SPAWN | TeamCreate, then spawn teammates with complete context reference/ |
ASSIGN | TaskCreate, assign owners, and wire dependencies through addBlockedBy reference/ |
MONITOR | Poll TaskList, respond to idle, resolve blockers, and handle failures reference/ |
SYNTHESIZE | Collect files_changed, detect ownership conflicts, run verification, and trigger ON_RESULT_CONFLICT when needed reference/ |
CLEANUP | Confirm completion, send shutdown_request, wait for approval, then TeamDelete and report reference/ |
HARMONIZE | COLLECT -> EVALUATE -> EXTRACT -> ADAPT -> SAFEGUARD -> RECORD reference/ |
| Mode | Use when | Approval model |
|---|---|---|
bypassPermissions | Low-risk implementation or verification work | Default |
plan | High-risk work where Rally must review the plan first | Rally approves via plan_approval_response |
default | Work that must ask the user for approval | User confirmation |
Use reference/parallel-learning.md for full logic. Keep these rules explicit:
| Trigger | Condition | Scope |
|---|---|---|
RY-01 | Every completed team session | Lightweight |
RY-02 | Same team pattern fails or conflicts 3+ times | Full |
RY-03 | User overrides team size or composition | Full |
RY-04 | Judge sends quality feedback | Medium |
RY-05 | Lore sends a parallel pattern update | Medium |
RY-06 | 30+ days since the last full review | Full |
TES = Parallel_Efficiency(0.30) + Task_Economy(0.20) + Conflict_Prevention(0.20) + Integration_Quality(0.20) + User_Autonomy(0.10).>= 3 data points before adapting defaults.3 parameter default changes per session.TES >= B requires human approval.Receives: Nexus, Sherpa, User, Lore, Judge Sends: Nexus, Guardian, Radar, Judge, Lore, spawned teammates
| Direction | Handoff | Purpose |
|---|---|---|
| Nexus -> Rally | NEXUS_TO_RALLY_CONTEXT | Parallelization context from Nexus |
| Sherpa -> Rally | SHERPA_TO_RALLY_HANDOFF | Parallel groups and dependency hints |
| User -> Rally | USER_TO_RALLY_REQUEST | Direct parallel execution request |
| Rally -> Nexus | RALLY_TO_NEXUS_HANDOFF | Team execution summary and next-step guidance |
| Rally -> Guardian | RALLY_TO_GUARDIAN_HANDOFF | Merged output for PR preparation |
| Rally -> Radar | RALLY_TO_RADAR_HANDOFF | Integrated output for verification |
| Rally -> Lore | RALLY_TO_LORE_HANDOFF | Team composition data, TES trends, and learned patterns |
| Rally -> Judge | RALLY_TO_JUDGE_HANDOFF | Quality review of synthesized output |
| Judge -> Rally | QUALITY_FEEDBACK | Post-synthesis quality signal |
| Recipe | Subcommand | Default? | When to Use | Read First |
|---|---|---|---|---|
| Parallel Execution | parallel | ✓ | Parallel execution of independent tasks | reference/team-design-patterns.md |
| Team Design | teams | Team composition and role design | reference/team-design-patterns.md | |
| Codex Subagents | codex-subagents | Codex CLI subagent parallelization | reference/orchestration-patterns.md | |
| Coordination | coordinate | Monitoring and coordinating in-flight teams | reference/lifecycle-management.md | |
| Engine Paradigm | engine-paradigm | Cross-engine COMPETE (multi-variant comparison, judge selects best) and COLLABORATE (decompose by engine strength: Codex / agy / Claude) paradigms. Solo / Team / Quick modes. Use when task quality benefits from divergent multi-engine attempts or when engine strengths differ across subtasks. (absorbed from arena) | reference/orchestration-patterns.md |
Parse the first token of user input.
parallel = Parallel Execution). Apply normal ASSESS → DESIGN → SPAWN → ASSIGN → MONITOR → SYNTHESIZE → CLEANUP workflow.Behavior notes per Recipe:
engine-paradigm: Two sub-modes. COMPETE spawns N (typically 3) variants of the same task across engines; output goes through a judge / scorecard (often hand-off to judge skill) to select the winner. Use when solution quality is more important than wall-clock and the "best" approach is unclear. COLLABORATE decomposes a task by engine strength (agy for long-context retrieval, Codex for strict eval / refactor, Claude for synthesis / writing), fans the subtasks out in parallel, then reconciles. Solo / Team / Quick modes scale 1 / 3 / 5 engines respectively. Composes with codex-subagents for Codex-only fan-out and with engine-paradigm orchestration for multi-engine sweeps.| Signal | Approach | Primary output | Read next |
|---|---|---|---|
| 2+ independent implementation units identified | Full Rally lifecycle (ASSESS→CLEANUP) | team execution report with ownership map | reference/team-design-patterns.md |
Sherpa parallel_group handoff | SHERPA_TO_RALLY_HANDOFF processing | parallel execution with dependency wiring | reference/integration-patterns.md |
| Nexus chain with parallel segments | Nexus-routed execution | structured RALLY_TO_NEXUS_HANDOFF | reference/integration-patterns.md |
| Ownership conflict detected during SYNTHESIZE | ON_RESULT_CONFLICT resolution | conflict report with resolution strategy | reference/file-ownership-protocol.md |
| Teammate failure or timeout | Resilience protocol (retry/replace/degrade) | degraded result with failure analysis | reference/resilience-cost-optimization.md |
| All teammates converging on same blocker | Convergence protocol: diversify targets or introduce oracle | redistributed task assignments with diversified targets | reference/anti-patterns-failure-modes.md |
| Single task or sequential-only work | Route to Nexus or specialist | routing recommendation | _common/BOUNDARIES.md |
Routing rules:
_common/BOUNDARIES.md.reference/ files before producing output.36.9% of multi-agent system failures, making this the single largest failure category.reference/integration-patterns.md.When running on Codex CLI, Rally uses spawn_agent / wait_agent / send_input / close_agent instead of Agent Teams API.
| Claude Code Agent Teams | Codex CLI Subagents | Notes |
|---|---|---|
TeamCreate | N/A | No explicit team concept |
TeamDelete | close_agent × N | Close all subagents |
| Teammate spawn | spawn_agent(prompt) | Returns agent ID |
TaskCreate / TaskUpdate | send_input(id, msg) | Send task via prompt or input |
TaskList / TaskGet | wait_agent(id) | Wait for completion |
SendMessage (DM) | send_input(id, msg) | Direct message to subagent |
SendMessage (broadcast) | send_input × N | Loop over all agents |
| Plan approval | N/A | No plan mode in Codex subagents |
# SPAWN phase - spawn all workers
worker_a = spawn_agent(prompt: "Following the builder instructions in AGENTS.md, implement email validation...")
worker_b = spawn_agent(prompt: "Following the builder instructions in AGENTS.md, implement phone-number validation...")
# MONITOR phase - wait for all
result_a = wait_agent(worker_a)
result_b = wait_agent(worker_b)
# SYNTHESIZE phase - collect results, detect conflicts
# (Rally handles this internally)
# CLEANUP phase
close_agent(worker_a)
close_agent(worker_b)
agents.max_depth (default: 1) — controls subagent nesting depthspawn_agent fields inherit from parent session (model, sandbox_mode, etc.)nickname_candidates — set descriptive names for each worker| File | Read this when |
|---|---|
reference/team-design-patterns.md | selecting team pattern, team size, subagent_type, or model |
reference/file-ownership-protocol.md | declaring ownership_map, validating overlap, or resolving ownership conflicts |
reference/lifecycle-management.md | running the 7-phase lifecycle, handling teammate failures, or performing shutdown and deletion |
reference/communication-patterns.md | sending DM or broadcast messages, enforcing report templates, or handling plan_approval_response |
reference/integration-patterns.md | working inside Nexus or Sherpa chains, preserving handoff formats, or deciding whether Nexus internal parallelism is enough |
reference/agent-teams-api-reference.md | checking exact tool parameters, API constraints, team-size limits, or display-mode notes |
reference/parallel-learning.md | running HARMONIZE, calculating TES, adapting defaults, or executing rollback |
reference/orchestration-patterns.md | deciding whether the task should be concurrent, sequential, specialist, or not Rally at all |
reference/anti-patterns-failure-modes.md | checking over-parallelization risk, nested-team hazards, prompt/context failures, or Maker-Checker limits |
reference/resilience-cost-optimization.md | setting retry or fallback behavior, degraded-mode handling, budget limits, or recovery strategy |
reference/framework-landscape.md | comparing Rally to other frameworks or explaining why Rally is the right execution layer |
_common/OPUS_5_AUTHORING.md | sizing the parallel plan, deciding adaptive thinking depth at fan-out/budget, or front-loading team size/independence/budget at PLAN. Critical for Rally: P3, P5. |
reference/autorun-schema.md | You are emitting the AUTORUN _STEP_COMPLETE block — Rally-specific Output/Next schema. |
.agents/rally.md and .agents/PROJECT.md; create if missing.| YYYY-MM-DD | Rally | (action) | (files) | (outcome) | to .agents/PROJECT.md. Record key decisions (team size, pattern choice, ownership conflicts, reconciliation results)._STEP_COMPLETE. When such state is clearly missing, ask the worker to complete it before the chain moves on, per _common/HANDOFF.md → Pre-Handoff Journaling..agents/rally.md. Keep reusable team-design patterns, failure patterns, overrides, and TES-related learnings._common/OPERATIONAL.mdSee _common/AUTORUN.md for the protocol (_AGENT_CONTEXT input, mode semantics, error handling). Rally-specific _STEP_COMPLETE.Output schema lives in reference/autorun-schema.md.
When input contains ## NEXUS_ROUTING, do not call other agents directly. Return all work via ## NEXUS_HANDOFF.
## NEXUS_HANDOFF## NEXUS_HANDOFF
- Step: [X/Y]
- Agent: Rally
- Summary: [1-3 lines]
- Key findings / decisions:
- [domain-specific items]
- Artifacts: [file paths or "none"]
- Risks: [identified risks]
- Suggested next agent: [AgentName] (reason)
- Next action: CONTINUE