[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C391VVX5TDF0Z2BYVBD12C":3,"skill-same:01M6C391VVX5TDF0Z2BYVBD12C":93},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":50,"linkOnly":51,"markdownContent":52,"markdownBody":53,"frontMatter":54,"refName":62,"commitSha":63,"skillDirectory":64,"forksCount":65,"repositoryHtmlUrl":66,"repositoryHomepageUrl":6,"ownerHtmlUrl":67,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":68,"install":69,"resources":82},"01M6C391VVX5TDF0Z2BYVBD12C","kanban-orchestrator",null,"Decomposition playbook + anti-temptation rules for an orchestrator profile routing work through Kanban. The \"don't do the work yourself\" rule and the basic lifecycle are auto-injected into every kanban worker's system prompt; this skill is the deeper playbook when you're specifically playing the orchestrator role.","jleechanorg\u002Fjleechan-skills","jleechanorg","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F221404966?v=4","01M6C1VJ99XG950X1DWPEBCBGX","01M6C1VJDK5YVDNT3362RT5WSB",6,"MIT","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fdevops\u002Fkanban-orchestrator\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49],"kanban","kanban orchestrator","orchestrator","when","macos","for","re","you","system prompt","decomposition","worker","deeper","do","kanban worker","auto","profile","prompt","work","Rules","multi-agent","system","lifecycle","playbook","routing","windows","orchestration","linux","2026-11-10 10:12:30",false,"---\nname: kanban-orchestrator\ndescription: Decomposition playbook + anti-temptation rules for an orchestrator profile routing work through Kanban. The \"don't do the work yourself\" rule and the basic lifecycle are auto-injected into every kanban worker's system prompt; this skill is the deeper playbook when you're specifically playing the orchestrator role.\nversion: 3.0.0\nplatforms: [linux, macos, windows]\nmetadata:\n  hermes:\n    tags: [kanban, multi-agent, orchestration, routing]\n    related_skills: [kanban-worker]\n---\n\n# Kanban Orchestrator — Decomposition Playbook\n\n> The **core worker lifecycle** (including the `kanban_create` fan-out pattern and the \"decompose, don't execute\" rule) is auto-injected into every kanban process via the `KANBAN_GUIDANCE` system-prompt block. This skill is the deeper playbook when you're an orchestrator profile whose whole job is routing.\n\n## Profiles are user-configured — not a fixed roster\n\nHermes setups vary widely. Some users run a single profile that does everything; some run a small fleet (`docker-worker`, `cron-worker`); some run a curated specialist team they've named themselves. There is **no default specialist roster** — the orchestrator skill does not know what profiles exist on this machine.\n\nBefore fanning out, you must ground the decomposition in the profiles that actually exist. The dispatcher silently fails to spawn unknown assignee names — it doesn't autocorrect, doesn't suggest, doesn't fall back. So a card assigned to `researcher` on a setup that only has `docker-worker` just sits in `ready` forever.\n\n**Step 0: discover available profiles before planning.**\n\nUse one of these:\n\n- `hermes profile list` — prints the table of profiles configured on this machine. Run it through your terminal tool if you have one; otherwise ask the user.\n- `kanban_list(assignee=\"\u003Csome-name>\")` — sanity-check a single name. Returns an empty list (rather than an error) for an unknown assignee, so this only confirms a name you're already considering.\n- **Just ask the user.** \"What profiles do you have set up?\" is a fine first turn when the goal needs more than one specialist.\n\nCache the result in your working memory for the rest of the conversation. Re-asking every turn wastes a tool call.\n\n## When to use the board (vs. just doing the work)\n\nCreate Kanban tasks when any of these are true:\n\n1. **Multiple specialists are needed.** Research + analysis + writing is three profiles.\n2. **The work should survive a crash or restart.** Long-running, recurring, or important.\n3. **The user might want to interject.** Human-in-the-loop at any step.\n4. **Multiple subtasks can run in parallel.** Fan-out for speed.\n5. **Review \u002F iteration is expected.** A reviewer profile loops on drafter output.\n6. **The audit trail matters.** Board rows persist in SQLite forever.\n\nIf *none* of those apply — it's a small one-shot reasoning task — use `delegate_task` instead or answer the user directly.\n\n## The anti-temptation rules\n\nYour 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\u002Ffile\u002Fcode\u002Fweb 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 the available profiles, ask the user which profile to create or which existing profile to use.** Do not invent profile names; the dispatcher will silently drop unknown assignees.\n- **Decompose, route, and summarize — that's the whole job.**\n\n## Decomposition playbook\n\n### Step 1 — Understand the goal\n\nAsk clarifying questions if the goal is ambiguous. Cheap to ask; expensive to spawn the wrong fleet.\n\n### Step 2 — Sketch the task graph\n\nBefore creating anything, draft the graph out loud (in your response to the user). Treat every concrete workstream as a candidate card:\n\n1. Extract the lanes from the request.\n2. Map each lane to one of the profiles you discovered in Step 0. If a lane doesn't fit any existing profile, ask the user which to use or create.\n3. Decide whether each lane is independent or gated by another lane.\n4. Create independent lanes as parallel cards with no parent links.\n5. Create synthesis\u002Freview\u002Fintegration cards with parent links to the lanes they depend on.\n\nExamples of prompts that should fan out (using placeholder profile names — substitute whatever exists on the user's setup):\n\n- \"Build an app\" → one card to a design-oriented profile for product\u002FUI direction, one or two cards to engineering profiles for implementation, plus a later integration\u002Freview card if the user has a reviewer profile.\n- \"Fix blockers and check model variants\" → one implementation card for the blocker fixes plus one discovery\u002Fresearch card for config\u002Fsource 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\" → one card to a vision-capable profile for the visual analysis while another searches the codebase.\n\nWords 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\nShow the graph to the user before creating cards. Let them correct it — including which actual profile name should own each lane.\n\n### Step 3 — Create tasks and link\n\nUse the profile names from Step 0. The example below uses placeholders `\u003Cprofile-A>`, `\u003Cprofile-B>`, `\u003Cprofile-C>` — replace them with what the user actually has.\n\n```python\nt1 = kanban_create(\n    title=\"research: Postgres cost vs current\",\n    assignee=\"\u003Cprofile-A>\",  # whichever profile handles research on this setup\n    body=\"Compare estimated infrastructure costs, migration costs, and ongoing ops costs over a 3-year window. Sources: AWS\u002FGCP pricing, team time estimates, current Postgres bills from peers.\",\n    tenant=os.environ.get(\"HERMES_TENANT\"),\n)[\"task_id\"]\n\nt2 = kanban_create(\n    title=\"research: Postgres performance vs current\",\n    assignee=\"\u003Cprofile-A>\",  # same profile, run in parallel\n    body=\"Compare query latency, throughput, and scaling characteristics at our expected data volume (~500GB, 10k QPS peak). Sources: benchmark papers, public case studies, pgbench results if easy.\",\n)[\"task_id\"]\n\nt3 = kanban_create(\n    title=\"synthesize migration recommendation\",\n    assignee=\"\u003Cprofile-B>\",  # whichever profile does synthesis\u002Fanalysis\n    body=\"Read the findings from T1 (cost) and T2 (performance). Produce a 1-page recommendation with explicit trade-offs and a go\u002Fno-go call.\",\n    parents=[t1, t2],\n)[\"task_id\"]\n\nt4 = kanban_create(\n    title=\"draft decision memo\",\n    assignee=\"\u003Cprofile-C>\",  # whichever profile drafts user-facing prose\n    body=\"Turn the analyst's recommendation into a 2-page memo for the CTO. Match the tone of previous decision memos in the team's knowledge base.\",\n    parents=[t3],\n)[\"task_id\"]\n```\n\n`parents=[...]` gates promotion — children stay in `todo` until every parent reaches `done`, then auto-promote to `ready`. No manual coordination needed; the dispatcher and dependency engine handle it.\n\n### Step 4 — Complete your own task\n\nIf you were spawned as a task yourself (e.g. a planner profile was assigned `T0: \"investigate Postgres migration\"`), mark it done with a summary of what you created:\n\n```python\nkanban_complete(\n    summary=\"decomposed into T1-T4: 2 research lanes in parallel, 1 synthesis on their outputs, 1 prose draft on the recommendation\",\n    metadata={\n        \"task_graph\": {\n            \"T1\": {\"assignee\": \"\u003Cprofile-A>\", \"parents\": []},\n            \"T2\": {\"assignee\": \"\u003Cprofile-A>\", \"parents\": []},\n            \"T3\": {\"assignee\": \"\u003Cprofile-B>\", \"parents\": [\"T1\", \"T2\"]},\n            \"T4\": {\"assignee\": \"\u003Cprofile-C>\", \"parents\": [\"T3\"]},\n        },\n    },\n)\n```\n\n### Step 5 — Report back to the user\n\nTell them what you created in plain prose, naming the actual profiles you used:\n\n> I've queued 4 tasks:\n> - **T1** (`\u003Cprofile-A>`): cost comparison\n> - **T2** (`\u003Cprofile-A>`): performance comparison, in parallel with T1\n> - **T3** (`\u003Cprofile-B>`): synthesizes T1 + T2 into a recommendation\n> - **T4** (`\u003Cprofile-C>`): turns T3 into a CTO memo\n>\n> The dispatcher will pick up T1 and T2 now. T3 starts when both finish. You'll get a gateway ping when T4 completes. Use the dashboard or `hermes kanban tail \u003Cid>` to follow along.\n\n## Common patterns\n\n**Fan-out + fan-in (research → synthesize):** N research-style cards with no parents, one synthesis card with all of them as parents.\n\n**Parallel implementation + validation:** one implementer card makes the change while one explorer\u002Fresearcher 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:** `planner → implementer → 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:** N tasks, all assigned to the same profile, no dependencies between them. Dispatcher serializes — that profile processes them in priority order, accumulating experience in its own memory.\n\n**Human-in-the-loop:** Any task can `kanban_block()` to wait for input. Dispatcher respawns after `\u002Funblock`. The comment thread carries the full context.\n\n## Pitfalls\n\n**Inventing profile names that don't exist.** The dispatcher silently fails to spawn unknown assignees — the card just sits in `ready` forever. Always assign to a profile from your Step 0 discovery; ask the user if you're unsure.\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\u002Fengineer card for the fixes and an explorer\u002Fresearcher 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\u002Freview 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\n**Don't pre-create the whole graph if the shape depends on intermediate findings.** If T3's structure depends on what T1 and T2 find, let T3 exist as a \"synthesize findings\" task whose own first step is to read parent handoffs and plan the rest. Orchestrators can spawn orchestrators.\n\n**Tenant inheritance.** If `HERMES_TENANT` is set in your env, pass `tenant=os.environ.get(\"HERMES_TENANT\")` on every `kanban_create` call so child tasks stay in the same namespace.\n\n## Recovering stuck workers\n\nWhen a worker profile keeps crashing, hallucinating, or getting blocked by its own mistakes (usually: wrong model, missing skill, broken credential), the kanban dashboard flags the task with a ⚠ badge and opens a **Recovery** section in the drawer. Three primary actions:\n\n1. **Reclaim** (or `hermes kanban reclaim \u003Ctask_id>`) — abort the running worker immediately and reset the task to `ready`. The existing claim TTL is ~15 min; this is the fast path out.\n2. **Reassign** (or `hermes kanban reassign \u003Ctask_id> \u003Cnew-profile> --reclaim`) — switch the task to a different profile (one that exists on this setup) and let the dispatcher pick it up with a fresh worker.\n3. **Change profile model** — the dashboard prints a copy-paste hint for `hermes -p \u003Cprofile> model` since profile config lives on disk; edit it in a terminal, then Reclaim to retry with the new model.\n\nHallucination warnings appear on tasks where a worker's `kanban_complete(created_cards=[...])` claim included card ids that don't exist or weren't created by the worker's profile (the gate blocks the completion), or where the free-form summary references `t_\u003Chex>` ids that don't resolve (advisory prose scan, non-blocking). Both produce audit events that persist even after recovery actions — the trail stays for debugging.\n","# Kanban Orchestrator — Decomposition Playbook\n\n> The **core worker lifecycle** (including the `kanban_create` fan-out pattern and the \"decompose, don't execute\" rule) is auto-injected into every kanban process via the `KANBAN_GUIDANCE` system-prompt block. This skill is the deeper playbook when you're an orchestrator profile whose whole job is routing.\n\n## Profiles are user-configured — not a fixed roster\n\nHermes setups vary widely. Some users run a single profile that does everything; some run a small fleet (`docker-worker`, `cron-worker`); some run a curated specialist team they've named themselves. There is **no default specialist roster** — the orchestrator skill does not know what profiles exist on this machine.\n\nBefore fanning out, you must ground the decomposition in the profiles that actually exist. The dispatcher silently fails to spawn unknown assignee names — it doesn't autocorrect, doesn't suggest, doesn't fall back. So a card assigned to `researcher` on a setup that only has `docker-worker` just sits in `ready` forever.\n\n**Step 0: discover available profiles before planning.**\n\nUse one of these:\n\n- `hermes profile list` — prints the table of profiles configured on this machine. Run it through your terminal tool if you have one; otherwise ask the user.\n- `kanban_list(assignee=\"\u003Csome-name>\")` — sanity-check a single name. Returns an empty list (rather than an error) for an unknown assignee, so this only confirms a name you're already considering.\n- **Just ask the user.** \"What profiles do you have set up?\" is a fine first turn when the goal needs more than one specialist.\n\nCache the result in your working memory for the rest of the conversation. Re-asking every turn wastes a tool call.\n\n## When to use the board (vs. just doing the work)\n\nCreate Kanban tasks when any of these are true:\n\n1. **Multiple specialists are needed.** Research + analysis + writing is three profiles.\n2. **The work should survive a crash or restart.** Long-running, recurring, or important.\n3. **The user might want to interject.** Human-in-the-loop at any step.\n4. **Multiple subtasks can run in parallel.** Fan-out for speed.\n5. **Review \u002F iteration is expected.** A reviewer profile loops on drafter output.\n6. **The audit trail matters.** Board rows persist in SQLite forever.\n\nIf *none* of those apply — it's a small one-shot reasoning task — use `delegate_task` instead or answer the user directly.\n\n## The anti-temptation rules\n\nYour 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\u002Ffile\u002Fcode\u002Fweb 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 the available profiles, ask the user which profile to create or which existing profile to use.** Do not invent profile names; the dispatcher will silently drop unknown assignees.\n- **Decompose, route, and summarize — that's the whole job.**\n\n## Decomposition playbook\n\n### Step 1 — Understand the goal\n\nAsk clarifying questions if the goal is ambiguous. Cheap to ask; expensive to spawn the wrong fleet.\n\n### Step 2 — Sketch the task graph\n\nBefore creating anything, draft the graph out loud (in your response to the user). Treat every concrete workstream as a candidate card:\n\n1. Extract the lanes from the request.\n2. Map each lane to one of the profiles you discovered in Step 0. If a lane doesn't fit any existing profile, ask the user which to use or create.\n3. Decide whether each lane is independent or gated by another lane.\n4. Create independent lanes as parallel cards with no parent links.\n5. Create synthesis\u002Freview\u002Fintegration cards with parent links to the lanes they depend on.\n\nExamples of prompts that should fan out (using placeholder profile names — substitute whatever exists on the user's setup):\n\n- \"Build an app\" → one card to a design-oriented profile for product\u002FUI direction, one or two cards to engineering profiles for implementation, plus a later integration\u002Freview card if the user has a reviewer profile.\n- \"Fix blockers and check model variants\" → one implementation card for the blocker fixes plus one discovery\u002Fresearch card for config\u002Fsource 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\" → one card to a vision-capable profile for the visual analysis while another searches the codebase.\n\nWords 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\nShow the graph to the user before creating cards. Let them correct it — including which actual profile name should own each lane.\n\n### Step 3 — Create tasks and link\n\nUse the profile names from Step 0. The example below uses placeholders `\u003Cprofile-A>`, `\u003Cprofile-B>`, `\u003Cprofile-C>` — replace them with what the user actually has.\n\n```python\nt1 = kanban_create(\n    title=\"research: Postgres cost vs current\",\n    assignee=\"\u003Cprofile-A>\",  # whichever profile handles research on this setup\n    body=\"Compare estimated infrastructure costs, migration costs, and ongoing ops costs over a 3-year window. Sources: AWS\u002FGCP pricing, team time estimates, current Postgres bills from peers.\",\n    tenant=os.environ.get(\"HERMES_TENANT\"),\n)[\"task_id\"]\n\nt2 = kanban_create(\n    title=\"research: Postgres performance vs current\",\n    assignee=\"\u003Cprofile-A>\",  # same profile, run in parallel\n    body=\"Compare query latency, throughput, and scaling characteristics at our expected data volume (~500GB, 10k QPS peak). Sources: benchmark papers, public case studies, pgbench results if easy.\",\n)[\"task_id\"]\n\nt3 = kanban_create(\n    title=\"synthesize migration recommendation\",\n    assignee=\"\u003Cprofile-B>\",  # whichever profile does synthesis\u002Fanalysis\n    body=\"Read the findings from T1 (cost) and T2 (performance). Produce a 1-page recommendation with explicit trade-offs and a go\u002Fno-go call.\",\n    parents=[t1, t2],\n)[\"task_id\"]\n\nt4 = kanban_create(\n    title=\"draft decision memo\",\n    assignee=\"\u003Cprofile-C>\",  # whichever profile drafts user-facing prose\n    body=\"Turn the analyst's recommendation into a 2-page memo for the CTO. Match the tone of previous decision memos in the team's knowledge base.\",\n    parents=[t3],\n)[\"task_id\"]\n```\n\n`parents=[...]` gates promotion — children stay in `todo` until every parent reaches `done`, then auto-promote to `ready`. No manual coordination needed; the dispatcher and dependency engine handle it.\n\n### Step 4 — Complete your own task\n\nIf you were spawned as a task yourself (e.g. a planner profile was assigned `T0: \"investigate Postgres migration\"`), mark it done with a summary of what you created:\n\n```python\nkanban_complete(\n    summary=\"decomposed into T1-T4: 2 research lanes in parallel, 1 synthesis on their outputs, 1 prose draft on the recommendation\",\n    metadata={\n        \"task_graph\": {\n            \"T1\": {\"assignee\": \"\u003Cprofile-A>\", \"parents\": []},\n            \"T2\": {\"assignee\": \"\u003Cprofile-A>\", \"parents\": []},\n            \"T3\": {\"assignee\": \"\u003Cprofile-B>\", \"parents\": [\"T1\", \"T2\"]},\n            \"T4\": {\"assignee\": \"\u003Cprofile-C>\", \"parents\": [\"T3\"]},\n        },\n    },\n)\n```\n\n### Step 5 — Report back to the user\n\nTell them what you created in plain prose, naming the actual profiles you used:\n\n> I've queued 4 tasks:\n> - **T1** (`\u003Cprofile-A>`): cost comparison\n> - **T2** (`\u003Cprofile-A>`): performance comparison, in parallel with T1\n> - **T3** (`\u003Cprofile-B>`): synthesizes T1 + T2 into a recommendation\n> - **T4** (`\u003Cprofile-C>`): turns T3 into a CTO memo\n>\n> The dispatcher will pick up T1 and T2 now. T3 starts when both finish. You'll get a gateway ping when T4 completes. Use the dashboard or `hermes kanban tail \u003Cid>` to follow along.\n\n## Common patterns\n\n**Fan-out + fan-in (research → synthesize):** N research-style cards with no parents, one synthesis card with all of them as parents.\n\n**Parallel implementation + validation:** one implementer card makes the change while one explorer\u002Fresearcher 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:** `planner → implementer → 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:** N tasks, all assigned to the same profile, no dependencies between them. Dispatcher serializes — that profile processes them in priority order, accumulating experience in its own memory.\n\n**Human-in-the-loop:** Any task can `kanban_block()` to wait for input. Dispatcher respawns after `\u002Funblock`. The comment thread carries the full context.\n\n## Pitfalls\n\n**Inventing profile names that don't exist.** The dispatcher silently fails to spawn unknown assignees — the card just sits in `ready` forever. Always assign to a profile from your Step 0 discovery; ask the user if you're unsure.\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\u002Fengineer card for the fixes and an explorer\u002Fresearcher 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\u002Freview 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\n**Don't pre-create the whole graph if the shape depends on intermediate findings.** If T3's structure depends on what T1 and T2 find, let T3 exist as a \"synthesize findings\" task whose own first step is to read parent handoffs and plan the rest. Orchestrators can spawn orchestrators.\n\n**Tenant inheritance.** If `HERMES_TENANT` is set in your env, pass `tenant=os.environ.get(\"HERMES_TENANT\")` on every `kanban_create` call so child tasks stay in the same namespace.\n\n## Recovering stuck workers\n\nWhen a worker profile keeps crashing, hallucinating, or getting blocked by its own mistakes (usually: wrong model, missing skill, broken credential), the kanban dashboard flags the task with a ⚠ badge and opens a **Recovery** section in the drawer. Three primary actions:\n\n1. **Reclaim** (or `hermes kanban reclaim \u003Ctask_id>`) — abort the running worker immediately and reset the task to `ready`. The existing claim TTL is ~15 min; this is the fast path out.\n2. **Reassign** (or `hermes kanban reassign \u003Ctask_id> \u003Cnew-profile> --reclaim`) — switch the task to a different profile (one that exists on this setup) and let the dispatcher pick it up with a fresh worker.\n3. **Change profile model** — the dashboard prints a copy-paste hint for `hermes -p \u003Cprofile> model` since profile config lives on disk; edit it in a terminal, then Reclaim to retry with the new model.\n\nHallucination warnings appear on tasks where a worker's `kanban_complete(created_cards=[...])` claim included card ids that don't exist or weren't created by the worker's profile (the gate blocks the completion), or where the free-form summary references `t_\u003Chex>` ids that don't resolve (advisory prose scan, non-blocking). Both produce audit events that persist even after recovery actions — the trail stays for debugging.\n",{"name":5,"version":55,"metadata":56,"platforms":61,"description":7},"3.0.0",{"hermes":57},{"tags":58,"related_skills":59},[23,42,48,46],[60],"kanban-worker",[49,27,47],"main","42ccd02cbf5e8e47839dc3eab6fc754dc6b339cf","hermes\u002Fskills\u002Fdevops\u002Fkanban-orchestrator",0,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills","https:\u002F\u002Fgithub.com\u002Fjleechanorg","2026-11-14 14:55:35",{"source":8,"skillName":5,"commands":70,"prompt":80,"zipAvailable":81},[71,74,77],{"tool":72,"command":73},"npx","npx skills add jleechanorg\u002Fjleechan-skills --skill kanban-orchestrator",{"tool":75,"command":76},"bunx","bunx skills add jleechanorg\u002Fjleechan-skills --skill kanban-orchestrator",{"tool":78,"command":79},"pnpm","pnpm dlx skills add jleechanorg\u002Fjleechan-skills --skill kanban-orchestrator","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fdevops\u002Fkanban-orchestrator\u002FSKILL.md",true,[83,89],{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fextended-guide.md","REFERENCE","参考文档",7093,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-makepad-2-0-layout\u002Freferences\u002Fextended-guide.md",{"path":90,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Flayout-patterns.md",24806,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-makepad-2-0-layout\u002Freferences\u002Flayout-patterns.md",[94,111,132,146,160,175],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":50},"01M716Y5MTJ6GYJZ2ATXCJK8G4","instinct","Use when the user invokes \u002Finstinct or \u002Fin, or asks to \"message Instinct\", \"ask Instinct\", \"tell Instinct\", \"check Instinct\", or read replies from the configured peer assistant. iMessage first, WhatsApp Web as fallback.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Finstinct\u002FSKILL.md",[],[96,101,26,102,103,104,105,106,107,108,109,110],"user","replies","check","use","identity","whatsapp","gmail","read","message","ask",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":122,"publishedAt":50},"01M716Y4HF7FVVMJSA2CCVN5VF","hr","Compatibility alias for history-resume; produce the same fresh-state, provenance-aware resume briefing.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhr\u002FSKILL.md",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[113,123,124,125,28,126,127,128,129,130,131],"resume","compatibility","provenance","history","produce","alias","briefing","state","fresh",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":139,"publishedAt":50},"01M716Y1FFNFKFJYYKF8HQA6T8","history-resume","Resume briefing for the current repository branch or worktree using fresh state and admitted history sources.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhistory-resume\u002FSKILL.md",[138],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},[126,123,140,141,101,142,129,143,28,144,145,130,131],"history resume","branch","analysis","repository","worktree","sources",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":50},"01M716XWXJ8EPHK4RH9T14TR85","grok","Alias for the canonical grokbot browser conversation workflow; \u002Fgrok talks to the Grok bot the same way \u002Fdot talks to Dot.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgrok\u002FSKILL.md",[],[148,153,154,155,28,156,128,157,158,159],"dot","bot","workflow","canonical","conversation","browser","grokbot",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":50},"01M70N9Q07DTE0EW5KFXMMMSJ0","codexa-bench","Compare `codexa` and normal `codex` on a fair split of comparable work by default; use `--strict` for duplicate runs of the exact same task.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcodexa-bench\u002FSKILL.md",[],[167,40,168,104,169,28,170,171,172,173,174],"codexa bench","split","default","duplicate","task","compare","normal","codex",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":179,"licenseFileUrl":180,"sourceHtmlUrl":181,"categories":182,"keywords":192,"publishedAt":50},"01M6C24S2X60SP8BBFGAEKPEGW","frontend-design","Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML\u002FCSS layouts, or when styling\u002Fbeautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FSKILL.md",[183,186,189],{"categoryNo":184,"categoryName":185,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":187,"categoryName":188,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":190,"categoryName":191,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000032","设计师",[193,194,195,104,196,197,198,101,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,26,217],"frontend","design","frontend design","generic","ui design","react","html","components","code","artifacts","ui","aesthetics","Production","web components","landing","applications","quality","web","css","create","examples","with","react components","web ui","pages"]