用途：面对多个彼此独立、可并行调查且不共享状态的问题（如不同的测试文件、互不相关的缺陷、分离的子系统）时，把工作委派给上下文隔离的子代理，从而保留自身上下文用于协调。
主要能力与判断标准：满足以下全部条件才派发——存在2个以上真正独立的问题；每个问题不依赖其他问题的上下文即可理解；代理不会编辑同一文件或依赖同一进行中的改动；否则会因上下文膨胀而损失 token。不应派发的场景包括：问题共享领域模型、schema 或核心工具（可能同一根因）；一个内聚功能被拆分（如注册+登录+重置+验证都涉及 User、中间件和 schema）；尚不清楚哪里坏了（探索性调试需要完整上下文）；任务一个代理由即可完成。文中提醒过度派发比派发不足更常见，建议每消息约3至4个代理，若想并行5个以上，多半说明它们并不真正独立。
使用方式（Claude Code）：并行不是特殊 Task() 函数，而是在同一条助手消息中发起多个 Agent 工具调用，由运行环境并发执行；跨消息逐个调用则按顺序执行。派发N个并行代理时，应把N个工具调用放在同一块中。子代理会自动加载 using-kisune 并因 <SUBAGENT-STOP> 跳过引导流程，直接执行指派任务；它不会再自动调用其他 kisune 技能，也没有对话记忆，提示词必须自包含。建议提示词包含四部分：目标（一句话）、上下文（文件路径、错误信息、既往尝试、意义）、约束（不得改动什么、范围边界）、期望输出（返回形式）。文中给出的示例目标为调查 src/auth/middleware.ts:42 在有效会话下抛出 token not found 的原因，约束为不要修改生产代码、仅定位根因，返回根因、具体行号和拟议修复。
代理返回后：批判性阅读摘要，用 diff 和状态而非报告来验证，运行 git status、git diff 并读取改动文件；检查跨代理冲突；集成后运行完整测试套件。若N个中1个失败，不要静默丢弃，应重新派发、自己接手或如实报告部分完成；不得声称整批成功。
限制与不适用：已知范围的查找直接用 Read/Grep；一次性工具执行不要包进代理；下一步由刚读到内容决定的短反应任务自己做；若你会给代理相同的上下文，派发只增加延迟而无隔离收益。若中途发现两个代理收敛到同一根因，应停止、合并为一个调查、待共享根因明确后再重新派发，避免沉没成本谬误。另与 completion-validation、brainstorming、spec-driven-implementation 等技能配合时，验证门禁以 diff 为准，Full 模式功能除非计划中任务明确独立，否则不要拆分执行。