Closing all three of your stacked PRs (#22974, #23154, #23183) in favor of asking for a single focused re-submission. Apologies for the bulk close — the work itself is good, the structure is the problem.

Why three closes: the PRs are git-stacked supersets of each other (#23183 contains every commit from #23154 which contains every commit from #22974). Reviewing them independently is impossible without first deciding on the previous one, and #23183 ends up bundling ~1000 LOC of redundant work (the create-time skills validation, which landed on main via PR #23273 using the live toolset registry rather than your hardcoded INVALID_TASK_SKILL_NAMES list) with ~300 LOC of genuinely novel work (the WorkerStartupGuard in run_agent.py).

What's already on main:

• Skills validation at create time (PR fix(kanban): reject toolset names in task skills field (salvage #22933) #23273) — uses KNOWN_TOOLSET_NAMES = frozenset(name.casefold() for name in get_toolset_names()), dynamic registry lookup, aggregates all typos before raising. Functionally identical to your _normalize_task_skills but with a live source of truth.

What's genuinely new in this stack and worth shipping (~300 LOC if carved out):

1. kb.check_worker_startup_guard() + WorkerStartupGuard dataclass — preflight in run_conversation() that runs before any model API call, closes the claim→spawn race window where a worker boots after the task was reclaimed/blocked.
2. Three new diagnostic rules (invalid_task_skills, assignee_profile_not_found, stale_running_claim).
3. hermes kanban edit --clear-skills / --reset-failures / --clear-claim recovery CLI flags backed by edit_task_recovery_fields() and reset_task_failures().

Ask: could you re-submit those three pieces as one focused PR against current main? Either the whole bundle (~300 net LOC) or split further (startup guard separately, diagnostics+recovery together) — whichever you prefer. The constraint is just that we need ONE PR per concern instead of three stacked supersets.

For the startup guard specifically: it touches run_agent.py which is on the protected-files list (~7500 lines, lots of repeated patterns), so we need to look at the dict-construction carefully. The current ~95-line hand-rolled return dict mirroring run_conversation's normal return shape is a maintenance hazard — factoring a _terminal_run_result() helper that builds it from kwargs would be cleaner. Happy to discuss the shape on the new PR.

Thanks for the work @qWaitCrypto — the diagnostics and startup-guard ideas are good, just need to land them as a focused unit.

References:

• PR fix(kanban): reject toolset names in task skills field (salvage #22933) #23273 — KNOWN_TOOLSET_NAMES create-time validation
• AGENTS.md "Critical File Restrictions" — run_agent.py editing rules