All skills
google avatar

google/adk-python

An open-source, code-first Python toolkit for building, evaluating, and deploying sophisticated AI agents with flexibility and control.

main Updated 11 hours agoGitHub
README badge for google/adk-python

Repository statistics

  • Indexed skills

    16

  • Skill groups

    1

  • GitHub stars

    21,687

  • Forks

    4,086

16 total

/adk-setup

Sets up a local ADK Python development environment in a git clone of the open-source adk-python repository: a uv virtual environment, all dependency extras, pre-commit hooks, and a first unit-test run. Runs only when explicitly requested, never on its own. Use when asked to set up, bootstrap, or repair a development checkout, install project dependencies, fix a missing or broken .venv, or prepare a machine for contributing a pull request. Don't use for debugging a running agent (use adk-debug), for commit and pull-request mechanics (use adk-git), or for re-running formatters on a checkout that is already set up (pre-commit run --all-files).

/adk-unit-guide

Writes a hands-on developer guide for one ADK code unit โ€” a minimal runnable example, how it works, a configuration-option table, advanced uses, limitations, and links to related samples โ€” to `docs/guides/{topic}/{unit}/index.md`, then lists it in the index at `docs/guides/README.md`. Its reader is a developer calling the unit from their own application, at more depth than the published adk.dev documentation carries. Use when asked to "write a unit guide for {class}", "document how to use {feature}", "add a guide for {file}", or after shipping a user-facing class, node, or plugin. Don't use for internals documentation aimed at someone changing or extending the unit โ€” that is a design document under `docs/design/` (use `adk-unit-design`). Don't use to write a runnable sample under `contributing/samples/` (use `adk-sample-creator`).

/adk-architecture

Explains how the ADK runtime fits together: the node and graph execution model, Context and Event flow, checkpoint and resume, tracing, and the rules governing the public API surface. Use when answering "how does X work" about ADK internals, tracing where an event or a piece of state comes from, deciding where a new capability belongs, reviewing a change to BaseNode, Workflow, Runner, Agent, Event or Context, working out why a node re-ran or stayed waiting after a resume, or judging whether a change breaks the public API. Don't use for assembling an agent from existing pieces (use adk-agent-builder), diagnosing one failing run or test (use adk-debug), or formatting and naming conventions (use adk-style).

/adk-review

Reviews the uncommitted changes in an adk-python working tree and reports correctness, design, public-API stability, test, sample and documentation gaps as a prioritized findings report, fixing them only when asked. Use when the user asks to review local changes, wants a self-review before opening a pull request, asks whether a change breaks the public API or needs tests, samples or docs, or asks what is wrong with the current diff. Required for changes to public APIs, core architecture (Runner, Workflow, BaseNode), new features and major refactors. Don't use for a single style nit (use adk-style), for diagnosing a failing test or a misbehaving agent at runtime (use adk-debug), or for wording a commit message or PR description (use adk-git).

/adk-sample-creator

Creates a new sample agent in the ADK Python repository โ€” the sample directory, its `agent.py`, and its `README.md` โ€” following the conventions the existing samples already use. Use when the user wants to add a sample or example demonstrating a feature or agent pattern (dynamic nodes, fan-out/fan-in, a standalone tool-using agent), asks where a new sample belongs under `contributing/samples/`, or wants an existing sample's README brought up to the standard structure. Don't use for building a real working agent for the user's own project (use `adk-agent-builder`), or for checking whether the Python blocks in a Markdown file run (use `adk-verify-snippets`).

/adk-agent-builder

Builds ADK (Agent Development Kit) Python agents: LLM agents with tools, graph workflows of function and agent nodes, conditional routing, fan-out and join, schema-validated delegation between agents, human-in-the-loop pauses, and pytest coverage for all of it. Use when asked to create an agent or a workflow, add a tool to one, branch or loop between nodes, run steps in parallel, pause for user approval, or test an agent. Don't use for explaining how ADK works internally or designing its core components (use `adk-architecture`), for an agent that already runs but misbehaves (use `adk-debug`), for authoring a sample under `contributing/` (use `adk-sample-creator`), or for naming, typing, and formatting conventions (use `adk-style`).

