feat: use llm to select skill when no skill selected

[ddu-aeron]

we are trying to use skills from clawhub and it do not have activation keyworkds, this pr will try to select these skills using llm as a fallback

Summary

• add LLM skill-selection fallback when no skills selected
• Add token cost tracking for the LLM skill-selection fallback

Change Type

• Bug fix
• New feature
• Refactor
• Documentation
• CI/Infrastructure
• Security
• Dependencies

Linked Issue

Validation

• cargo fmt --all -- --check
• cargo clippy --all --benches --tests --examples --all-features -- -D warnings
• cargo build
• Relevant tests pass:
• cargo test --features integration if database-backed or integration behavior changed
• Manual testing: tested with a skill without activation and it was selected
• If a coding agent was used and supports it, review-pr or pr-shepherd --fix was run before requesting review

Security Impact

Database Impact

Blast Radius

Touches src/llm/reasoning.rs (return type of select_skill_names_with_llm),
src/agent/agent_loop.rs (LLM fallback candidate filter + cost recording),
and test fixtures in src/agent/dispatcher.rs. No change to the happy path
for explicit or deterministic skill selection.

Rollback Plan

Revert the three files changed in this PR. No schema or config changes involved.

Review Follow-Through

The fallback_candidates filter now excludes any skill that has at least one
keyword, pattern, or tag. If a skill is intended to be description-only (no
activation criteria), it will still reach the LLM fallback. Reviewers should
confirm this is the desired boundary.

---

Review track:

[gemini-code-assist]

Code Review

This pull request introduces an LLM-based fallback mechanism for skill selection, triggered when explicit mentions or deterministic keyword matching do not yield results. It includes logic for candidate filtering, context token budget management, and cost tracking for the fallback LLM call. The dispatcher was also updated to ensure correct message context is used during approval-resume flows. Review feedback suggests optimizing the implementation by using a cheaper LLM model for the selection task and utilizing standard JSON serialization instead of pretty-printing to reduce token overhead.

[serrrfirat]

Nice improvement for the v1 path. One thing to call out: this is still v1-only, since engine v2 does skill selection in crates/ironclaw_engine/orchestrator/default.py (via select_skills(...) / __list_skills__()), not in src/agent/*.

If we want parity, we should mirror the same behavior in v2 as a follow-up: keep explicit /skill-name + deterministic keyword/pattern selection as the primary path, and only fall back to an LLM-based selector when that path returns no skills. I’d also keep the same guardrail from this PR and only offer the LLM skills that have no positive activation metadata, so the LLM doesn’t second-guess deterministic exclusions.

Otherwise we’ll have different skill-selection behavior between v1 and v2 during the migration.

[ddu-aeron]

Nice improvement for the v1 path. One thing to call out: this is still v1-only, since engine v2 does skill selection in crates/ironclaw_engine/orchestrator/default.py (via select_skills(...) / __list_skills__()), not in src/agent/*.

If we want parity, we should mirror the same behavior in v2 as a follow-up: keep explicit /skill-name + deterministic keyword/pattern selection as the primary path, and only fall back to an LLM-based selector when that path returns no skills. I’d also keep the same guardrail from this PR and only offer the LLM skills that have no positive activation metadata, so the LLM doesn’t second-guess deterministic exclusions.

Otherwise we’ll have different skill-selection behavior between v1 and v2 during the migration.

You are correct! we should keep the same logic in v2 engine. but im not familiar with python and still dont know how to test v2 engine.

i will dig into the code base with help of AI. and try to impl it. it would be great if some would help!

[ddu-aeron]

@serrrfirat v2 engine part is finished and tested manually, please review the change

[serrrfirat]

Thank you for taking the time to contribute this PR—we genuinely appreciate the work and context you added.

IronClaw is now consolidating development around the Reborn architecture and the upcoming ironclaw-reborn binary. This PR targets a legacy path that we no longer plan to ship or continue maintaining, so we are closing this implementation rather than asking you to keep investing in code that is being retired.

This is an architecture-transition decision, not a reflection on the quality of your contribution. We would be very happy to see you contribute to Reborn. If you would like to revisit this idea in the current architecture, please reference this PR so the original work and discussion remain connected; maintainers can help identify the owning Reborn crate and the appropriate integration-test seam.

Thank you again, and we hope to work with you on Reborn.