orchestrate

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Multi-Agent Orchestration

多Agent编排

Meta-orchestration patterns mined from 597+ real agent dispatches across production codebases. This skill tells you WHICH strategy to use, HOW to structure prompts, and WHEN to use background vs foreground.
Core principle: Choose the right orchestration strategy for the work, partition agents by independence, inject context to enable parallelism, and adapt review overhead to trust level.
从生产代码库的597+次真实Agent调度中提炼出的元编排模式。本技能会告诉你该使用哪种策略、如何构造提示词,以及何时使用后台/前台运行模式。
核心原则: 为工作选择合适的编排策略,按独立性划分Agent,注入上下文以支持并行运行,根据信任级别调整审核开销。

Strategy Selection

策略选择

dot
digraph strategy_selection {
    rankdir=TB;
    "What type of work?" [shape=diamond];

    "Research / knowledge gathering" [shape=box];
    "Independent feature builds" [shape=box];
    "Sequential dependent tasks" [shape=box];
    "Same transformation across partitions" [shape=box];
    "Codebase audit / assessment" [shape=box];
    "Greenfield project kickoff" [shape=box];

    "Research Swarm" [shape=box style=filled fillcolor=lightyellow];
    "Epic Parallel Build" [shape=box style=filled fillcolor=lightyellow];
    "Sequential Pipeline" [shape=box style=filled fillcolor=lightyellow];
    "Parallel Sweep" [shape=box style=filled fillcolor=lightyellow];
    "Multi-Dimensional Audit" [shape=box style=filled fillcolor=lightyellow];
    "Full Lifecycle" [shape=box style=filled fillcolor=lightyellow];

    "What type of work?" -> "Research / knowledge gathering";
    "What type of work?" -> "Independent feature builds";
    "What type of work?" -> "Sequential dependent tasks";
    "What type of work?" -> "Same transformation across partitions";
    "What type of work?" -> "Codebase audit / assessment";
    "What type of work?" -> "Greenfield project kickoff";

    "Research / knowledge gathering" -> "Research Swarm";
    "Independent feature builds" -> "Epic Parallel Build";
    "Sequential dependent tasks" -> "Sequential Pipeline";
    "Same transformation across partitions" -> "Parallel Sweep";
    "Codebase audit / assessment" -> "Multi-Dimensional Audit";
    "Greenfield project kickoff" -> "Full Lifecycle";
}
StrategyWhenAgentsBackgroundKey Pattern
Research SwarmKnowledge gathering, docs, SOTA research10-60+Yes (100%)Fan-out, each writes own doc
Epic Parallel BuildPlan with independent epics/features20-60+Yes (90%+)Wave dispatch by subsystem
Sequential PipelineDependent tasks, shared files3-15No (0%)Implement -> Review -> Fix chain
Parallel SweepSame fix/transform across modules4-10No (0%)Partition by directory, fan-out
Multi-Dimensional AuditQuality gates, deep assessment6-9No (0%)Same code, different review lenses
Full LifecycleNew project from scratchAll aboveMixedResearch -> Plan -> Build -> Review -> Harden

dot
digraph strategy_selection {
    rankdir=TB;
    "What type of work?" [shape=diamond];

    "Research / knowledge gathering" [shape=box];
    "Independent feature builds" [shape=box];
    "Sequential dependent tasks" [shape=box];
    "Same transformation across partitions" [shape=box];
    "Codebase audit / assessment" [shape=box];
    "Greenfield project kickoff" [shape=box];

    "Research Swarm" [shape=box style=filled fillcolor=lightyellow];
    "Epic Parallel Build" [shape=box style=filled fillcolor=lightyellow];
    "Sequential Pipeline" [shape=box style=filled fillcolor=lightyellow];
    "Parallel Sweep" [shape=box style=filled fillcolor=lightyellow];
    "Multi-Dimensional Audit" [shape=box style=filled fillcolor=lightyellow];
    "Full Lifecycle" [shape=box style=filled fillcolor=lightyellow];

    "What type of work?" -> "Research / knowledge gathering";
    "What type of work?" -> "Independent feature builds";
    "What type of work?" -> "Sequential dependent tasks";
    "What type of work?" -> "Same transformation across partitions";
    "What type of work?" -> "Codebase audit / assessment";
    "What type of work?" -> "Greenfield project kickoff";

    "Research / knowledge gathering" -> "Research Swarm";
    "Independent feature builds" -> "Epic Parallel Build";
    "Sequential dependent tasks" -> "Sequential Pipeline";
    "Same transformation across partitions" -> "Parallel Sweep";
    "Codebase audit / assessment" -> "Multi-Dimensional Audit";
    "Greenfield project kickoff" -> "Full Lifecycle";
}
策略适用场景Agent数量后台运行占比核心模式
Research Swarm知识收集、文档整理、前沿技术研究10-60+是 (100%)扇出,每个Agent编写独立文档
Epic Parallel Build包含独立史诗/功能的开发计划20-60+是 (90%+)按子系统波次调度
Sequential Pipeline依赖型任务、共享文件修改3-15否 (0%)实现 -> 审核 -> 修复链
Parallel Sweep跨模块统一修复/转换4-10否 (0%)按目录划分,扇出调度
Multi-Dimensional Audit质量门禁、深度评估6-9否 (0%)同一份代码,不同审核视角
Full Lifecycle从零开始的新项目以上所有混合研究 -> 规划 -> 构建 -> 审核 -> 加固

