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`).

Jump to install Review files

Repository: google/adk-python
Last source activity: August 13, 2026 at 00:03
Detected SKILL.md language: English
Stars: 21,709
Forks: 4,101

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with an AI assistant

Copy this prompt into the AI assistant you're using.

Follow https://skillsmp.com/skill-install/prompt.md to install only the Agent Skill at https://github.com/google/adk-python/tree/main/.agents/skills/adk-unit-design.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/google/adk-python --skill adk-unit-design

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer

2 files

SKILL.md

Source instructions · Read-only preview

name: adk-unit-design
description: 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 code unit design A unit design documents a code unit **as implemented**, the way a unit test exercises it as implemented. Nothing proposed or aspirational belongs in one. The reader is deciding what they may safely change, so answer "what breaks if I touch this?" — not "how do I call this?". ## Inputs Require the source file, or a class or method named inside it. Also read, when they exist: the base classes and interfaces the unit implements, its unit tests (the best evidence of intended behaviour), and example usage. ## Analyse before writing Answer each of these from the source. Anything the code does not show stays out of the document — do not infer a design intent from a name. - Purpose and intended use of the unit. - Execution flow, and the data that flows in and out. - Upstream dependencies, and which classes depend on this unit. - Extension surfaces: abstract methods, hooks, callbacks, configurable fields. - Constraints — what a subclass or caller must not change, and why. - Operational limitations. ## Where the document goes Mirror the source path under `docs/design/`, one directory per unit, document named `index.md`. Drop the leading underscore of a private module: | Source | Design document | | :--- | :--- | | `src/google/adk/workflow/_function_node.py` | `docs/design/workflow/function_node/index.md` | | `src/google/adk/events/event.py` | `docs/design/events/event/index.md` | If a document already exists at that path, update it in place and keep the existing wording wherever the code has not changed, so the diff shows only what the change actually altered. `docs/design/` does not exist in this repository yet — the first design document creates it. `docs/guides/` is the established sibling tree; match its directory shape. ## Link to GitHub, not to local paths These documents render on GitHub, where a local filesystem path is dead. Rewrite `{repo_root}/src/google/adk/{topic}/{unit}.py#L93` as `https://github.com/google/adk-python/blob/main/src/google/adk/{topic}/{unit}.py#L93`. ## Structure Follow [references/design-template.md](references/design-template.md) section by section.

View on GitHub

Back to search Back to installation

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).

2026-10-03

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).

2026-10-03

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`).

2026-10-01

View all from this repository

adk-unit-design

Source facts

Install options

Install with an AI assistant

Review the source files

More from this repository

Install with an AI assistant

More from this repository