Team

Team

This is a Hermes-native team workflow skill.

Why This Exists

team exists to keep execution work explicit, evidence-backed, and inside the Hermes/executor boundary instead of relying on ad hoc chat narration.

Do Not Use When

• An accepted implementation plan with disjoint files, criteria, and commands is ready for parallel delivery; use ultrawork.
• The request is a settings-only change, one bounded edit that is explicitly low-risk and has a direct owner and verification path, or a direct answer/diagnosis; use one direct owner instead of coordinating workers.

Examples

Good example:

• Prompt: team: coordinate parallel agents for frontend polish, copy polish, and QA with worker ACKs.
• Expected behavior: Assign lanes, require worker ACK/result evidence, and keep integration verification separate.
• Why: The work benefits from multiple coordinated workers with disjoint ownership.

Bad example:

• Prompt: team: treat casual chat or unaccepted work as if this workflow already produced verified results.
• Expected behavior: Ask a clarification question or route to a narrower workflow instead of forcing team.
• Why: The request lacks the required inputs or would overclaim work that Hermes did not observe.

Completion Checklist

• Each lane has an owner, disjoint scope, expected output, and verification target.
• Worker ACK, dispatch, result, integration, and verification evidence are separated when wrappers record them.
• Hermes-owned coding teams use hermes_coding_harness/v1 so builder, verifier, reviewer, docs, and PR lanes stay distinct even in solo mode.
• The integrated status names which lanes are observed, blocked, or still prepared_not_observed.

Recovery Notes

• If two lanes are not independent, collapse them under one owner or re-plan before dispatch.
• If a worker has no ACK or result, mark that lane not_observed or blocked rather than infer progress.
• If integration reveals a shared-file conflict, stop lane fan-out and reassign ownership before continuing.