50 lines
2.4 KiB
Markdown
50 lines
2.4 KiB
Markdown
---
|
|
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.
|