/adk-debug

Diagnoses misbehaving ADK agents by inspecting sessions, events, tool calls, and the exact request that reached the model. Covers the `adk run` CLI and the `adk web` dev server with its session, trace, and debug HTTP endpoints. Use when an agent returns the wrong answer, ignores a tool or swallows a tool error, hangs, loops, emits raw JSON instead of calling tools, is not discovered by `adk web`, when a sub-agent cannot see the parent conversation, or when you need the LLM request/response, token counts, or logs for a run. Don't use for how ADK is designed internally (use `adk-architecture`), for building a new agent or workflow (use `adk-agent-builder`), for environment or dependency setup failures (use `adk-setup`), or for lint and style nits (use `adk-style`).

/adk-git

Writes commit messages and pull request descriptions for the adk-python repository: Conventional Commits types and scopes, subject lines that say why a change was made, and the linked-issue and testing-plan sections the PR template requires. Use when writing or rewording a commit message, squashing commits before a pull request, drafting a PR description, or checking that a change is shaped to land. Don't use for generic git mechanics such as rebasing, resolving conflicts, cherry-picking, or branch surgery; those need no skill. Don't use to judge the content of a change (use adk-review) or for code style and naming (use adk-style).

/adk-style

Python style and codebase conventions for ADK (Agent Development Kit): private-by-default file visibility, imports, type hints, Pydantic v2 models, formatting, docstrings, logging, async I/O, file and test layout, and unit test structure. Use when writing or editing ADK source or tests, deciding whether a new file or symbol should be public or private, naming or placing a test file, fixing a formatter, linter, or type-check failure (pyink, isort, ruff, mypy, addlicense, compliance-checks), or asking whether code matches house style. Don't use for reviewing a whole changeset (use adk-review), writing a developer guide or design doc for a code unit (use adk-unit-guide or adk-unit-design), building or configuring agents (use adk-agent-builder), or installing the toolchain (use adk-setup).

/adk-unit-design

Writes an as-built architecture document for one ADK code unit โ€” purpose, execution flow, data flow, cross-class dependencies, extension points, and the parts that must not change โ€” to `docs/design/{topic}/{unit}/index.md`. It describes the code as implemented, not a proposed design, and its reader is a developer about to change or extend that unit. Use when asked to "write a design doc for {file}", "document the architecture of {class}", "document the extension points of {unit}", or after adding a core class, node type, or plugin base. Don't use for documentation aimed at developers who only call the unit from their own application โ€” that is a usage guide with runnable examples under `docs/guides/` (use `adk-unit-guide`). Don't use to answer a framework-wide architecture question (use `adk-architecture`).

/adk-verify-snippets

Checks that every Python code block in a Markdown file actually compiles and runs, by extracting each block to a temporary file, executing it in an isolated subprocess, and writing a pass/fail report with per-snippet coverage. Use when the user asks to verify, test, or validate the code samples in a README, a guide, or a documentation page; wants to know which snippets in a Markdown file are broken or out of date; or asks for a snippet verification report. Don't use for running the project's test suite (run pytest directly), for checking code style or formatting (use `adk-style`), or for authoring a new runnable sample agent (use `adk-sample-creator`).

The badge links readers to this page. It shows the skilld mark and no counts, and it follows the reader's light or dark GitHub theme.

<a href="https://skilld.dev/gh/google/adk-python"> <picture> <source media="(prefers-color-scheme: dark)" srcset="https://skilld.dev/b/google/adk-python?theme=dark"> <source media="(prefers-color-scheme: light)" srcset="https://skilld.dev/b/google/adk-python?theme=light"> <img alt="Skill repository on skilld.dev" src="https://skilld.dev/b/google/adk-python?theme=light"> </picture> </a>