---
name: kanban-collaboration
description: "Umbrella for Hermes Kanban collaboration: orchestrator decomposition, worker lifecycle pitfalls, task graph routing, and board hygiene."
version: 1.0.0
author: Hermes Agent
license: MIT
platforms: [linux, macos, windows]
metadata:
  hermes:
    tags: [kanban, orchestration, workers, task-graph, multi-agent]
    related_skills: [kanban-orchestrator, kanban-worker, hermes-agent]
---

# Kanban Collaboration

Use this umbrella when operating Hermes' durable Kanban board for multi-agent or multi-profile work. It covers both orchestrator behavior (decompose and route work) and worker behavior (execute an assigned card safely and report completion/blockers).

## Orchestrator responsibilities

- Decide whether the board is warranted; do not route trivial single-agent tasks through Kanban.
- Understand the goal and constraints before creating cards.
- Sketch a task graph with dependencies, not a flat TODO dump.
- Create small, independently verifiable cards with clear acceptance criteria.
- Assign to profiles based on user-configured roles/capabilities; do not assume a fixed roster.
- Resist doing worker tasks yourself. The orchestrator's job is decomposition, routing, monitoring, and integration.

## Worker responsibilities

- Treat the assigned card and board context as the source of truth.
- Work in the assigned workspace/tenant; do not bleed state across tenants.
- If creating follow-up cards, capture returned IDs before linking/claiming them.
- Complete only when acceptance criteria are met and evidence is attached.
- Block quickly with actionable reasons when credentials, permissions, missing context, or upstream dependencies prevent progress.

## Task graph hygiene

- Link dependencies explicitly.
- Keep cards narrow enough to verify but broad enough not to create micro-task noise.
- Use comments for discoveries that future workers need.
- Reclaim or unblock stale tasks only after checking recent activity.
- Summaries should include files changed, commands run, artifacts produced, and remaining risks.

## Good block reasons

A block reason should allow the orchestrator/user to act immediately: missing API key name, inaccessible repository/path, ambiguous product decision, failing upstream card, or unavailable service. Avoid vague 'could not proceed' messages.

## Verification

The board is durable; verify by reading cards/comments/links back after creating, updating, completing, blocking, or linking tasks.