Strategy 1: Research Swarm

策略1:Research Swarm

Mass-deploy background agents to build a knowledge corpus. Each agent researches one topic and writes one markdown document. Zero dependencies between agents.
批量部署后台Agent构建知识库。每个Agent负责研究一个主题并编写一份markdown文档,Agent之间无任何依赖。

When to Use

适用场景

  • Kicking off a new project (need SOTA for all technologies)
  • Building a skill/plugin (need comprehensive domain knowledge)
  • Technology evaluation (compare multiple options in parallel)
  • 启动新项目(需要所有相关技术的前沿信息)
  • 开发技能/插件(需要全面的领域知识)
  • 技术选型(并行对比多个可选方案)

The Pattern

运行模式

Phase 1: Deploy research army (ALL BACKGROUND)
    Wave 1 (10-20 agents): Core technology research
    Wave 2 (10-20 agents): Specialized topics, integrations
    Wave 3 (5-10 agents): Gap-filling based on early results

Phase 2: Monitor and supplement
    - Check completed docs as they arrive
    - Identify gaps, deploy targeted follow-up agents
    - Read completed research to inform remaining dispatches

Phase 3: Synthesize
    - Read all research docs (foreground)
    - Create architecture plans, design docs
    - Use Plan agent to synthesize findings
Phase 1: Deploy research army (ALL BACKGROUND)
    Wave 1 (10-20 agents): Core technology research
    Wave 2 (10-20 agents): Specialized topics, integrations
    Wave 3 (5-10 agents): Gap-filling based on early results

Phase 2: Monitor and supplement
    - Check completed docs as they arrive
    - Identify gaps, deploy targeted follow-up agents
    - Read completed research to inform remaining dispatches

Phase 3: Synthesize
    - Read all research docs (foreground)
    - Create architecture plans, design docs
    - Use Plan agent to synthesize findings

Prompt Template: Research Agent

提示词模板:研究Agent

markdown
Research [TECHNOLOGY] for [PROJECT]'s [USE CASE].

Create a comprehensive research doc at [OUTPUT_PATH]/[filename].md covering:

1. Latest [TECH] version and features (search "[TECH] 2026" or "[TECH] latest")
2. [Specific feature relevant to project]
3. [Another relevant feature]
4. [Integration patterns with other stack components]
5. [Performance characteristics]
6. [Known gotchas and limitations]
7. [Best practices for production use]
8. [Code examples for key patterns]

Include code examples where possible. Use WebSearch and WebFetch to get current docs.
Key rules:
  • Every agent gets an explicit output file path (no ambiguity)
  • Include search hints: "search [TECH] 2026" (agents need recency guidance)
  • Numbered coverage list (8-12 items) scopes the research precisely
  • ALL agents run in background -- no dependencies between research topics
markdown
Research [TECHNOLOGY] for [PROJECT]'s [USE CASE].

Create a comprehensive research doc at [OUTPUT_PATH]/[filename].md covering:

1. Latest [TECH] version and features (search "[TECH] 2026" or "[TECH] latest")
2. [Specific feature relevant to project]
3. [Another relevant feature]
4. [Integration patterns with other stack components]
5. [Performance characteristics]
6. [Known gotchas and limitations]
7. [Best practices for production use]
8. [Code examples for key patterns]

Include code examples where possible. Use WebSearch and WebFetch to get current docs.
核心规则:
  • 为每个Agent指定明确的输出文件路径(无歧义)
  • 包含搜索提示:
    search [TECH] 2026
    (Agent需要时效性指引)
  • 编号的覆盖列表(8-12项)精准限定研究范围
  • 所有Agent后台运行——研究主题之间无依赖

Dispatch Cadence

调度节奏

  • 3-4 seconds between agent dispatches
  • Group into thematic waves of 10-20 agents
  • 15-25 minute gaps between waves for gap analysis

  • Agent调度间隔3-4秒
  • 按主题分组为10-20个Agent的波次
  • 波次之间间隔15-25分钟用于缺口分析

Strategy 2: Epic Parallel Build

策略2:Epic Parallel Build

Deploy background agents to implement independent features/epics simultaneously. Each agent builds one feature in its own directory/module. No two agents touch the same files.
部署后台Agent并行实现独立功能/史诗需求。每个Agent在独立目录/模块中开发一个功能,无两个Agent操作相同文件。

