What are skills in A2A and how are they supported?

in here https://forums.basehub.com/a2aproject/A2A/1#2-4-in-task-auth-auth-required-state

they mentioned "skills": what are skills in a2a, and how are they supported?

Now I have a comprehensive picture. Let me put it all together.

---

##What Are "Skills" in A2A?

In the A2A protocol, Skills (AgentSkill) represent the distinct capabilities or functions that an agent can perform. They are the primary way an agent advertises what it's good at to clients and other agents.

As the proto definition puts it (specification/a2a.proto L393-397):

Skills represent the abilities of an agent. It is largely a descriptive concept but represents a more focused set of behaviors that the agent is likely to succeed at.

###The AgentSkill Message

Defined at specification/a2a.proto L438-453, an AgentSkill has these fields:

###Where Skills Live: The Agent Card

Skills are declared as a required field on the AgentCard:

repeated AgentSkill skills = 12 [(google.api.field_behavior) = REQUIRED];

Every agent must publish at least the skills array in its Agent Card. Here's a concrete example from the spec (docs/specification.md L1037-1048):

{
  "skills": [
    {
      "id": "academic-research",
      "name": "Academic Research Assistant",
      "description": "Provides research assistance with citations and source verification",
      "tags": ["research", "citations", "academic"],
      "examples": ["Find peer-reviewed articles on climate change"],
      "inputModes": ["text/plain"],
      "outputModes": ["text/plain"]
    }
  ]
}

###How Skills Are Used

Skills serve several purposes across the protocol:

1. Agent Discovery — Clients and registries use skills to find the right agent. From docs/topics/agent-discovery.md, curated registries allow clients to "query and discover agents based on criteria like 'skills' or 'tags'", enabling capability-based discovery.

2. Per-Skill I/O Modes — A skill can override the agent's defaultInputModes/defaultOutputModes. For example, an agent might generally handle text/plain, but a specific skill could accept image/png input.

3. Per-Skill Security — Skills can declare their own security_requirements (a2a.proto L453). This was added in a recent change (CHANGELOG.md) and enables skill-based authorization. From docs/topics/enterprise-ready.md L73-76:

   Access can be controlled on a per-skill basis, as advertised in the Agent Card. For example, specific OAuth scopes should grant an authenticated client access to invoke certain skills but not others.

4. Extended Agent Cards — When a client authenticates, the server can return an extended Agent Card with additional skills not visible in the public card (docs/specification.md L1865-1867). This means sensitive or premium skills can be hidden from unauthenticated discovery.

5. Authorization Decisions — The spec explicitly says authorization logic MAY consider "specific skills requested" (docs/specification.md L1912).

###Connection to the Forum Post

The forum post you referenced discusses the AUTH_REQUIRED task state. This connects to skills because:

• An agent might require different auth for different skills (via per-skill security_requirements)
• During task execution, if the agent realizes it needs additional credentials to complete a skill (e.g., accessing a third-party API on the user's behalf), it transitions to TASK_STATE_AUTH_REQUIRED

###What Skills Are Not

Skills are descriptive metadata, not executable endpoints. There's no InvokeSkill() RPC — you interact with agents via SendMessage, and the agent uses its own logic to determine which skill applies. There's an open investigation in the README.md roadmap to potentially add a QuerySkill() method:

Investigate a QuerySkill() method for dynamically checking unsupported or unanticipated skills.

But today, skills are purely a discovery and routing hint — clients read them from the Agent Card and structure their messages accordingly.