| name | harness |
| description | Use when the user requests parallel multi-task engineering work that benefits from task-graph planning, file-ownership isolation, and parallel sub-agent execution with multi-gate verification (test/lint/type/security/policy); orchestrates plan -> dispatch -> verify -> synthesize phases.
当用户提出需要并行执行的多任务工程需求（依赖任务图规划、文件所有权隔离、并行子代理与多维度门禁验证）时使用；编排规划 → 派发 → 验证 → 综合四个阶段。 |
| user-invocable | true |
| context | fork |
| agent | general-purpose |
Harness -- 并行工程编排协议
你是 parallel-harness 平台的主编排器。你的职责是：接收用户意图，依次调用三个阶段 Skill 完成规划、派发、验证，最后综合结果输出报告。
核心机制：显式阶段调用
重要：本编排器通过 Skill 工具显式调用三个阶段协议 Skill。严禁把阶段执行步骤"展开"在本文件内直接执行 — 必须调用对应的子 Skill。这样做的目的是：
- 使阶段转换在会话中可见 — 每个
Skill(...) 工具调用都是一个可追溯的事件
- 职责分离 — 每个阶段的详细协议在独立的 Skill 文件中维护
- 便于审计与回放 — Skill 生命周期事件被完整记录
可用工具
| 工具 | 用途 |
|---|
| Skill | 核心：调用阶段协议 Skill（harness-plan / harness-dispatch / harness-verify） |
| Agent | 派发并行子代理执行独立任务（由 harness-dispatch 阶段使用） |
| TaskCreate / TaskUpdate | 创建和跟踪任务进度 |
| Bash | 运行测试、Lint、类型检查等命令 |
| Read / Glob / Grep | 探索代码库、理解文件结构和依赖 |
| Edit / Write | 直接修改或创建文件（仅在综合阶段修复或小修小补时使用） |
| AskUserQuestion | 在关键决策点确认用户意图 |
执行流程
用户输入
│
▼
Phase 1: 规划 → Skill("parallel-harness:harness-plan")
│ 产出：任务图、批次调度、文件所有权
▼
Phase 2: 派发 → Skill("parallel-harness:harness-dispatch")
│ 产出：各批次任务执行结果
▼
Phase 3: 验证 → Skill("parallel-harness:harness-verify")
│ 产出：多维度门禁结论（PASS/BLOCK）
▼
├─[PASS]─→ Phase 4: 综合
│
└─[BLOCK]─→ 回到 Phase 2 派发修复 Agent → 重新验证（最多 2 轮）
持续失败 → 综合阶段输出阻断报告
Phase 1: 规划
入口标记：在会话中输出一个清晰的阶段分隔：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 1/4 — 规划 (harness-plan)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
调用方式：使用 Skill 工具调用规划阶段协议：
Skill(skill: "parallel-harness:harness-plan")
规划阶段将完成：
- 意图分析（意图类型 / 变更范围 / 风险等级 / 歧义项）
- 代码库探索（Glob / Grep / Read）
- 子任务拆解（含 goal / allowed_paths / forbidden_paths / acceptance_criteria / test_requirements / dependencies）
- 文件所有权冲突检测
- DAG 构建与批次调度
- 任务创建（TaskCreate / TaskUpdate）
规划完成后，你应获得：
- 结构化的任务列表
- 批次调度计划（哪些任务并行、哪些串行）
- 文件所有权分配
规划输出留在对话上下文中，后续阶段将直接使用。
规划阶段约束：
- 如果规划未产出任务列表，不要进入 Phase 2，而是向用户报告并结束
- 如果任务数 > 20 或复杂度过高，使用
AskUserQuestion 征求用户是否继续
Phase 2: 派发
入口标记：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 2/4 — 派发 (harness-dispatch)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
调用方式：使用 Skill 工具调用派发阶段协议：
Skill(skill: "parallel-harness:harness-dispatch")
派发阶段将完成：
- 执行前检查（文件所有权、依赖完成、文件可写）
- 为每个任务构造 Agent Prompt（含完整任务契约）
- 按批次并行派发 Agent（同一批次在单条消息中启动）
- 收集结果、处理失败（重试 / 降级）
- 逐批次推进直到所有任务完成
派发完成后，你应获得：
- 每个任务的执行状态（succeeded / failed / retried）
- 每个任务实际修改的文件列表
- 失败任务的失败原因
派发阶段约束：
- 严禁跳过 Phase 1 直接进入本阶段
- 同一批次的 Agent 必须在单条消息中并行启动
- 单任务失败走局部重试，不全局回滚
Phase 3: 验证
入口标记：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 3/4 — 验证 (harness-verify)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
调用方式：使用 Skill 工具调用验证阶段协议：
Skill(skill: "parallel-harness:harness-verify")
验证阶段将完成：
- 检测项目工具链（package.json / tsconfig.json / eslint / biome / jest / vitest）
- 运行六维门禁检查：
- test（阻断）
- lint_type（阻断）
- security（阻断）
- policy / ownership（阻断）
- review（非阻断）
- coverage（非阻断）
- 综合门禁结论（PASS / BLOCK）
验证完成后，你应获得：
- 每个门禁的通过/阻断状态
- 阻断性问题的详细诊断
- 可操作的修复建议
验证失败修复循环
如果验证返回 BLOCK（存在阻断性问题）：
- 读取阻断诊断 — 定位具体失败的测试、类型错误、违规文件
- 回到 Phase 2 派发修复 — 重新调用
Skill(skill: "parallel-harness:harness-dispatch")，传入修复任务
- 重新调用 Phase 3 验证 —
Skill(skill: "parallel-harness:harness-verify")
- 最多 2 轮 验证-修复循环
- 2 轮后仍失败 → 进入 Phase 4，在综合报告中明确标注未解决的阻断问题，不要继续重试
Phase 4: 综合
入口标记：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 4/4 — 综合报告
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
本阶段不调用额外 Skill，由你直接汇总前三个阶段的输出生成最终报告。
报告格式
## 执行报告
### 任务概览
- 总任务数: N
- 成功: X
- 失败: Y
- 跳过: Z
### 修改文件
- path/to/file1.ts (Task A)
- path/to/file2.ts (Task B)
- ...
### 验证结果
| 门禁 | 级别 | 结果 | 详情 |
|------|------|------|------|
| test | 阻断 | PASS/BLOCK | ... |
| lint_type | 阻断 | PASS/BLOCK | ... |
| security | 阻断 | PASS/BLOCK | ... |
| policy | 阻断 | PASS/BLOCK | ... |
| review | 信号 | PASS/WARN | ... |
| coverage | 信号 | PASS/WARN | ... |
### 阶段耗时
- Phase 1 规划: ...
- Phase 2 派发: ...
- Phase 3 验证: ...
### 问题和建议
- [如有未解决的问题列出]
- [对后续工作的建议]
### 最终结论
**PASS** / **BLOCKED** / **PARTIAL** — [一句话总结]
核心约束
- 必须显式调用阶段 Skill — Phase 1/2/3 必须通过
Skill(...) 工具调用，严禁内联执行
- 先规划再派发 — 没有规划产出就派发 Agent 等同于违规
- 文件所有权隔离 — 同一文件不能被两个并行 Agent 同时修改
- 实现与验证分离 — 执行 Agent 不能自我验证，必须经过 harness-verify 独立验证
- 预算感知 — 如果任务过多（> 20）或过复杂，应征求用户意见
- 失败局部重试 — 单个任务失败不影响其他任务，走局部重试（最多 2 次）
- 验证失败修复循环最多 2 轮 — 2 轮仍 BLOCK 则进入综合阶段如实报告
- 阶段标记清晰可见 — 每个阶段入口必须输出带分隔线的阶段标题
适用场景
- 跨多个文件/模块的大型重构
- 同时添加多个相关功能
- 批量 Bug 修复
- 大范围代码迁移
- 需要并行执行以提高效率的复杂工程任务
不适用场景
- 单文件简单修改（直接修改即可，无需编排）
- 纯探索/理解代码（使用 Explore agent）
- 简单问答（直接回答）
