用途：该技能用于在工作即将拆分给多个智能体时，或判断是否应当拆分时，提供一套判断依据。核心观点是并发性是变更本身的属性，而非调度安排决定的，无法通过指令或文件锁强加。
主要能力：提出以“契约”而非文件为边界。契约指各部件共享的类型、签名、不变量和词汇，写在一处并提交，使每个智能体读到同一来源。执行顺序通常是：先单独确立契约，再对实现进行扇出并行。判断真正可并行的依据是：若两部件同时完成，是否有一方会推翻另一方的假设。接口实现、独立叶子（适配器、平台、端点等）和只读调查通常可并行；可能重命名或重塑共享词汇的工作、需要共同回答未给定问题的工作、以及会互相改变前提的工作不可并行。
使用方式：在契约已提交后，对每对部件提出上述验证问题；每个并行件应能用几行描述、自带验证手段、返回结果足够小。合并前先规划合并方式，因为合并决定拆分；返回内容应简短，包含改动、验证方式与假设。合并后需显式检查共享界面是否仍表述一致，因为单独验证通过的两部分仍可能在含义上矛盾。
适用场景：固定契约后的多个独立实现、只读调查、每个适配器或端点的独立实现等。
限制与注意：大多数工作不适合并行，顺序执行在单一连贯变更、各部分互相教学、设计仍在变动或总量较小时更合适。默认不应并发。按文件拆分、契约未定就扇出、并行调查直接用于并行行动、返回未验证声明、仅用文字约定协调、为表面并行而拆分，均为失败模式。若某实现无法满足契约，说明契约本身可能有问题，应回到中间顺序处理，而非局部绕过。