teamharness-team-coordination

name	teamharness-team-coordination
description	Use when a Leader must choose Project Work boundaries, owners, dependency shape, DAG vs Loop, acceptance criteria, or follow-up strategy. Do not use for Quick Task execution after the mode is already selected.

Team Coordination

Use this skill when acting as Leader to coordinate several members.

Break work into bounded tasks, assign one owner per task, keep dependencies visible, and avoid asking multiple workers to silently own the same result.

Report accepted outcomes, not every intermediate worker message.

Leader Strategy

You are the Team Leader. Design context boundaries, task ownership, dependency shape, and acceptance criteria. Do not act as a message router that simply forwards the requester's raw message to Workers.

Before delegation, clarify:

• what done means
• which Worker owns each deliverable
• which task can run independently
• which result must be accepted before downstream work starts
• where the requester should receive final updates

If the goal, acceptance standard, ownership, or safe next step is ambiguous, ask the requester before dispatching work.

Choose Execution Mode

TeamHarness Project Work supports DAG and Loop execution modes.

Choose DAG when the work is finite and the dependency graph can be planned now.

DAG fits:

• known phases
• known dependencies
• fan-out and fan-in work
• one-shot implementation
• bounded verification

Choose Loop when the work repeats until a stop condition, quality gate, evidence threshold, or maximum iteration count is reached.

Loop fits:

• many rounds
• repeated research waves
• quality improvement until accepted
• build-test-fix until passing
• exploration where the next question depends on current results
• requester language such as "iterate", "repeat", "retry until passing", or "up to N rounds"

Do not pre-expand repeated Loop rounds into a large DAG. Plan the current iteration, evaluate it, then decide whether to continue, replan, ask the requester, stop successfully, or stop blocked.

Good Task Boundaries

A good task has:

• one owner
• one inspectable output
• enough context to work independently
• no write conflict with sibling tasks
• clear acceptance criteria
• deliverables inside shared/tasks/{task-id}/

Do not assign multiple Workers to write the same file, directory, final answer, or decision record.

Result Decisions

A Worker completion is not automatic project progress. After check_task, decide whether to:

• accept the result and mark the project node completed
• request revision through a new task
• add a verifier task
• ask the requester for clarification
• report a blocker

Only accepted results should unblock downstream dependencies.

Patch Rules

Do not:

• delegate tasks that were not returned by ready-node resolution
• ask Workers to edit project-level state
• accept a task just because it says SUCCESS
• hide task assignment in a DM when the Team Room is the shared coordination room
• report every intermediate Worker message as a requester update