run-parallel-agents-feature-build

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

<EXTREMELY-IMPORTANT> This skill orchestrates real Agent tool executions. Non-negotiable rules: 1. Verify independence before launching anything. 2. Write a complete prompt for every spawned agent because fresh `subagent_type` agents do not inherit task context. 3. Launch all parallel agents in a single assistant message with multiple `Agent(...)` tool uses. 4. Use `run_in_background: true` for independent lanes and do not poll or tail background output. 5. Use `isolation: "worktree"` for code-writing lanes unless the task is explicitly read-only. </EXTREMELY-IMPORTANT>

<EXTREMELY-IMPORTANT> 此技能用于编排真实的Agent工具执行。不可协商的规则： 1. 在启动任何任务之前，先验证任务的独立性。 2. 为每个生成的Agent编写完整的提示词，因为新的`subagent_type` Agent不会继承任务上下文。 3. 在一条助手消息中使用多个`Agent(...)`工具调用，启动所有并行Agent。 4. 为独立执行通道设置`run_in_background: true`，不要轮询或跟踪后台输出。 5. 除非任务明确为只读，否则为代码编写通道使用`isolation: "worktree"`。 </EXTREMELY-IMPORTANT>

Run Parallel Agents Feature Build

运行并行Agent功能构建

Inputs

输入

$request

: Optional plan path, task selection, or user direction such as

execute layer 0 from .ulpi/plans/foo.json

build these three features in parallel

$request

：可选的计划路径、任务选择或用户指示，例如

execute layer 0 from .ulpi/plans/foo.json

或

build these three features in parallel

。

Goal

目标

Exploit Claude Code's real parallel agent runtime to execute independent build tasks concurrently without file conflicts, missing context, or fake orchestration.

利用Claude Code的真实并行Agent运行时，并发执行独立构建任务，避免文件冲突、上下文缺失或虚假编排。

Step 0: Resolve the candidate work set

步骤0：确定候选工作集

Identify the source of truth for the work:

an approved DAG plan
an explicit user task list
a clearly decomposed set of independent implementation lanes

Then determine:

task count
dependency edges
write scope overlap
whether each lane is build work rather than research or debugging

Do not use this skill if:

there are fewer than 3 independent lanes
any lane depends on another lane's result
multiple lanes write the same file or the same narrow subsystem surface
the task is still at planning or exploration stage

Use

AskUserQuestion

only if the decomposition is ambiguous and safe parallelization depends on a user choice.

Success criteria: You have a concrete set of parallel-safe build lanes.

确定工作的真实来源：

已批准的DAG计划
明确的用户任务列表
已清晰分解的独立实现通道集合

然后确定：

任务数量
依赖关系边
写入范围重叠情况
每个通道是否为构建工作，而非研究或调试工作

在以下情况请勿使用此技能：

独立通道数量少于3个
任何通道依赖于其他通道的结果
多个通道写入同一文件或同一狭窄子系统区域
任务仍处于规划或探索阶段

仅当分解存在歧义且安全并行化取决于用户选择时，才使用

AskUserQuestion

。

成功标准：你拥有一组具体的可并行安全执行的构建通道。

Step 1: Prove independence, do not assume it

步骤1：验证独立性，勿主观假设

For each candidate lane, verify:

required inputs are already available
no output from another lane is needed first
write scope is disjoint
validation can be run per lane or after merge without ambiguity

If a plan exists, treat its dependency graph and write scope as the primary source.

If there is no plan, derive equivalent temporary structure:

lane name
scope
expected files
acceptance criteria
validation command

Load

references/agent-runtime-semantics.md

for the runtime rules that make or break parallel execution.

Success criteria: Every lane is independently executable without merge-race risk.

针对每个候选通道，验证：

所需输入已就绪
无需先获取其他通道的输出
写入范围互不相交
可按通道运行验证，或在合并后无歧义地运行验证

若存在计划，则将其依赖图和写入范围作为主要依据。

若没有计划，则推导等效的临时结构：

通道名称
范围
预期文件
验收标准
验证命令

加载

references/agent-runtime-semantics.md

，获取决定并行执行成败的运行时规则。

成功标准：每个通道均可独立执行，不存在合并竞争风险。

Step 2: Match each lane to the right agent

步骤2：为每个通道匹配合适的Agent

Choose the most appropriate specialized agent for each lane based on:

repository technology
target files and directories
framework-specific patterns
whether the work is implementation or general support

Load

references/agent_matching_logic.md

for detailed matching rules and edge cases.

Practical defaults:

