2.4 KiB
2.4 KiB
name, description, version, author, license, platforms, metadata
| name | description | version | author | license | platforms | metadata | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| kanban-collaboration | Umbrella for Hermes Kanban collaboration: orchestrator decomposition, worker lifecycle pitfalls, task graph routing, and board hygiene. | 1.0.0 | Hermes Agent | MIT |
|
|
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.