go-adk

Expert guidance for developing agents with

google.golang.org/adk

(Go ADK).

When to trigger

The user mentions Go ADK,
```
google.golang.org/adk
```
,
```
adk-go
```
, or asks how to build agents in Go.
The task involves ADK concepts like
```
llmagent
```
, tools, callbacks, sessions/state/memory, workflow agents, streaming, MCP, A2A, ADK web/API runtime, launchers, deployment, evaluation, or safety controls.

Core rules

Treat references/llms-index.md as the required ADK coverage map.
Prefer official ADK Go APIs and examples over ad-hoc wrappers.
Follow existing repository patterns first (imports, launcher style, layout, env handling).
For version-sensitive behavior, check release notes and API reference before giving definitive guidance.
Prioritize Go-specific ADK docs first; if a feature is documented only in another SDK doc, call that out explicitly.
Keep agent names unique and never use
```
user
```
as an agent name.
Use concise
```
Description
```
fields so delegation and tool selection remain reliable.
Treat ADK Web as development-only unless the user explicitly asks for production runtime choices.

Workflow

Map task to ADK domain:
- Build, run, deploy, evaluate, safety, components, protocols, or reference.
- Load only the relevant sections from references/llms-index.md.
Confirm execution style:
- Launcher-first app (
```
cmd/launcher
```
  ,
```
cmd/launcher/full
```
  ) or embedded runtime (
```
runner.Run
```
  loop).
- Local dev UI, CLI-only, or REST/API server flow.
Build the first working agent:
- ```
llmagent.New(llmagent.Config{...})
```
  with a concrete model (commonly
```
gemini.NewModel(...)
```
  ).
- Add minimum viable
```
Instruction
```
  ,
```
Description
```
  , and
```
Tools
```
  .
Add tools safely:
- Use
```
functiontool.New(...)
```
  for typed custom tools.
- Use
```
geminitool.GoogleSearch{}
```
  or other ADK/native integrations only when needed.
- For sensitive tools, apply confirmations, auth, and policy callbacks.
Wire stateful execution:
- Sessions via
```
session.Service
```
  (often
```
session.NewInMemoryService()
```
  for local dev).
- Add
```
memory.Service
```
  only when cross-session retrieval is required.
- Add state/context/artifacts management only when required by the workflow.
Apply control points:
- Use callbacks (
```
Before/After Model
```
  ,
```
Before/After Tool
```
  , agent callbacks) for logging, caching, guardrails, and overrides.
- Prefer plugins for reusable security policy enforcement.
Scale composition:
- Use workflow agents for deterministic orchestration (
```
sequentialagent
```
  ,
```
parallelagent
```
  ,
```
loopagent
```
  ).
- Use multi-agent delegation (descriptions + transfer behavior) only when specialization is clear.
Select runtime/deployment posture:
- Local dev: CLI/Web/API.
- Production: deployment target + observability + safety posture.
Verify behavior end-to-end:
- Validate happy-path conversation, tool errors, callbacks, session resume/rewind behavior, and evaluation criteria.

Output expectations

Provide exact Go imports, runnable snippets, and command lines that match the chosen runtime mode.
Call out version-sensitive behavior if the user targets older ADK tags.
Mention the relevant ADK doc section when guidance comes from
```
llms-index
```
categories beyond core Go quickstart pages.
Prefer small, testable incremental changes over large rewrites.

References

Quickstart and launcher baseline: references/quickstart.md
Core APIs and agent config: references/core-primitives.md
Tools, callbacks, and guardrails: references/tools-and-guardrails.md
Runtime modes, examples, and A2A: references/runtime-and-examples.md
Required ADK source map (
```
llms.txt
```
mirror): references/llms-index.md

go-adk

NPX Install

Tags

SKILL.md Content

go-adk

When to trigger

Core rules

Workflow

Output expectations

References