fix(kanban): validate --skill against the worker profile's skill registry at create time

[AIalliAI]

Summary

hermes kanban create --skill <name> accepted any string. Unknown names only surfaced when the spawned worker crashed at CLI startup (ValueError: Unknown skill(s): <name>) — burning the task's retry budget and completing with an empty result.

This validates at create time and rejects the task with exit 2 and a descriptive error before it is enqueued.

Fixes #44072

How it works

• kanban_db.unresolvable_task_skills(skills, hermes_home) — best-effort mirror of skill_view()'s lookup strategies (directory named <name> containing SKILL.md at the root or nested, relative-path form cat/name, frontmatter name: alias, legacy flat <name>.md) against the skills roots the worker will actually see: <home>/skills plus skills.external_dirs from that home's config.yaml (read directly, since the validating CLI may run under a different HERMES_HOME than the worker).
• _cmd_create resolves the assignee profile's HERMES_HOME the same way the dispatcher's _default_spawn does (resolve_profile_env), so validation runs against the worker's registry, not the creator's — the exact failure mode in the issue ("a profile dispatching a skill not installed in the target assignee's profile").

Deliberately conservative

A name is only rejected when every cheap strategy misses. Names that can't be reliably checked cross-profile get the benefit of the doubt:

• plugin-qualified namespace:skill names (plugin registries are per-home state), and
• the built-in kanban-worker (the dispatcher already gates it on resolvability and silently drops it when absent — never fatal).

So a false accept degrades to today's behavior, while a reject is always a real startup crash avoided.

Error output

$ hermes kanban create "some task" --assignee coder --skill some-unknown-skill
kanban: unknown skill(s) for profile 'coder': some-unknown-skill
Workers preload --skill values at startup and crash on unknown names, burning the
task's retry budget (see #44072). Check the name with `hermes skills list` or
install the skill into that profile first.

Tests

• New tests/hermes_cli/test_kanban_create_skill_validation.py (11 tests): unit coverage for every resolution strategy (direct dir, relative path, frontmatter alias, legacy flat .md, external_dirs, missing skills root) and end-to-end run_slash coverage including the assignee-profile-home case in both directions (skill only in profile home → accepted; skill only in root home → rejected).
• Updated test_cli_create_skill_flag_repeatable / test_cli_show_renders_skills to install the skills they reference (they test persistence/rendering, not resolution).
• Full tests/hermes_cli -k kanban selection produces a failure set identical to origin/main baseline (the handful of pre-existing ordering/environment-dependent failures are untouched).

[alt-glitch]

Duplicate of #44092 — the earlier open PR fixing the same issue (#44072) with the same approach: validate kanban create --skill against the installed skill registry at task-creation time before enqueue. This PR is more thorough (cross-profile HERMES_HOME resolution), but #44092 landed first; maintainer to consolidate.

[AIalliAI]

Status update on the duplicate flag above: #44092 has since been closed by its author in favor of this PR (it didn't cover relative-path/alias/ns:skill lookup forms or the calling profile's registry — details in the review there). This is now the only open fix for #44072.

[AIalliAI]

Requesting maintainer review — this is ready to land from my side. Standalone fork CI is pending first-run approval here; the rollup branch in #44061 carrying this session's batch is fully green on upstream CI (all test shards, typecheck, e2e).

[teknium1]

Thanks for addressing the worker retry-budget failure. The all-unresolvable case still exists on current main, but this implementation needs revision before salvage.

Problems

• hermes_cli/kanban.py:1351 rejects any unknown entry. Current main intentionally skips unknown skills when another requested skill loads (cli.py:15933-15947, commit 018009bc382de86f864e3fa8af3982c2f0aa7bfb), so mixed valid/invalid task skills must remain enqueueable.
• hermes_cli/kanban_db.py:7677 checks relative skills.external_dirs against the creator cwd. Worker resolution anchors relative paths at its profile HERMES_HOME (agent/skill_utils.py:483-487), causing false rejection.
• hermes_cli/kanban_db.py:7744 bypasses skill_view exclusion and ambiguity behavior (agent/skill_utils.py:785-807; tools/skills_tool.py:1182-1204).

Suggested changes

• Reject only when every requested skill is unresolvable, and cover the mixed-list case.
• Reuse worker-equivalent external-directory, exclusion, and collision semantics.

GitHub currently reports the PR mergeable, but its base predates the mixed-skill behavior and requires substantive behavioral rework. This is an automated hermes-sweeper review.

[teknium1]

This rejects a mixed valid/invalid list, but current main intentionally skips unknown entries when at least one requested skill loads (cli.py:15933-15947, 018009bc). Please preserve that behavior and reject only the all-unresolvable case.

[teknium1]

Relative skills.external_dirs must be resolved against the worker profile’s HERMES_HOME, not the creator cwd. See agent/skill_utils.py:483-487; otherwise this validator can reject a skill the worker would load.

[teknium1]

Use the shared indexed-skill iteration semantics here: raw rglob() includes paths that skill_view excludes and does not model its ambiguity rejection, so it can falsely accept a worker-invalid name.