Initial skills documentation — 25 categories, all SKILL.md + references + scripts

2026-07-15 17:42:20 -04:00
commit 1b4fcd4427
976 changed files with 188344 additions and 0 deletions
@@ -0,0 +1,49 @@
+---
+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.