feat(agent): add filesystem-backed Agent Skills support to agent nodes

[zivkovicp]

Summary

• add Agent Skills support for agent nodes using a fixed project-level skills/ directory
• expose discovered skills in the agent prompt via progressive disclosure metadata
• add built-in skill tools for activation and reading skill-local reference files
• support optional spec-compliant allowed-tools frontmatter and runtime tool compatibility filtering
• prevent agents from claiming unavailable skills when no compatible skills remain
• add demo skills for Python scratchpad execution and REST API calling

[NA-Wen]

Thank you very much for your contribution — this feature is quite important for the project and we really appreciate the effort you put into it 🥳.

That said, the addition of python_execution here does not seem strictly necessary. Could you please revisit this part and consider removing or simplifying it if it is not that necessary?

Once this part is updated, we will merge the PR as soon as possible ! Thanks again for your vital contribution !

[zivkovicp]

I made the requested change and pushed to my branch. It seems the PR is slow to sync, if the changes aren't visible in a reasonable amount of time, please advise on how to update this PR (I'm not a regular GitHub contributor and am not familiar)

[zxrys]

Thanks for the fast follow-up here and for iterating on this so quickly after our previous discussion. This is a meaningful contribution overall: the skill abstraction is clean, the config surface is easy to understand, and the built-in activate_skill / read_skill_file flow is a strong addition. I spent some time walking through the runtime path, and I found a concrete issue that I think should be addressed before merging:

The implementation does not track the most recently activated skill as the current active skill.

In runtime/node/agent/skills/manager.py#L172, activate_skill() only marks a skill as activated in a boolean map. Then runtime/node/agent/skills/manager.py#L216 returns the first discovered activated skill, not the last activated one.

This causes incorrect behavior when the model activates multiple skills in sequence. For example:

• first activate python-scratchpad
• then activate rest-api-caller

Semantically, rest-api-caller should now be the current active skill. But with the current implementation, active_skill() may still return python-scratchpad if it appears earlier in discovery order. Since runtime tool restriction uses active_skill() in runtime/node/executor/agent_executor.py#L711, later tool calls can still be checked against the wrong skill.

I also verified this locally: after activating python-scratchpad and then rest-api-caller, active_skill() still returned python-scratchpad.

I think this should be modeled as explicit “current active skill” state, rather than inferring it from a set of previously activated skills.