Feature proposal: Add Agent Skills support to ADK

[DamiMartinez]

Summary

Add support for Agent Skills in ADK so agents can extend their capabilities with standardized SKILL.md skills.

Motivation

• Ecosystem compatibility – Agent Skills is an open format used by Cursor, Claude Code, Gemini CLI, and others. ADK support would align with this ecosystem.
• Progressive disclosure – Only metadata (name, description) is loaded initially; full instructions load when relevant, reducing context use.
• Reuse – Skills from skills.sh and other sources could be reused across ADK agents.

Proposed approach

Skill-as-tool pattern (following the Claude Agent SDK):

• Inject skill metadata into system context at startup.
• Expose a Skill tool that loads full content when invoked.
• Context management: content added via tool results; removal via event compaction and truncation.

Components: Skill discovery loader, Skill tool, AgentSkillsPlugin (metadata injection), and configurable skills directories.

Questions for maintainers

1. Does this fit ADK's roadmap and architecture?
2. Should Skills be opt-in via plugin or part of the default setup?
3. Rely on compaction/truncation for removal, or support an explicit dismiss?

Willingness to contribute

I’d like to help implement this feature and collaborate with maintainers on the design and implementation.

[praizada-groupon]

I can see some activity on this topic c736210, but I don't think it's ready yet.

[aleksandarperak33-hub]

First-class agent skills is the right direction — the tension right now is that skills (instructions + tools + memory) tend to leak across agents when you use them in multi-agent flows.

What we solved with TokenRip (tokenrip.com) is skill scoping: each skill is an asset with a stable URL, agents fetch the asset at session start, and the asset defines the skill's tool allowlist + behavioral contract. Skills become composable without cross-agent state pollution.

Would be excited to see ADK take skills in this direction — scoped, versioned, URL-addressable — rather than as instance-attached state.