parallel-implementation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Parallel Implementation

并行实现

Planner skill — returns a slice plan, does not invoke subagents itself. The main Agent keeps execution authority.

这是一个规划类技能——仅返回任务拆分计划，不会自行调用子Agent。主Agent保留执行权限。

When to Use

适用场景

Invoke only when one of these triggers fires:

Greenfield 0→1 across multiple independent modules → plan a layered parallel split (e.g., data / service / UI layers each as their own slice). Greenfield independence makes this the cleanest parallel case.
Change touches ≥3 modules → the main Agent should confirm with the user via
```
AskUserQuestion
```
whether to parallelize; some cross-module edits are better serialized.
Change touches ≥5 files AND each file's diff exceeds 50 lines → the total work justifies dispatch overhead; recommend parallel.
User explicitly asks for "parallel write", "多 agent 并行实现", or "split this across subagents" → honor regardless of size.

Don't use for:

Single-file, 2-file, or 3–4 file changes where any slice's diff is <50 lines → main Agent writes it inline
Refactors where all callers cascade from a single change (e.g., renaming a widely-used helper) → serialize through main Agent
Work with serial dependencies (B needs A's output) → that's a pipeline, not parallel
Pure read tasks (review, search, analysis) → parallel subagents without slicing are fine; no planning needed

Multi-agent overhead (worktree setup, context briefing, result merging, conflict resolution) is real. When in doubt, inline wins.

仅在满足以下任一触发条件时调用：

从零到一构建跨多个独立模块的全新项目 → 规划分层并行拆分（例如，数据层/服务层/UI层各作为一个独立拆分单元）。全新项目的独立性让这成为最适合并行处理的场景。
修改涉及≥3个模块 → 主Agent应通过
```
AskUserQuestion
```
工具确认用户是否需要并行处理；部分跨模块修改按顺序执行效果更好。
修改涉及≥5个文件，且每个文件的代码差异超过50行 → 任务总量值得付出调度开销，建议并行处理。
用户明确要求“parallel write”、“多 agent 并行实现”或“split this across subagents” → 无论任务规模大小都遵循用户要求。

不适用场景：

单文件、双文件或3-4文件修改，且任一拆分单元的代码差异<50行 → 主Agent直接内联编写
所有调用方都依赖单一修改的重构（例如，重命名广泛使用的辅助函数） → 由主Agent按顺序执行
存在串行依赖的任务（B需要A的输出） → 这属于流水线任务，而非并行任务
纯读取类任务（评审、搜索、分析） → 无需规划即可直接使用并行子Agent

多Agent协作存在真实开销（工作树设置、上下文同步、结果合并、冲突解决）。存疑时，优先选择内联编写。

The Iron Law

铁律

A slice plan is only valid when every slice has independent inputs and independent outputs. If two slices can collide — on the same file, on a shared data structure, or on a shared mid-execution state — they are not parallel. Either merge them into one writer, or serialize them.

Violating this = guaranteed merge conflicts or silent state corruption.

只有当每个拆分单元的输入和输出完全独立时，拆分计划才有效。 如果两个拆分单元可能产生冲突——修改同一文件、共享数据结构或共享执行中间状态——则它们无法并行处理。要么将它们合并为一个处理单元，要么按顺序执行。

违反此规则必然导致合并冲突或静默状态损坏。

Steps

步骤

Step 1: Slice-ability check

步骤1：可拆分性检查

Ask: can this task be cut into pieces whose inputs and outputs don't overlap?

✅ "Implement
```
plugins.ts
```
resolver, write its unit tests in
```
tests/plugins.test.ts
```
, add CLI flag to
```
cli.ts
```
" — three files, dependencies resolvable at boundaries, each slice carries substantive logic
✅ "Greenfield: build data layer in
```
store.ts
```
, service layer in
```
service.ts
```
, UI layer in
```
ui.tsx
```
, each with its own tests" — layered 0→1, no shared mid-execution state
❌ "Refactor
```
utils.ts
```
to extract a logging helper and update all callers" — all callers edit sites cascade from the extraction; serialize
❌ "Add retry to the exec wrapper AND migrate exec callers to use it" — B depends on A; pipeline, not parallel

If the answer is no, return "serialize" and terminate. Don't force a bad split.

思考：该任务能否拆分为输入和输出互不重叠的多个单元？

✅ “实现
```
plugins.ts
```
解析器，在
```
tests/plugins.test.ts
```
中编写单元测试，为
```
cli.ts
```
添加CLI标志” ——三个文件，边界依赖可解，每个拆分单元包含独立逻辑
✅ “全新项目：在
```
store.ts
```
构建数据层，
```
service.ts
```
构建服务层，
```
ui.tsx
```
构建UI层，各层配有独立测试” ——分层从零到一构建，无共享执行中间状态
❌ “重构
```
utils.ts
```
以提取日志辅助函数并更新所有调用方” ——所有调用方的修改都依赖于提取操作；需按顺序执行
❌ “为exec包装器添加重试机制，并迁移所有exec调用方使用该机制” ——B依赖A；属于流水线任务，而非并行任务

如果答案是否定的，返回"serialize"并终止。不要强行拆分。

Step 2: Draft file assignments

步骤2：草拟文件分配方案

For each slice, list:

Which files it will create / modify / delete
What it needs from other slices as input (file paths, function signatures, data shapes)
What it produces as output (unified diff, new file set, state change)

Be explicit — vague assignments ("slice 2 touches the config layer") breed collisions.

为每个拆分单元列出：

将创建/修改/删除的文件
需要从其他拆分单元获取的输入（文件路径、函数签名、数据结构）
生成的输出（统一diff、新文件集、状态变更）

表述要明确——模糊的分配（如“拆分单元2处理配置层”）容易引发冲突。

Step 3: Collision check → merge

步骤3：冲突检查 → 合并

Scan the file-assignment table. For every file that appears in more than one slice:

If the edits are append-only and non-overlapping (e.g., both add different rows to different sections of the same Markdown table) → still merge to one writer; worktree merges of concurrent edits to the same file produce conflicts whenever the hunks touch adjacent lines
Otherwise → merge those slices to one subagent. Guaranteed.

Example:

✅ Slice A writes
```
cli.ts
```
, Slice B writes
```
utils.ts
```
— different files, safe
❌ Slice A and Slice B both edit
```
utils.ts
```
— merge into one slice
❌ Slice A edits
```
skills-lock.json
```
via
```
npx skills add
```
, Slice B also edits
```
skills-lock.json
```
directly — merge; the generator and the hand-edit will clobber each other

扫描文件分配表。对于出现在多个拆分单元中的每个文件：

如果修改是仅追加且无重叠（例如，向同一Markdown表格的不同部分添加不同行） → 仍需合并为一个处理单元；工作树中对同一文件的并发修改，只要修改块涉及相邻行就会产生冲突
否则 → 将这些拆分单元合并为一个子Agent处理，这是必须的。

示例：

✅ 拆分单元A修改
```
cli.ts
```
，拆分单元B修改
```
utils.ts
```
——不同文件，安全
❌ 拆分单元A和拆分单元B都修改
```
utils.ts
```
——合并为一个拆分单元
❌ 拆分单元A通过
```
npx skills add
```
修改
```
skills-lock.json
```
，拆分单元B直接修改
```
skills-lock.json
```
——合并；自动生成和手动编辑会互相覆盖

Step 4: Size filter

步骤4：规模过滤

For each remaining slice, estimate diff size. Rule of thumb:

< 50 lines of actual change per slice → drop from the plan; main Agent writes inline. Dispatch overhead (context setup, worktree spin-up, result merge) outweighs parallelism gain.
~50–150 lines → dispatch candidate
> 150 lines or architectural → dispatch, and note "override to a stronger reasoning model at
```
xhigh
```
effort (the maximum the runtime supports)" on the slice if the main Agent's current model is not already that

Drop small slices from the plan; note them as "main Agent handles inline".

Minimum-slices gate: if fewer than 3 dispatchable slices remain after filtering, terminate and return "serialize". Below three parallel writers, the dispatch ceremony (worktree spin-up, context briefing, merge) isn't worth the context cost — the main Agent writes them sequentially.

对每个剩余的拆分单元，估算代码差异规模。经验规则：

每个拆分单元实际修改<50行 → 从计划中移除；由主Agent内联编写。调度开销（上下文设置、工作树启动、结果合并）超过并行处理的收益。
~50–150行 → 可作为调度候选
>150行或涉及架构修改 → 进行调度，如果主Agent当前使用的模型不是最强推理模型，则在该拆分单元上标注“override to a stronger reasoning model at
```
xhigh
```
effort (the maximum the runtime supports)”

从计划中移除小型拆分单元；标注为“主Agent内联处理”。

最小拆分单元门槛：过滤后剩余可调度的拆分单元少于3个时，终止并返回"serialize"。少于3个并行处理单元时，调度流程（工作树启动、上下文同步、合并）的成本不值得——主Agent按顺序执行即可。

Step 5: Output contract per slice

步骤5：每个拆分单元的输出约定

For every dispatched slice, decide the exact format the subagent must return. No defaults.

Common contracts:

Code change: "Return the unified diff of your changes plus a one-line rationale per file."
New file: "Return the full file contents plus a one-paragraph explanation of its role."
Config edit: "Return the updated section verbatim; do not quote the entire file."
Test slice: "Return the test file plus a bullet list mapping test → requirement being verified."

An unspecified format = the subagent dumps verbose context back, cancelling the dispatch benefit.

对每个要调度的拆分单元，确定子Agent必须返回的精确格式。无默认格式。

常见约定：

代码修改：“返回修改的统一diff，以及每个文件的一行说明。”
新文件：“返回完整文件内容，以及一段说明其作用的文字。”
配置修改：“返回更新后的部分内容；不要引用整个文件。”
测试单元：“返回测试文件，以及将测试与待验证需求关联的项目符号列表。”

未指定格式会导致子Agent返回冗余上下文，抵消调度的优势。

Step 6: Return the plan

步骤6：返回计划

Emit a single table the main Agent can execute against:

Slice	Writer	Model	Files	Depends on	Output format
1	subagent	inherit	`src/plugins.ts`	—	unified diff + one-line rationale
2	subagent	inherit	`tests/plugins.test.ts`	slice 1 signature only	test file + requirement map
3	main Agent	—	`src/cli.ts`	slice 1 complete	(inline, no dispatch)

Annotate:

Which slices are parallelizable now (no blocking deps)
Which are gated (wait for a prior slice)
Which are inline (main Agent, no subagent)

Model column contract:

Default value is inherit
— subagent uses whatever model the main Agent is currently running (could be any Claude model, Codex / GPT-5.4, or a future main Agent runtime). Don't hardcode Anthropic-specific or OpenAI-specific model names as the default.
Set an explicit override only when the caller has a reason:
- User or main Agent asked for a specific model (e.g., "use opus high for the resolver slice")
- Slice is architectural / high-stakes and benefits from a stronger reasoning model at higher effort than the main Agent's current setting
- Slice is mechanical boilerplate that can safely drop to a faster/cheaper model
Write the override as a neutral phrase the main Agent can translate (e.g.,
```
stronger reasoning model, xhigh effort
```
,
```
fast mechanical model
```
), not a specific model name, unless the user named one.
Effort levels (when named) escalate:
```
low
```
→
```
medium
```
→
```
high
```
→
```
xhigh
```
. Complex / architectural slices default to
xhigh
(the max the runtime supports).
```
high
```
is appropriate for medium-complexity work; lower levels only for mechanical tasks.

输出主Agent可直接执行的表格：

拆分单元	处理方	模型	文件	依赖	输出格式
1	subagent	inherit	`src/plugins.ts`	—	统一diff + 一行说明
2	subagent	inherit	`tests/plugins.test.ts`	仅依赖拆分单元1的签名	测试文件 + 需求映射
3	main Agent	—	`src/cli.ts`	拆分单元1完成	（内联编写，不调度）

添加注释：

哪些拆分单元可立即并行处理（无阻塞依赖）
哪些拆分单元需要等待（依赖前置单元完成）
哪些拆分单元内联处理（主Agent执行，不调用子Agent）

模型列约定：

默认值为**
```
inherit
```
** ——子Agent使用主Agent当前运行的模型（可以是任何Claude模型、Codex/GPT-5.4，或未来的主Agent运行时模型）。不要默认硬编码Anthropic或OpenAI特定的模型名称。
仅在有明确理由时设置显式覆盖：
- 用户或主Agent指定了特定模型（例如，“对解析器拆分单元使用opus high”）
- 拆分单元涉及架构/高风险内容，需要比主Agent当前设置更强的推理模型和更高的算力
- 拆分单元是机械性样板代码，可安全切换到更快/更便宜的模型
覆盖内容使用主Agent可解析的中性表述（例如，
```
stronger reasoning model, xhigh effort
```
、
```
fast mechanical model
```
），除非用户指定了具体模型名称，否则不要使用特定模型名。
算力等级（若指定）从低到高：
```
low
```
→
```
medium
```
→
```
high
```
→
```
xhigh
```
。复杂/架构类拆分单元默认使用
xhigh
（运行时支持的最高等级）。
```
high
```
适用于中等复杂度任务；更低等级仅适用于机械性任务。

Handoff to Main Agent

移交主Agent执行

The main Agent executes the plan:

Parallel slices → single message with multiple
```
Agent
```
tool calls, each with
```
isolation: "worktree"
```
(since they're writing code)
Gated slices → run after their deps complete; main Agent serves as the relay (A's output → main Agent → B's context)
Inline slices → main Agent writes them directly

The skill does none of this — it only produced the plan.

主Agent按以下方式执行计划：

并行拆分单元 → 单条消息包含多个
```
Agent
```
工具调用，每个调用设置
```
isolation: "worktree"
```
（因为它们要编写代码）
需等待的拆分单元 → 在依赖完成后运行；主Agent作为中继（A的输出 → 主Agent → B的上下文）
内联拆分单元 → 主Agent直接编写

本技能仅生成计划，不执行任何上述操作。

Anti-patterns

反模式

❌ Returning a plan with overlapping file assignments — Step 3 must merge them
❌ Omitting the output format column — a slice without a format contract will dump context and waste the dispatch
❌ Forcing parallelism where the task is naturally serial — Step 1 should have terminated the skill
❌ Slicing too small just to have more parallelism — Step 4's size filter is not optional
❌ Attempting to coordinate subagents mid-flight via shared state — no current CLI runtime (Claude Code, Codex CLI, etc.) has an agent-to-agent channel; serialize through the main Agent or merge into a single-line task

❌ 返回存在重叠文件分配的计划 ——步骤3必须合并这些单元
❌ 省略输出格式列 ——无格式约定的拆分单元会返回冗余上下文，浪费调度资源
❌ 在天然串行的任务中强行并行 ——步骤1应终止技能执行
❌ 为了增加并行单元数量而过度拆分 ——步骤4的规模过滤是必须执行的
❌ 尝试通过共享状态在执行中协调子Agent ——当前CLI运行时（Claude Code、Codex CLI等）没有Agent间通信通道；通过主Agent按顺序执行，或合并为单一任务

Example invocation

调用示例

User: Code review surfaced three independent bugs. Fix all three in this PR:
      (A) cli.ts drops ESC cancellation errors in withEsc();
      (B) hooks.ts doesn't validate the `_marker` field on settings reads;
      (C) plugins.ts silently ignores marketplace fetch failures.
      Each has its own test.

Assistant (runs parallel-implementation):
  Step 1 (slice-ability): ✅ three bugs, three files, no cross-cutting
                          signature changes — fully independent
  Step 2 (assignments):
    A → src/cli.ts + tests/cli.test.ts
    B → src/hooks.ts + tests/hooks.test.ts
    C → src/plugins.ts + tests/plugins.test.ts
  Step 3 (collision check): no file appears twice; no merge needed
  Step 4 (size filter): each slice ~50–100 lines of changes — dispatch
  Step 5 (output contract): each subagent returns unified diff + a
                            one-sentence description of the bug it fixes
  Step 6 (plan):
    | Slice | Writer | Model | Files | Depends on | Output format |
    | A | subagent | inherit | src/cli.ts + tests     | — | diff + rationale |
    | B | subagent | inherit | src/hooks.ts + tests   | — | diff + rationale |
    | C | subagent | inherit | src/plugins.ts + tests | — | diff + rationale |
  Parallelizable now: A, B, C (no gating)

Main Agent:
  1. Dispatches A/B/C in parallel, each with isolation: "worktree"
  2. Merges returned diffs, runs the full regression suite

User: 代码评审发现三个独立的Bug。在本次PR中修复所有三个：
      (A) cli.ts的withEsc()方法丢弃了ESC取消错误；
      (B) hooks.ts在读取设置时未验证`_marker`字段；
      (C) plugins.ts静默忽略了市场拉取失败。
      每个Bug都有对应的测试。

Assistant（调用parallel-implementation）：
  步骤1（可拆分性）：✅ 三个Bug对应三个文件，无交叉签名变更——完全独立
  步骤2（分配方案）：
    A → src/cli.ts + tests/cli.test.ts
    B → src/hooks.ts + tests/hooks.test.ts
    C → src/plugins.ts + tests/plugins.test.ts
  步骤3（冲突检查）：无文件重复出现；无需合并
  步骤4（规模过滤）：每个拆分单元修改约50–100行——进行调度
  步骤5（输出约定）：每个子Agent返回统一diff + 一行描述修复的Bug
  步骤6（计划）：
    | 拆分单元 | 处理方 | 模型 | 文件 | 依赖 | 输出格式 |
    | A | subagent | inherit | src/cli.ts + tests     | — | diff + 说明 |
    | B | subagent | inherit | src/hooks.ts + tests   | — | diff + 说明 |
    | C | subagent | inherit | src/plugins.ts + tests | — | diff + 说明 |
  可立即并行处理：A、B、C（无依赖）

Main Agent:
  1. 并行调度A/B/C，每个调用设置isolation: "worktree"
  2. 合并返回的diff，运行完整回归测试套件

Relationship to other skills

与其他技能的关系

```
test-designer
```
→ may produce the failing tests whose green phase triggers this skill (upstream)
```
test-driven-development
```
→ governs when to enter green phase (upstream)
```
systematic-debugging
```
→ runs if any dispatched slice's result breaks regression (downstream)
```
verification-before-completion
```
→ gates "done" after all slices merge (downstream)

```
test-designer
```
→ 可能生成触发本技能的失败测试（上游）
```
test-driven-development
```
→ 控制何时进入修复阶段（上游）
```
systematic-debugging
```
→ 若任一调度单元的结果破坏回归测试则触发（下游）
```
verification-before-completion
```
→ 所有单元合并后验证任务是否完成（下游）