When to Use

适用场景

  • Implementation plan with 10+ independent tasks
  • Monorepo with isolated packages/modules
  • Sprint backlog with non-overlapping features
  • 包含10+独立任务的实现计划
  • 带隔离包/模块的单体仓库
  • 无重叠功能的冲刺待办列表

The Pattern

运行模式

Phase 1: Scout (FOREGROUND)
    - Deploy one Explore agent to map the codebase
    - Identify dependency chains and independent workstreams
    - Group tasks by subsystem to prevent file conflicts

Phase 2: Deploy build army (ALL BACKGROUND)
    Wave 1: Infrastructure/foundation (Redis, DB, auth)
    Wave 2: Backend APIs (each in own module directory)
    Wave 3: Frontend pages (each in own route directory)
    Wave 4: Integrations (MCP servers, external services)
    Wave 5: DevOps (CI, Docker, deployment)
    Wave 6: Bug fixes from review findings

Phase 3: Monitor and coordinate
    - Check git status for completed commits
    - Handle git index.lock contention (expected with 30+ agents)
    - Deploy remaining tasks as agents complete
    - Track via Sibyl tasks or TodoWrite

Phase 4: Review and harden (FOREGROUND)
    - Run Codex/code-reviewer on completed work
    - Dispatch fix agents for critical findings
    - Integration testing
Phase 1: Scout (FOREGROUND)
    - Deploy one Explore agent to map the codebase
    - Identify dependency chains and independent workstreams
    - Group tasks by subsystem to prevent file conflicts

Phase 2: Deploy build army (ALL BACKGROUND)
    Wave 1: Infrastructure/foundation (Redis, DB, auth)
    Wave 2: Backend APIs (each in own module directory)
    Wave 3: Frontend pages (each in own route directory)
    Wave 4: Integrations (MCP servers, external services)
    Wave 5: DevOps (CI, Docker, deployment)
    Wave 6: Bug fixes from review findings

Phase 3: Monitor and coordinate
    - Check git status for completed commits
    - Handle git index.lock contention (expected with 30+ agents)
    - Deploy remaining tasks as agents complete
    - Track via Sibyl tasks or TodoWrite

Phase 4: Review and harden (FOREGROUND)
    - Run Codex/code-reviewer on completed work
    - Dispatch fix agents for critical findings
    - Integration testing

Prompt Template: Feature Build Agent

提示词模板:功能开发Agent

markdown
**Task: [DESCRIPTIVE TITLE]** (task\_[ID])

Work in /path/to/project/[SPECIFIC_DIRECTORY]
markdown
**Task: [DESCRIPTIVE TITLE]** (task\_[ID])

Work in /path/to/project/[SPECIFIC_DIRECTORY]

Context

Context

