{"repo":"NousResearch/hermes-agent","public_id":"22897","display_label":"Docs: clarify kanban fan-out decomposition","summary":"Multiple closely related pull requests aimed at improving documentation clarity around kanban orchestrator fan-out decomposition in skills. The members appear to represent iterations or salvage attempts of the same documentation change.","subsystem":null,"counts":{"members":3,"open_issues":0,"open_issues_distinct":0,"open_prs":0,"closed_issues":1,"merged_prs":1,"attempt_prs":1},"landed_fix":{"status":"merged_to_main","basis":"structural","pr":22939,"merged_at":"2026-05-10T02:31:14+00:00"},"resolution":{"state":"resolved","by":"pr-22939"},"freshness":{"state":"verified","last_verified_at":"2026-05-10T02:31:14+00:00","is_stale":false},"grouping":{"backbone":"STRUCTURAL_SPANNING","link_density":0.6666666666666666},"fix_edges":[{"issue_number":22897,"pr_number":22939,"tier":"verified","basis":"closing_ref","confidence":0.95,"recoverable_from_timeline":true,"pr_merged_at":"2026-05-10T02:31:14+00:00"}],"members":[{"kind":"issue","number":22897,"title":"docs(skills): clarify kanban orchestrator fan-out decomposition","url":null,"state":"closed"},{"kind":"pr","number":22898,"title":"docs(skills): clarify kanban fan-out decomposition","url":null,"state":"closed","close_reason":{"refs":[{"kind":"pr","value":"#22939","number":22939}],"category":"merged_via","implication":"superseded"},"merged":false},{"kind":"pr","number":22939,"title":"docs(skills): clarify kanban fan-out decomposition (salvage #22898)","url":null,"state":"merged","close_reason":{"category":"merged"},"merged":true,"is_fix_pr":true,"fix_tier":"verified","files_changed":["scripts/release.py","skills/devops/kanban-orchestrator/SKILL.md"],"fix_hunks":[{"file":"scripts/release.py","hunks":["@@ -841,6 +841,7 @@\n     \"[redacted:email]\": \"0xharryriddle\",\n     \"[redacted:email]\": \"lhysdl\",\n     \"[redacted:email]\": \"SherlockShemol\",\n+    \"[redacted:email]\": \"eloklam\",\n     \"[redacted:email]\": \"fmercurio\",\n     \"[redacted:email]\": \"Ricardo-M-L\",\n     \"[redacted:email]\": \"leozeli\","]},{"file":"skills/devops/kanban-orchestrator/SKILL.md","hunks":["@@ -32,6 +32,8 @@ Your job description says \"route, don't execute.\" The rules that enforce that:\n \n - **Do not execute the work yourself.** Your restricted toolset usually doesn't even include terminal/file/code/web for implementation. If you find yourself \"just fixing this quickly\" — stop and create a task for the right specialist.\n - **For any concrete task, create a Kanban task and assign it.** Every single time.\n+- **Split multi-lane requests before creating cards.** A user prompt can contain several independent workstreams. Extract those lanes first, then create one card per lane instead of bundling unrelated work into a single implementer card.\n+- **Run independent lanes in parallel.** If two cards do not need each other's output, leave them unlinked so the dispatcher can fan them out. Link only true data dependencies.\n - **If no specialist fits, ask the user which profile to create.** Do not default to doing it yourself under \"close enough.\"\n - **Decompose, route, and summarize — that's the whole job.**\n ","@@ -58,7 +60,24 @@ Ask clarifying questions if the goal is ambiguous. Cheap to ask; expensive to sp\n \n ### Step 2 — Sketch the task graph\n \n-Before creating anything, draft the graph out loud (in your response to the user). Example for \"Analyze whether we should migrate to Postgres\":\n+Before creating anything, draft the graph out loud (in your response to the user). Treat every concrete workstream as a candidate card:\n+\n+1. Extract the lanes from the request.\n+2. Assign each lane to the best specialist.\n+3. Decide whether each lane is independent or gated by another lane.\n+4. Create independent lanes as parallel cards with no parent links.\n+5. Create synthesis/review/integration cards with parent links to the lanes they depend on.\n+\n+Examples of prompts that should fan out:\n+\n+- \"Build an app\" -> `designer` for product/UI direction and `frontend-eng` or `backend-eng` for implementation, with a later integration/review card if needed.\n+- \"Fix blockers and check model variants\" -> one implementation card for the blocker fixes plus one discovery/research card for config/source verification. A final reviewer card can depend on both.\n+- \"Research docs and implement\" -> a docs-research card can run in parallel with a codebase-discovery card; implementation waits only if it truly needs those findings.\n+- \"Analyze this screenshot and find the related code\" -> `observer` handles visual analysis while an explorer-style profile searches the codebase.\n+\n+Words like \"also,\" \"finally,\" or \"and\" do not automatically imply a dependency. They often mean \"make sure this is covered before reporting back.\" Only link tasks when one card cannot start until another card's output exists.\n+\n+Example for \"Analyze whether we should migrate to Postgres\":\n \n ```\n T1  researcher        research: Postgres cost vs current","@@ -136,6 +155,8 @@ Tell them what you created in plain prose:\n \n **Fan-out + fan-in (research → synthesize):** N `researcher` tasks with no parents, one `analyst` task with all of them as parents.\n \n+**Parallel implementation + validation:** one implementer card makes the change while one explorer/researcher card verifies config, docs, or source mapping. A reviewer card can depend on both. Do not make the implementer own unrelated verification just because the user mentioned both in one sentence.\n+\n **Pipeline with gates:** `pm → backend-eng → reviewer`. Each stage's `parents=[previous_task]`. Reviewer blocks or completes; if reviewer blocks, the operator unblocks with feedback and respawns.\n \n **Same-profile queue:** 50 tasks, all assigned to `translator`, no dependencies between them. Dispatcher serializes — translator processes them in priority order, accumulating experience in their own memory.","@@ -144,6 +165,12 @@ Tell them what you created in plain prose:\n \n ## Pitfalls\n \n+**Bundling independent lanes into one card.** If the user asks for two independent outcomes, create two cards. Example: \"fix blockers and check model variants\" is not one fixer task; create a fixer/engineer card for the fixes and an explorer/researcher card for the variant check, then optionally gate review on both.\n+\n+**Over-linking because of wording.** \"Finally check X\" may still be parallel with implementation if X is static config, docs, or source discovery. Link it after implementation only when the check depends on the implementation result.\n+\n+**Forgetting dependency links.** If the task graph says `research -> implement -> review`, do not create all tasks as independent ready cards. Use parent links so implement/review cannot run before their inputs exist.\n+\n **Reassignment vs. new task.** If a reviewer blocks with \"needs changes,\" create a NEW task linked from the reviewer's task — don't re-run the same task with a stern look. The new task is assigned to the original implementer profile.\n \n **Argument order for links.** `kanban_link(parent_id=..., child_id=...)` — parent first. Mixing them up demotes the wrong task to `todo`.\n"]}]}],"trust":{"default_tier":"verified","includes_suggested":false}}