use the most specific framework/domain agent available
use
```
general-purpose
```
only when no stronger fit exists
do not invent agent types

Success criteria: Every lane has a justified agent assignment.

根据以下因素为每个通道选择最适合的专用Agent：

仓库技术栈
目标文件和目录
框架特定模式
工作内容是实现还是通用支持

加载

references/agent_matching_logic.md

，获取详细的匹配规则和边缘情况处理方式。

实用默认规则：

使用可用的最具体的框架/领域Agent
仅在没有更合适的选择时才使用
```
general-purpose
```
不要自行创建Agent类型

成功标准：每个通道的Agent分配均有合理依据。

Step 3: Build full agent briefs

步骤3：编写完整的Agent任务简报

Because fresh

subagent_type

agents start without the main thread's task context, every prompt must contain:

exact scope
why this task exists
files or directories to inspect
write scope
constraints and patterns to follow
acceptance criteria
validation command
explicit instruction whether the lane should write code or only investigate

If the work came from a DAG plan, preserve:

task ID
acceptance criteria
write scope
validation command
review requirement

If the task is identity, routing, registry, or isolation sensitive, require the lane to use

references/task-exit-gate.md

before declaring completion.

Success criteria: Each lane prompt is complete enough for a fresh agent to act without asking basic clarifying questions.

由于新的

subagent_type

Agent启动时不包含主线程的任务上下文，每个提示词必须包含：

精确的范围
任务存在的原因
需要检查的文件或目录
写入范围
需要遵循的约束和模式
验收标准
验证命令
明确指示该通道应编写代码还是仅进行调研

若工作来自DAG计划，请保留：

任务ID
验收标准
写入范围
验证命令
评审要求

若任务涉及身份、路由、注册表或隔离敏感内容，要求通道在声明完成前使用

references/task-exit-gate.md

。

成功标准：每个通道的提示词足够完整，新Agent无需询问基础澄清问题即可执行任务。

Step 4: Launch all agents in one parallel batch

步骤4：一次性批量启动所有Agent

Launch every lane in a single assistant message containing multiple

Agent(...)

tool uses.

Required launch semantics for code-writing lanes:

```
subagent_type
```
: matched agent type
```
description
```
: short 3-5 word description
```
prompt
```
: full task brief
```
run_in_background: true
```
```
isolation: "worktree"
```

Runtime-specific rules:

do not send the agent launches across multiple assistant messages if the user asked for parallel work
do not rely on agent defaults for async or isolation when code-writing safety matters
do not use read-only forks here; this skill is for fresh specialized build agents

Load

references/agent-runtime-semantics.md

for the exact source-backed reasons behind these rules.

Success criteria: All independent lanes are launched concurrently with explicit, safe runtime settings.

在一条包含多个

Agent(...)

工具调用的助手消息中启动所有通道。

代码编写通道的必填启动语义：

```
subagent_type
```
：匹配的Agent类型
```
description
```
：3-5个单词的简短描述
```
prompt
```
：完整的任务简报
```
run_in_background: true
```
```
isolation: "worktree"
```

运行时特定规则：

若用户要求并行工作，请勿跨多条助手消息发送Agent启动请求
当代码编写安全性至关重要时，不要依赖Agent的异步或隔离默认设置
此处不要使用只读分支；此技能适用于新的专用构建Agent

加载

references/agent-runtime-semantics.md

，获取这些规则背后的准确来源依据。

成功标准：所有独立通道均已并发启动，并配置了明确、安全的运行时设置。

Step 5: Aggregate completions without polling

步骤5：聚合完成结果，无需轮询

After launch:

continue with non-overlapping coordination work
wait for completion notifications rather than polling background transcripts
trust the returned agent summaries unless there is a concrete reason to inspect deeper

When each lane completes, capture:

status
files touched
validation result
blockers or deviations from brief

If a lane is blocked, do not hide it inside a merged success summary.

Success criteria: Every spawned lane has a tracked outcome without unnecessary transcript noise.

启动后：

继续处理无重叠的协调工作
等待完成通知，而非轮询后台记录
除非有具体理由需要深入检查，否则信任返回的Agent摘要

每个通道完成时，记录：

状态
涉及的文件
验证结果
阻碍或与简报不符的情况

若某个通道被阻塞，不要将其隐藏在合并的成功摘要中。

成功标准：所有生成的通道均已跟踪结果，且无不必要的记录噪音。

Step 6: Review, conflict check, and closeout

步骤6：评审、冲突检查与收尾

Before treating a lane as merged:

check for write-scope conflicts across finished lanes
if the plan specifies a
```
review
```
field, invoke the corresponding review skill:
- ```
codex
```
  →
```
codex-review
```
- ```
claude
```
  →
```
claude-review
```
- ```
kiro
```
  →
```
kiro-review
```
if the lane came from a structured task plan, require the lane to satisfy
```
references/task-exit-gate.md
```

If conflicts exist:

stop automatic aggregation
identify the overlapping files
merge intentionally or escalate to the user

Success criteria: Finished lanes are reviewed and conflict-checked before being treated as complete.

在将通道视为已合并之前：

检查已完成通道之间的写入范围冲突
若计划指定了
```
review
```
字段，调用相应的评审技能：
- ```
codex
```
  →
```
codex-review
```
- ```
claude
```
  →
```
claude-review
```
- ```
kiro
```
  →
```
kiro-review
```
若通道来自结构化任务计划，要求通道满足
```
references/task-exit-gate.md
```
的要求

若存在冲突：

停止自动聚合
识别重叠文件
手动合并或上报给用户

成功标准：已完成的通道在被视为完成前，已通过评审和冲突检查。

Step 7: Report the consolidated result

步骤7：报告合并结果

Summarize:

which lanes ran
which agents handled them
completion status per lane
files or areas changed
reviews performed
remaining blockers or follow-up sequencing

Be explicit about partial success. Parallel execution is only a win if the user can see which lanes are actually done.

Success criteria: The user gets a concise but accurate parallel-execution summary.

总结内容：

运行了哪些通道
哪些Agent处理了这些通道
每个通道的完成状态
更改的文件或区域
执行的评审操作
剩余的阻碍或后续需按顺序执行的工作

明确说明部分成功的情况。只有当用户能清楚看到哪些通道已实际完成时，并行执行才是有效的。

成功标准：用户获得一份简洁但准确的并行执行摘要。

Guardrails

防护规则

Do not use this skill for fewer than 3 genuinely independent lanes.
Do not parallelize tasks with shared write scope or dependency edges.
Do not keep giant agent catalogs or launch templates inline in
```
SKILL.md
```
.
Do not assume fresh agents know the surrounding task context.
Do not poll or tail background agent output unless the user explicitly asks.
Do not rely on default agent
```
background
```
or
```
isolation
```
settings when explicit launch parameters are safer.
Do not add
```
disable-model-invocation
```
; this skill should remain available when the user asks for parallel execution.
Do not add
```
context: fork
```
; this workflow coordinates fresh specialized agents, not read-only skill forks.
Do not add
```
paths:
```
; this is a generic orchestration skill.

独立通道数量少于3个时，请勿使用此技能。
请勿并行化具有共享写入范围或依赖边的任务。
不要在
```
SKILL.md
```
中嵌入庞大的Agent目录或启动模板。
不要假设新Agent了解周边的任务上下文。
除非用户明确要求，否则不要轮询或跟踪后台Agent输出。
当明确的启动参数更安全时，不要依赖Agent的
```
background
```
或
```
isolation
```
默认设置。
不要添加
```
disable-model-invocation
```
；当用户要求并行执行时，此技能应保持可用。
不要添加
```
context: fork
```
；此工作流用于协调新的专用Agent，而非只读技能分支。
不要添加
```
paths:
```
；这是一个通用编排技能。

When To Load References

何时加载参考文档

```
references/agent-runtime-semantics.md
```
Use for source-backed Agent runtime rules: fresh context, single-message parallel launch, background behavior, worktree isolation, and explicit parameter precedence.
```
references/agent_matching_logic.md
```
Use for detailed agent-selection rules and framework-specific edge cases.
```
references/task-exit-gate.md
```
Use when the task came from a structured plan with acceptance criteria, write scope, and validation requirements.

```
references/agent-runtime-semantics.md
```
用于获取基于来源的Agent运行时规则：新上下文、单消息并行启动、后台行为、工作树隔离以及明确参数优先级。
```
references/agent_matching_logic.md
```
用于获取详细的Agent选择规则和框架特定边缘情况处理方式。
```
references/task-exit-gate.md
```
当任务来自具有验收标准、写入范围和验证要求的结构化计划时使用。

Output Contract

输出约定

Report:

resolved parallel lane set
agent assignment per lane
launch status
completion and review status per lane
conflicts, blockers, or remaining sequential work

报告内容：

已确定的并行通道集合
每个通道的Agent分配情况
启动状态
每个通道的完成和评审状态
冲突、阻碍或剩余的顺序执行工作