Research Remote Agents

This skill helps the user find A2A-compatible remote agents that match what their project actually needs. A2A (Agent-to-Agent Protocol) does not yet have a mature automated discovery layer — there is no universal registry an agent can query at runtime. So discovery is still a manual research task: someone has to read the project, understand its goals, hunt down candidate agents, and check their Agent Cards. This skill automates that research and hands the user a short, curated list of candidates to choose from.

What this skill does

1. Reads the project to understand its purpose and tech stack.
2. Derives the capabilities a remote agent would need to provide for this project.
3. Searches A2A registries and the web for agents exposing those capabilities.
4. Returns a single paragraph naming 4–5 candidate remote agents, each with a link to its Agent Card (or repo/docs if the card isn't directly linkable).

It does not auto-integrate the agent or write code. It is a research and recommendation step. Integration is a separate, explicit decision the user makes after reviewing candidates.

Step 1 — Understand the project

Read these sources, in this priority order, and stop once you have a clear picture (don't exhaustively read every file in a large repo):

• CLAUDE.md (or CLAUDE.local.md) — the single most important file; it usually states the project's purpose and conventions directly.
• README.md and anything under docs/, documentation/, or *.md at the root.
• Package manifests (package.json, *.csproj, pyproject.toml, go.mod, Cargo.toml) — these reveal the language and framework.
• Any file whose name signals project intent (ARCHITECTURE.md, PRD.md, spec.md, requirements.md).

From these, write a short internal summary (don't show it yet) capturing:

• Domain: what the project is for (e.g. e-commerce price tracker, clinic-matching platform, internal devtool).
• Tech stack: primary language(s) and framework(s).
• Gaps: what kind of work the project would plausibly want to delegate to an external agent — e.g. document parsing, translation, web research, code review, image generation, payment reconciliation, data enrichment.

The "Gaps" are the heart of this skill. A remote agent is only useful if it does something the project needs but doesn't already do well itself. If the project clearly has no obvious delegation gap, say so honestly rather than inventing one.

Step 2 — Derive needed capabilities

Turn the gaps into concrete capability queries. For each gap, phrase what an ideal agent would advertise in its Agent Card skills / capabilities section. Example:

• Gap: "needs to extract structured data from uploaded medical PDFs"
• Capability query: "PDF data extraction agent", "document understanding A2A agent", "OCR structured output agent"

Keep this to 2–4 distinct capabilities. More than that and the recommendations get unfocused.

Step 3 — Search for candidate agents

A2A agents are published in scattered places. Search these sources, in roughly this order, using the capability queries from Step 2. Run multiple distinct searches — one or two per capability — rather than a single broad query.

Known places to look:

• A2A directories and registries (search: A2A agent directory, agent2agent registry, A2A agent card directory).
• Smithery (smithery.ai) — primarily MCP, but increasingly lists agents.
• Glama (glama.ai) and mcp.so — adjacent agent/tool directories.
• GitHub — search <capability> A2A agent card and agent.json / .well-known/agent.json, which is the conventional Agent Card path.
• Vendor docs — major providers publishing A2A-compatible agents.

For each promising candidate, try to confirm:

• It actually speaks A2A (look for an Agent Card, usually JSON at /.well-known/agent.json or a documented card URL).
• Its advertised skills genuinely match one of the project's gaps.
• It's reachable / not abandoned (recent activity, working link).

If you cannot verify a true Agent Card link, still include the agent but clearly link to its repo or docs and note that the card URL needs confirmation. Never fabricate an Agent Card URL — a wrong link is worse than an honest "card location unconfirmed".

Step 4 — Present the recommendations

Respond to the user in the language they are using (match their messages). Output exactly one short paragraph — not a table, not a long list — that:

• Opens with a one-line restatement of what the project needs (so the user can sanity-check that you understood the project).
• Names 4–5 candidate remote agents inline.
• Gives each agent a markdown link to its Agent Card (or repo/docs, flagged as such).
• For each, adds a 4–8 word note on why it fits.

Output template

Match this shape (translate the framing to the user's language):

Projen [bir cümlelik özet] için bir remote agent'a ihtiyaç duyuyor. Buna uygun bulduğum adaylar: Agent A — [neden uygun], Agent B — [neden uygun], Agent C — [neden uygun], Agent D — [neden uygun], ve Agent E — [neden uygun]. Card linki doğrulanamayanları ayrıca belirttim; entegrasyondan önce her birinin Agent Card'ını açıp skills bölümünü kontrol etmeni öneririm.

Then end with one short line offering the obvious next step: integrating whichever agent the user picks. Do not integrate anything proactively.

Honesty rules

• If discovery turns up fewer than 4 solid candidates, return what you have and say plainly that the A2A ecosystem is still young and these were the genuine matches — don't pad the list with irrelevant agents.
• If the project has no real delegation gap, tell the user that directly instead of recommending agents it doesn't need.
• Never invent Agent Card URLs, agent names, or capabilities. Every link must be one you actually found.