# Parallel Run Output Templates

Use these for per-task verdicts (Step 7) and run summaries (Step 8).

## Per-task verdict

```markdown
# Task {n} Verdict — {short task title}

**Type:** {dev|research|debug|docs|review|security|quick|complex}
**Phase mode:** {prototype|production}
**Team:** {list of roles}
**Status:** {complete-consensus | complete-divergent | complete-single-source | failed}

## Result

{1-2 sentences summarizing what was done / found}

## Agent verdicts

| Role | Verdict | Brief |
|------|---------|-------|
| builder (Claude) | PASS | <one line> |
| code-reviewer (Claude) | CONCERNS | <one line> |
| code-reviewer (Codex) | PASS | <one line> |

## Disagreements (if any)

- Claude code-reviewer flagged X as a concern; Codex did not. Reason for divergence: <agent explanation>
- Recommendation: <manual review | accept Claude | accept Codex | re-dispatch>

## Artifacts

- `.forge/parallel/{run-id}/task-{n}/builder.md`
- `.forge/parallel/{run-id}/task-{n}/code-reviewer-claude.md`
- `.forge/parallel/{run-id}/task-{n}/code-reviewer-codex.md`
- `.forge/parallel/{run-id}/task-{n}/followups.md` (if any)

## Followups (if any)

- <item> — owner: <user | next parallel run | /forge-evolve>
```

## Run summary

```markdown
# Parallel Run {run-id}

**Started:** {ISO-8601}
**Completed:** {ISO-8601}
**Phase mode:** {prototype|production|ambiguous}
**Codex consent:** {verify|takeover|skip|never}

## Input

{verbatim user prompt or task list}

## Classification

| # | Task | Type | Routed |
|---|------|------|--------|
| 1 | Update README | docs | — |
| 2 | Explore caching options | research | — |
| 3 | Implement payment integration | command:/feature | ✅ routed |
| ... | ... | ... | ... |

## Outcomes

| # | Status | Team size | Conflicts | Followups |
|---|--------|-----------|-----------|-----------|
| 1 | consensus | 1 | — | — |
| 2 | consensus | 3 | — | — |
| 4 | divergent | 2 | Claude PASS, Codex CONCERNS | manual review |
| 5 | failed | 1 | both agents timed out | retry |

## Routed to commands

- Item 3 → `/feature` (run when ready)

## Followup actions

1. Resolve divergence on task 4 (recommend manual review of file X)
2. Retry task 5 (consider /bugfix if recurring)
3. Invoke `/feature` for routed item 3

## Stats

- Tasks: {N}
- Routed: {M}
- Executed: {N - M}
- Total agents dispatched: {K}
- Wall time: {minutes}
- Cells with Claude+Codex consensus: {X}/{N - M}
- Cells with divergence: {Y}/{N - M}

## Next steps

If divergence > 30%, sample-check a few team outputs — your classifier or team-assembly might be miscalibrated.

If all tasks PASSED with no divergence, run a `/forge-evolve` to consider whether patterns recurred enough to warrant capturing as a gotcha or rule.
```

## Severity / verdict definitions

Per-agent verdict vocabulary:

- **PASS** — task done as specified, no concerns
- **CONCERNS** — done with caveats; followups recommended but not blocking
- **FAIL** — task could not be completed (blocked, unknown, hit error)

Per-task status:

- **complete-consensus** — all team members agree PASS or all agree CONCERNS
- **complete-divergent** — team members disagree (e.g., PASS vs FAIL); user should adjudicate
- **complete-single-source** — only one agent returned; use with caution
- **failed** — multiple agents failed; task did not complete

## When to escalate to a command

After run summary, if any task is `complete-divergent` AND the divergence is over a load-bearing question (security, data-loss, contract change), recommend escalating:

- Dev task with divergent verdicts → `quality-code-review` skill standalone for that change
- Debug task with divergent verdicts → `support-debug` skill standalone
- Research task with divergent verdicts → user adjudication required

`/parallel` is for parallel speed. When agreement breaks down, the right tool is depth, not parallelism.
