hermes - 💡(How to fix) Fix docs(skills): clarify kanban orchestrator fan-out decomposition

Summary

kanban-orchestrator documents the basic durable-workflow pattern, but it does not explicitly tell orchestrator profiles to split multi-clause prompts into independent parallel workstreams before creating cards. That makes it easy for an orchestrator to collapse unrelated work into one implementation card.

Example failure mode:

User: Fix these blockers. Finally, check whether model variants like thinking / fast mode match our setup.

A naive orchestrator may create one fixer card for the blocker fixes, then do the model/config verification itself or bury that verification inside the fixer task. In an OMO-style workflow these are two independent lanes:

T1  fixer / engineer      fix the blockers
T2  explorer / researcher verify model/config/source mapping       parallel with T1
T3  reviewer              final consistency review                 parents: T1, T2

Why this matters

Kanban's value is durable fan-out / fan-in. If the skill only says "create tasks" without warning about independent lanes, orchestrator profiles lose that parallelism and produce weaker audit trails:

• implementation work owns unrelated verification
• static config/source checks wait unnecessarily behind edits
• final review lacks explicit parent handoffs
• users cannot see which lane produced which result

This is especially visible when adapting OMO / multi-agent workflows where design, implementation, research, validation, and review should often run as separate cards.

Proposed docs fix

Update skills/devops/kanban-orchestrator/SKILL.md to make decomposition explicit:

1. Add an anti-temptation rule to split multi-lane requests before card creation.
2. Add a task-graph checklist:
   • extract lanes
   • assign each lane to a specialist
   • decide whether each lane is independent or gated
   • leave independent lanes unlinked so they can run in parallel
   • link only true dependencies
3. Add examples:
   • "Build an app" -> design + implementation lanes
   • "Fix blockers and check model variants" -> implementation + verification lanes
   • "Research docs and implement" -> docs research + codebase discovery, with implementation gated only if needed
   • screenshot analysis + code search -> observer + explorer in parallel
4. Add pitfalls for bundling independent lanes into one card and over-linking because of wording like "finally".

Scope

Docs/skill-only. No Kanban database, dispatcher, CLI, or worker-tool behavior change in this issue. A later feature can add a plan -> create graph -> dispatch helper, but this issue only teaches the existing orchestrator skill the recommended decomposition pattern.

Validation

• Skill frontmatter still parses
• Skill size remains within limits
• Skill-manager tests pass