[What already exists. Reference specific files, patterns, infrastructure.] [e.g., "Redis is available at
app.state.redis
", "Follow pattern from
src/auth/
"]
[What already exists. Reference specific files, patterns, infrastructure.] [e.g., "Redis is available at
app.state.redis
", "Follow pattern from
src/auth/
"]

Your Job

Your Job

  1. Create
    src/path/to/module/
    with:
    • file.py
      -- [Description]
    • routes.py
      -- [Description]
    • models.py
      -- [Schema definitions]
  2. Implementation requirements: [Detailed spec with code snippets, Pydantic models, API contracts]
  3. Tests:
    • Create
      tests/test_module.py
    • Cover: [specific test scenarios]
  4. Integration:
    • Wire into [main app entry point]
    • Register routes at [path]
  1. Create
    src/path/to/module/
    with:
    • file.py
      -- [Description]
    • routes.py
      -- [Description]
    • models.py
      -- [Schema definitions]
  2. Implementation requirements: [Detailed spec with code snippets, Pydantic models, API contracts]
  3. Tests:
    • Create
      tests/test_module.py
    • Cover: [specific test scenarios]
  4. Integration:
    • Wire into [main app entry point]
    • Register routes at [path]

Git

Git

Commit with message: "feat([module]): [description]" Only stage files YOU created. Check
git status
before committing. Do NOT stage files from other agents.

**Key rules:**

- Every agent gets its own directory scope -- NO OVERLAP
- Provide existing patterns to follow ("Follow pattern from X")
- Include infrastructure context ("Redis available at X")
- Explicit git hygiene instructions (critical with 30+ parallel agents)
- Task IDs for traceability
Commit with message: "feat([module]): [description]" Only stage files YOU created. Check
git status
before committing. Do NOT stage files from other agents.

**核心规则:**

- 每个Agent有专属目录范围——无重叠
- 提供可遵循的现有模式(「遵循`X`中的模式」)
- 包含基础设施上下文(「Redis可通过`X`访问」)
- 明确的Git操作规范(30+并行Agent场景下至关重要)
- 任务ID用于可追溯性

Git Coordination for Parallel Agents

并行Agent的Git协调规则

When running 10+ agents concurrently:
  1. Expect index.lock contention -- agents will retry automatically
  2. Each agent commits only its own files -- prompt must say this explicitly
  3. No agent should run
    git add .
    -- only specific files
  4. Monitor with
    git log --oneline -20
    periodically
  5. No agent should push -- orchestrator handles push after integration

当同时运行10+Agent时:
  1. 预期会出现index.lock冲突——Agent会自动重试
  2. 每个Agent仅提交自己创建的文件——提示词中必须明确说明
  3. 禁止任何Agent运行
    git add .
    ——仅添加指定文件
  4. 定期运行
    git log --oneline -20
    监控进度
  5. 禁止Agent执行push操作——集成完成后由编排者统一推送

Strategy 3: Sequential Pipeline

策略3:Sequential Pipeline

Execute dependent tasks one at a time with review gates. Each task builds on the previous task's output. Use
superpowers:subagent-driven-development
for the full pipeline.
通过审核门禁逐个执行依赖型任务,每个任务基于前序任务的输出构建。可使用
superpowers:subagent-driven-development
实现完整流水线。

When to Use

适用场景

  • Tasks that modify shared files
  • Integration boundary work (JNI bridges, auth chains)
  • Review-then-fix cycles where each fix depends on review findings
  • Complex features where implementation order matters
  • 修改共享文件的任务
  • 集成边界工作(JNI桥接、认证链路)
  • 修复依赖审核结果的审核-修复循环
  • 实现顺序有要求的复杂功能

The Pattern

运行模式

For each task:
    1. Dispatch implementer (FOREGROUND)
    2. Dispatch spec reviewer (FOREGROUND)
    3. Dispatch code quality reviewer (FOREGROUND)
    4. Fix any issues found
    5. Move to next task

Trust Gradient (adapt over time):
    Early tasks:  Implement -> Spec Review -> Code Review (full ceremony)
    Middle tasks: Implement -> Spec Review (lighter)
    Late tasks:   Implement only (pattern proven, high confidence)
For each task:
    1. Dispatch implementer (FOREGROUND)
    2. Dispatch spec reviewer (FOREGROUND)
    3. Dispatch code quality reviewer (FOREGROUND)
    4. Fix any issues found
    5. Move to next task

Trust Gradient (adapt over time):
    Early tasks:  Implement -> Spec Review -> Code Review (full ceremony)
    Middle tasks: Implement -> Spec Review (lighter)
    Late tasks:   Implement only (pattern proven, high confidence)

Trust Gradient

信任梯度

As the session progresses and patterns prove reliable, progressively lighten review overhead:
PhaseReview OverheadWhen
Full ceremonyImplement + Spec Review + Code ReviewFirst 3-4 tasks
StandardImplement + Spec ReviewTasks 5-8, or after patterns stabilize
LightImplement + quick spot-checkLate tasks with established patterns
Cost-optimizedUse
model: "haiku"
for reviews
Formulaic review passes
This is NOT cutting corners -- it's earned confidence. If a late task deviates from the pattern, escalate back to full ceremony.

随着会话推进和模式验证可靠,可逐步降低审核开销:
阶段审核开销触发时机
全流程实现 + 需求审核 + 代码审核前3-4个任务
标准实现 + 需求审核第5-8个任务,或模式稳定后
轻量实现 + 快速抽查模式已确立的后期任务
成本优化
model: "haiku"
执行审核
公式化审核流程
这不是偷工减料——而是信任积累的结果。如果后期任务偏离既定模式,可回退到全流程审核。

Strategy 4: Parallel Sweep

策略4:Parallel Sweep

Apply the same transformation across partitioned areas of the codebase. Every agent does the same TYPE of work but on different FILES.
在代码库的分区范围内应用统一转换,每个Agent执行相同类型的工作但操作不同文件。

When to Use

适用场景

  • Lint/format fixes across modules
  • Type annotation additions across packages
  • Test writing for multiple modules
  • Documentation updates across components
  • UI polish across pages
  • 跨模块的lint/格式修复
  • 跨包的类型注解添加
  • 多模块的测试用例编写
  • 跨组件的文档更新
  • 跨页面的UI优化

The Pattern

运行模式

Phase 1: Analyze the scope
    - Run the tool (ruff, ty, etc.) to get full issue list
    - Auto-fix what you can
    - Group remaining issues by module/directory

Phase 2: Fan-out fix agents (4-10 agents)
    - One agent per module/directory
    - Each gets: issue count by category, domain-specific guidance
    - All foreground (need to verify each completes)

Phase 3: Verify and repeat
    - Run the tool again to check remaining issues
    - If issues remain, dispatch another wave
    - Repeat until clean
Phase 1: Analyze the scope
    - Run the tool (ruff, ty, etc.) to get full issue list
    - Auto-fix what you can
    - Group remaining issues by module/directory

Phase 2: Fan-out fix agents (4-10 agents)
    - One agent per module/directory
    - Each gets: issue count by category, domain-specific guidance
    - All foreground (need to verify each completes)

Phase 3: Verify and repeat
    - Run the tool again to check remaining issues
    - If issues remain, dispatch another wave
    - Repeat until clean

Prompt Template: Module Fix Agent

提示词模板:模块修复Agent

markdown
Fix all [TOOL] issues in the [MODULE_NAME] directory ([PATH]).

Current issues ([COUNT] total):

- [RULE_CODE]: [description] ([count]) -- [domain-specific fix guidance]
- [RULE_CODE]: [description] ([count]) -- [domain-specific fix guidance]

Run `[TOOL_COMMAND] [PATH]` to see exact issues.

IMPORTANT for [DOMAIN] code:
[Domain-specific guidance, e.g., "GTK imports need GI.require_version() before gi.repository imports"]

After fixing, run `[TOOL_COMMAND] [PATH]` to verify zero issues remain.
Key rules:
  • Provide issue counts by category (not just "fix everything")
  • Include domain-specific guidance (agents need to know WHY patterns exist)
  • Partition by directory to prevent overlap
  • Run in waves: fix -> verify -> fix remaining -> verify

markdown
Fix all [TOOL] issues in the [MODULE_NAME] directory ([PATH]).

Current issues ([COUNT] total):

- [RULE_CODE]: [description] ([count]) -- [domain-specific fix guidance]
- [RULE_CODE]: [description] ([count]) -- [domain-specific fix guidance]

Run `[TOOL_COMMAND] [PATH]` to see exact issues.

IMPORTANT for [DOMAIN] code:
[Domain-specific guidance, e.g., "GTK imports need GI.require_version() before gi.repository imports"]

After fixing, run `[TOOL_COMMAND] [PATH]` to verify zero issues remain.
核心规则:
  • 按分类提供问题计数(而不是仅说「修复所有问题」)
  • 包含领域特定指引(Agent需要知道模式存在的原因)
  • 按目录划分避免重叠
  • 按波次运行:修复 -> 验证 -> 修复剩余问题 -> 验证

Strategy 5: Multi-Dimensional Audit

策略5:Multi-Dimensional Audit

Deploy multiple reviewers to examine the same code from different angles simultaneously. Each reviewer has a different focus lens.
部署多个审核者同时从不同角度检查同一份代码,每个审核者有不同的关注视角。

When to Use

适用场景

  • Major feature complete, need comprehensive review
  • Pre-release quality gate
  • Security audit
  • Performance assessment
  • 核心功能开发完成,需要全面审核
  • 发布前质量门禁
  • 安全审计
  • 性能评估

The Pattern

运行模式

Dispatch 6 parallel reviewers (ALL FOREGROUND):
    1. Code quality & safety reviewer
    2. Integration correctness reviewer
    3. Spec completeness reviewer
    4. Test coverage reviewer
    5. Performance analyst
    6. Security auditor

Wait for all to complete, then:
    - Synthesize findings into prioritized action list
    - Dispatch targeted fix agents for critical issues
    - Re-review only the dimensions that had findings
Dispatch 6 parallel reviewers (ALL FOREGROUND):
    1. Code quality & safety reviewer
    2. Integration correctness reviewer
    3. Spec completeness reviewer
    4. Test coverage reviewer
    5. Performance analyst
    6. Security auditor

Wait for all to complete, then:
    - Synthesize findings into prioritized action list
    - Dispatch targeted fix agents for critical issues
    - Re-review only the dimensions that had findings

Prompt Template: Dimension Reviewer

提示词模板:维度审核者

markdown
[DIMENSION] review of [COMPONENT] implementation.

**Files to review:**

- [file1.ext]
- [file2.ext]
- [file3.ext]

**Analyze:**

1. [Specific question for this dimension]
2. [Specific question for this dimension]
3. [Specific question for this dimension]

**Report format:**

- Findings: numbered list with severity (Critical/Important/Minor)
- Assessment: Approved / Needs Changes
- Recommendations: prioritized action items

markdown
[DIMENSION] review of [COMPONENT] implementation.

**Files to review:**

- [file1.ext]
- [file2.ext]
- [file3.ext]

**Analyze:**

1. [Specific question for this dimension]
2. [Specific question for this dimension]
3. [Specific question for this dimension]

**Report format:**

- Findings: numbered list with severity (Critical/Important/Minor)
- Assessment: Approved / Needs Changes
- Recommendations: prioritized action items

Strategy 6: Full Lifecycle

策略6:Full Lifecycle

For greenfield projects, combine all strategies in sequence:
Session 1: RESEARCH (Research Swarm)
    -> 30-60 background agents build knowledge corpus
    -> Architecture planning agents synthesize findings
    -> Output: docs/research/*.md + docs/plans/*.md

Session 2: BUILD (Epic Parallel Build)
    -> Scout agent maps what exists
    -> 30-60 background agents build features by epic
    -> Monitor, handle git contention, track completions
    -> Output: working codebase with commits

Session 3: ITERATE (Build-Review-Fix Pipeline)
    -> Code review agents assess work
    -> Fix agents address findings
    -> Deep audit agents (foreground) assess each subsystem
    -> Output: quality-assessed codebase

Session 4: HARDEN (Sequential Pipeline)
    -> Integration boundary reviews (foreground, sequential)
    -> Security fixes, race condition fixes
    -> Test infrastructure setup
    -> Output: production-ready codebase
Each session shifts orchestration strategy to match the work's nature. Parallel when possible, sequential when required.

对于从零开始的新项目,按顺序组合所有策略:
Session 1: RESEARCH (Research Swarm)
    -> 30-60 background agents build knowledge corpus
    -> Architecture planning agents synthesize findings
    -> Output: docs/research/*.md + docs/plans/*.md

Session 2: BUILD (Epic Parallel Build)
    -> Scout agent maps what exists
    -> 30-60 background agents build features by epic
    -> Monitor, handle git contention, track completions
    -> Output: working codebase with commits

Session 3: ITERATE (Build-Review-Fix Pipeline)
    -> Code review agents assess work
    -> Fix agents address findings
    -> Deep audit agents (foreground) assess each subsystem
    -> Output: quality-assessed codebase

Session 4: HARDEN (Sequential Pipeline)
    -> Integration boundary reviews (foreground, sequential)
    -> Security fixes, race condition fixes
    -> Test infrastructure setup
    -> Output: production-ready codebase
每个会话根据工作性质调整编排策略,尽可能并行,必要时串行。

Background vs Foreground Decision

后台 vs 前台运行决策

dot
digraph bg_fg {
    "What is the agent producing?" [shape=diamond];

    "Information (research, docs)" [shape=box];
    "Code modifications" [shape=box];

    "Does orchestrator need it NOW?" [shape=diamond];
    "BACKGROUND" [shape=box style=filled fillcolor=lightgreen];
    "FOREGROUND" [shape=box style=filled fillcolor=lightyellow];

    "Does next task depend on this task's files?" [shape=diamond];
    "FOREGROUND (sequential)" [shape=box style=filled fillcolor=lightyellow];
    "FOREGROUND (parallel)" [shape=box style=filled fillcolor=lightyellow];

    "What is the agent producing?" -> "Information (research, docs)";
    "What is the agent producing?" -> "Code modifications";

    "Information (research, docs)" -> "Does orchestrator need it NOW?";
    "Does orchestrator need it NOW?" -> "FOREGROUND" [label="yes"];
    "Does orchestrator need it NOW?" -> "BACKGROUND" [label="no - synthesize later"];

    "Code modifications" -> "Does next task depend on this task's files?";
    "Does next task depend on this task's files?" -> "FOREGROUND (sequential)" [label="yes"];
    "Does next task depend on this task's files?" -> "FOREGROUND (parallel)" [label="no - different modules"];
}
Rules observed from 597+ dispatches:
  • Research agents with no immediate dependency -> BACKGROUND (100% of the time)
  • Code-writing agents -> FOREGROUND (even if parallel)
  • Review/validation gates -> FOREGROUND (blocks pipeline)
  • Sequential dependencies -> FOREGROUND, one at a time

dot
digraph bg_fg {
    "What is the agent producing?" [shape=diamond];

    "Information (research, docs)" [shape=box];
    "Code modifications" [shape=box];

    "Does orchestrator need it NOW?" [shape=diamond];
    "BACKGROUND" [shape=box style=filled fillcolor=lightgreen];
    "FOREGROUND" [shape=box style=filled fillcolor=lightyellow];

    "Does next task depend on this task's files?" [shape=diamond];
    "FOREGROUND (sequential)" [shape=box style=filled fillcolor=lightyellow];
    "FOREGROUND (parallel)" [shape=box style=filled fillcolor=lightyellow];

    "What is the agent producing?" -> "Information (research, docs)";
    "What is the agent producing?" -> "Code modifications";

    "Information (research, docs)" -> "Does orchestrator need it NOW?";
    "Does orchestrator need it NOW?" -> "FOREGROUND" [label="yes"];
    "Does orchestrator need it NOW?" -> "BACKGROUND" [label="no - synthesize later"];

    "Code modifications" -> "Does next task depend on this task's files?";
    "Does next task depend on this task's files?" -> "FOREGROUND (sequential)" [label="yes"];
    "Does next task depend on this task's files?" -> "FOREGROUND (parallel)" [label="no - different modules"];
}
从597+次调度中总结的规则:
  • 无即时依赖的研究Agent -> 后台运行(100%场景)
  • 代码编写Agent -> 前台运行(即使是并行模式)
  • 审核/验证门禁 -> 前台运行(会阻塞流水线)
  • 顺序依赖任务 -> 前台运行,逐个执行

Prompt Engineering Patterns

提示词工程模式

Pattern A: Role + Mission + Structure (Research)

模式A:角色 + 任务 + 结构(研究场景)

markdown
You are researching [DOMAIN] to create comprehensive documentation for [PROJECT].

Your mission: Create an exhaustive reference document covering ALL [TOPIC] capabilities.

Cover these areas in depth:

1. **[Category]** -- specific items
2. **[Category]** -- specific items
   ...

Use WebSearch and WebFetch to find blog posts, GitHub repos, and official docs.
markdown
You are researching [DOMAIN] to create comprehensive documentation for [PROJECT].

Your mission: Create an exhaustive reference document covering ALL [TOPIC] capabilities.

Cover these areas in depth:

1. **[Category]** -- specific items
2. **[Category]** -- specific items
   ...

Use WebSearch and WebFetch to find blog posts, GitHub repos, and official docs.

Pattern B: Task + Context + Files + Spec (Feature Build)

模式B:任务 + 上下文 + 文件 + 规范(功能开发场景)

markdown
**Task: [TITLE]** (task\_[ID])

Work in /absolute/path/to/[directory]
markdown
**Task: [TITLE]** (task\_[ID])

Work in /absolute/path/to/[directory]

Context

Context

[What exists, what to read, what infrastructure is available]
[What exists, what to read, what infrastructure is available]

Your Job

Your Job

  1. Create
    path/to/file
    with [description]
  2. [Detailed implementation spec]
  3. [Test requirements]
  4. [Integration requirements]
  1. Create
    path/to/file
    with [description]
  2. [Detailed implementation spec]
  3. [Test requirements]
  4. [Integration requirements]

Git

Git

Commit with: "feat([scope]): [message]" Only stage YOUR files.
undefined
Commit with: "feat([scope]): [message]" Only stage YOUR files.
undefined

Pattern C: Review + Verify + Report (Audit)

模式C:审核 + 验证 + 报告(审计场景)

markdown
Comprehensive audit of [SCOPE] for [DIMENSION].

Look for:

1. [Specific thing #1]
2. [Specific thing #2]
   ...
3. [Specific thing #10]

[Scope boundaries -- which directories/files]

Report format:

- Findings: numbered with severity
- Assessment: Pass / Needs Work
- Action items: prioritized
markdown
Comprehensive audit of [SCOPE] for [DIMENSION].

Look for:

1. [Specific thing #1]
2. [Specific thing #2]
   ...
3. [Specific thing #10]

[Scope boundaries -- which directories/files]

Report format:

- Findings: numbered with severity
- Assessment: Pass / Needs Work
- Action items: prioritized

Pattern D: Issue + Location + Fix (Bug Fix)

模式D:问题 + 位置 + 修复(Bug修复场景)

markdown
**Task:** Fix [ISSUE] -- [SEVERITY]

**Problem:** [Description with file:line references]
**Location:** [Exact file path]

**Fix Required:**

1. [Specific change]
2. [Specific change]

**Verify:**

1. Run [command] to confirm fix
2. Run tests: [test command]

markdown
**Task:** Fix [ISSUE] -- [SEVERITY]

**Problem:** [Description with file:line references]
**Location:** [Exact file path]

**Fix Required:**

1. [Specific change]
2. [Specific change]

**Verify:**

1. Run [command] to confirm fix
2. Run tests: [test command]

Context Injection: The Parallelism Enabler

上下文注入:并行能力的核心

Agents can work independently BECAUSE the orchestrator pre-loads them with all context they need. Without this, agents would need to explore first, serializing the work.
Always inject:
  • Absolute file paths (never relative)
  • Existing patterns to follow ("Follow pattern from
    src/auth/jwt.py
    ")
  • Available infrastructure ("Redis at
    app.state.redis
    ")
  • Design language/conventions ("SilkCircuit Neon palette")
  • Tool usage hints ("Use WebSearch to find...")
  • Git instructions ("Only stage YOUR files")
For parallel agents, duplicate shared context:
  • Copy the same context block into each agent's prompt
  • Explicit exclusion notes ("11-Sibyl is handled by another agent")
  • Shared utilities described identically

Agent能够独立工作的前提是编排者预先为其注入所有需要的上下文。没有上下文的话Agent需要先自行探索,会导致工作串行化。
必须注入的内容:
  • 绝对文件路径(不要用相对路径)
  • 可遵循的现有模式(「遵循
    src/auth/jwt.py
    中的模式」)
  • 可用的基础设施(「Redis可通过
    app.state.redis
    访问」)
  • 设计语言/规范(「SilkCircuit Neon配色方案」)
  • 工具使用提示(「使用WebSearch查找...」)
  • Git操作指引(「仅提交你创建的文件」)
并行Agent场景下需复制共享上下文:
  • 为每个Agent的提示词复制相同的上下文块
  • 明确的排除说明(「11-Sibyl由其他Agent负责」)
  • 共享工具的统一描述

Monitoring Parallel Agents

并行Agent监控

When running 10+ background agents:
  1. Check periodically --
    git log --oneline -20
    for commits
  2. Read output files --
    tail
    the agent output files for progress
  3. Track completions -- Use Sibyl tasks or TodoWrite
  4. Deploy gap-fillers -- As early agents complete, identify missing work
  5. Handle contention -- git index.lock is expected, agents retry automatically
当运行10+后台Agent时:
  1. 定期检查 —— 运行
    git log --oneline -20
    查看提交记录
  2. 读取输出文件 —— 用
    tail
    查看Agent输出文件了解进度
  3. 跟踪完成情况 —— 使用Sibyl任务或TodoWrite工具
  4. 部署补位Agent —— 早期Agent完成后识别缺失的工作
  5. 处理冲突 —— git index.lock冲突是正常现象,Agent会自动重试

Status Report Template

状态报告模板

undefined
undefined

Agent Swarm Status

Agent Swarm Status

[N] agents deployed | [M] completed | [P] in progress
[N] agents deployed | [M] completed | [P] in progress

Completed:

Completed:

  • [Agent description] -- [Key result]
  • [Agent description] -- [Key result]
  • [Agent description] -- [Key result]
  • [Agent description] -- [Key result]

In Progress:

In Progress:

  • [Agent description] -- [Status]
  • [Agent description] -- [Status]

Gaps Identified:

Gaps Identified:

  • [Missing area] -- deploying follow-up agent

---
  • [Missing area] -- deploying follow-up agent

---

Common Mistakes

常见错误

DON'T: Dispatch agents that touch the same files -> merge conflicts DO: Partition by directory/module -- one agent per scope
DON'T: Run all agents foreground when they're independent -> sequential bottleneck DO: Use background for research, foreground for code that needs coordination
DON'T: Send 50 agents with vague "fix everything" prompts DO: Give each agent a specific scope, issue list, and domain guidance
DON'T: Skip the scout phase for build sprints DO: Always Explore first to map what exists and identify dependencies
DON'T: Keep full review ceremony for every task in a long session DO: Apply the trust gradient -- earn lighter reviews through consistency
DON'T: Let agents run
git add .
or
git push
DO: Explicit git hygiene in every build prompt
DON'T: Dispatch background agents for code that needs integration DO: Background is for research only. Code agents run foreground.

禁止: 调度多个Agent操作相同文件 -> 合并冲突 正确做法: 按目录/模块划分 —— 每个Scope对应一个Agent
禁止: 独立任务也全部用前台运行Agent -> 串行瓶颈 正确做法: 研究场景用后台运行,需要协调的代码任务用前台运行
禁止: 给50个Agent发模糊的「修复所有问题」提示词 正确做法: 给每个Agent指定明确的范围、问题列表和领域指引
禁止: 开发冲刺跳过探索阶段 正确做法: 始终先运行Explore Agent梳理现有代码和依赖关系
禁止: 长会话中每个任务都保持全流程审核 正确做法: 应用信任梯度 —— 通过稳定表现换取更轻量的审核流程
禁止: 允许Agent运行
git add .
git push
正确做法: 每个开发提示词中都明确说明Git操作规范
禁止: 调度后台Agent处理需要集成的代码任务 正确做法: 后台仅用于研究场景,代码Agent全部前台运行

Integration with Other Skills

与其他技能的集成

SkillUse WithWhen
superpowers:subagent-driven-development
Sequential PipelineSingle-task implement-review cycles
superpowers:dispatching-parallel-agents
Parallel SweepIndependent bug fixes
superpowers:writing-plans
Full LifecycleCreate the plan before Phase 2
superpowers:executing-plans
Sequential PipelineBatch execution in separate session
superpowers:brainstorming
Full LifecycleBefore research phase
superpowers:requesting-code-review
All strategiesQuality gates between phases
superpowers:verification-before-completion
All strategiesFinal validation
技能配合使用场景触发时机
superpowers:subagent-driven-development
Sequential Pipeline单任务实现-审核循环
superpowers:dispatching-parallel-agents
Parallel Sweep独立Bug修复
superpowers:writing-plans
Full Lifecycle第二阶段前创建开发计划
superpowers:executing-plans
Sequential Pipeline独立会话中的批量执行
superpowers:brainstorming
Full Lifecycle研究阶段前
superpowers:requesting-code-review
所有策略阶段间的质量门禁
superpowers:verification-before-completion
所有策略最终验证