[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M698YSCG645WR5X1R4F9YRQ5":3,"skill-same:01M698YSCG645WR5X1R4F9YRQ5":80},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":55,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":73},"01M698YSCG645WR5X1R4F9YRQ5","adk-unit-guide",null,"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\u002Fguides\u002F{topic}\u002F{unit}\u002Findex.md`, then lists it in the index at `docs\u002Fguides\u002FREADME.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\u002Fdesign\u002F` (use `adk-unit-design`). Don't use to write a runnable sample under `contributing\u002Fsamples\u002F` (use `adk-sample-creator`).","google\u002Fadk-python","google","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1342004?v=4","01M698VYEFDM0VJBZDYYJ2T83S","Google","01M698XZC2HCATT8VD5VAVZDTP",22203,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-python\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fadk-unit-guide\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"adk unit guide","adk","unit","guide","node","when","at","advanced","add","guides","how to","sample","write","design","option","how","contributing","shipping","code","documentation","docs","2026-11-10 10:12:30",false,"---\nname: adk-unit-guide\ndescription: >-\n  Writes a hands-on developer guide for one ADK code unit — a minimal runnable\n  example, how it works, a configuration-option table, advanced uses,\n  limitations, and links to related samples — to\n  `docs\u002Fguides\u002F{topic}\u002F{unit}\u002Findex.md`, then lists it in the index at\n  `docs\u002Fguides\u002FREADME.md`. Its reader is a developer calling the unit from their\n  own application, at more depth than the published adk.dev documentation\n  carries. Use when asked to \"write a unit guide for {class}\", \"document how to\n  use {feature}\", \"add a guide for {file}\", or after shipping a user-facing\n  class, node, or plugin. Don't use for internals documentation aimed at someone\n  changing or extending the unit — that is a design document under\n  `docs\u002Fdesign\u002F` (use `adk-unit-design`). Don't use to write a runnable sample\n  under `contributing\u002Fsamples\u002F` (use `adk-sample-creator`).\n---\n\n# ADK code unit guide\n\nA unit guide is granular usage documentation for one code unit, deeper than what\nships on adk.dev — so detail that would bloat the published documentation has\nsomewhere to live. The reader wants to call the unit from an application, so\nlead with working code.\n\nUnit guides focus on public APIs and caller-visible behavior. Do not\ndiscuss internal implementation details (such as private methods, internal state\nmechanisms, or unexported helpers).\n\n## Voice\n\nWrite to help the reader understand, not to instruct them from above.\n\n- **Give the reason, not only the rule.** Whenever the guide states a\n  constraint, a default, or a recommendation, say why it is that way. A reader\n  who knows the reason can handle the case the guide did not anticipate.\n- **Do not decide for the reader.** Phrasings such as \"most applications never\n  need this\" or \"you will rarely\" tell people what they want. State the\n  trade-off and let them choose.\n- **Explain at the caller's level.** Explaining what happens is required;\n  explaining the machinery that makes it happen is not. If an explanation needs\n  a private symbol to make sense, it is pitched at the wrong layer.\n- **Length follows understanding.** Brevity is not the goal. Where a reader\n  would have a follow-up question, answer it. Where the sentence already lands,\n  leave it.\n- **Problem before syntax.** Say what the reader is trying to do, then show the\n  code.\n- Every heading has at least one sentence under it before the next heading, and\n  every code block has a sentence introducing what it does.\n\nSentence-level rules, following the Google developer documentation style guide:\npresent tense, no contractions, no parentheticals (use commas), no bare \"This\"\nas a subject, no `e.g.` or `etc.`, no superlatives, sentence case in headings,\nand no heading deeper than H3.\n\n### What the difference looks like\n\nFrom the `BaseNode` guide. Before:\n\n> Most applications never subclass `BaseNode`, so the sections that follow cover\n> the settings first.\n\nThat decides for the reader and gives them nothing to check their own case\nagainst. After:\n\n> You usually configure a node rather than subclass one, because the settings\n> below cover what most graphs need. Subclassing earns its keep when you want\n> behavior the settings cannot express, and that case is at the end.\n\nSame length, same facts. The second one names the reason, so a reader can tell\nwhich of the two situations is theirs.\n\nA second pair, from the `JoinNode` guide. Before:\n\n> Here three tasks run in parallel on the same input, and a `JoinNode` collects\n> their results.\n\nThat opens in speech rather than documentation, and it drops the name of the\npattern the reader would search for. After:\n\n> This example builds a fan-out\u002Ffan-in workflow. Three tasks run in parallel on\n> the same input, and a `JoinNode` aggregates their results so that a final node\n> can present all three together.\n\n## Inputs\n\nRequire the source file, or a class or method named inside it. Also read, when\nthey exist: its unit tests (they give you an example to adapt) and its design\ndocument at `docs\u002Fdesign\u002F{topic}\u002F{unit}\u002Findex.md`.\n\n## Analyse before writing\n\n- Purpose and intended use of the unit.\n- Which classes depend on it, and which it depends on.\n- Configuration options the unit itself introduces, ignoring inherited ones.\n- Known limitations.\n- Exclude internal implementation details such as private methods and\n  attributes, internal helper functions, private execution state, or internal\n  data structures.\n\n## Where the guide goes\n\nMirror the source path under `docs\u002Fguides\u002F`, one directory per unit, guide named\n`index.md`. Drop the leading underscore of a private module:\n\n| Source | Guide |\n| :--- | :--- |\n| `src\u002Fgoogle\u002Fadk\u002Fworkflow\u002F_function_node.py` | `docs\u002Fguides\u002Fworkflow\u002Ffunction_node\u002Findex.md` |\n| `src\u002Fgoogle\u002Fadk\u002Fplugins\u002Freflect_retry_tool_plugin.py` | `docs\u002Fguides\u002Fplugins\u002Freflect_retry_tool_plugin\u002Findex.md` |\n\nUse named files instead of `index.md` only when one source file has genuinely\nseparate usage modes — `docs\u002Fguides\u002Fagents\u002Fllm_agent\u002F` holds `single_turn.md`\nand `task.md` for that reason.\n\nUpdate an existing guide in place, keeping the existing wording wherever the\ncode has not changed, so the diff shows only what the change actually altered.\n\nThen add the guide to `docs\u002Fguides\u002FREADME.md` under the right category heading,\nas `* [Title](path\u002Findex.md) - one-line summary.` That index is the only table\nof contents; a guide missing from it is unreachable.\n\n## When a guide is not required\n\n`scripts\u002Fcheck_new_py_files.py` enforces this convention on the Python files a\nchange adds under `src\u002Fgoogle\u002Fadk\u002F`. Some it passes over without asking, and\nthe rest you can waive, so work out which case you are in before writing a\nguide the rule does not ask for.\n\nThree subtrees sit outside the rule, because nothing in them is published:\n`src\u002Fgoogle\u002Fadk\u002Finternal\u002F`, `src\u002Fgoogle\u002Fadk\u002Fplatform\u002Finternal\u002F`, and\n`src\u002Fgoogle\u002Fadk\u002Fv1\u002F`.\n\nElsewhere a file is exempt on one of two grounds. It carries no unit of its\nown, which covers `__init__.py` and any path with a `cli\u002F` or `utils\u002F`\ncomponent. Or it holds declarations that belong in the guide of whatever uses\nthem rather than in a guide of their own, which covers any filename ending\n`_utils.py`, `_helper.py`, `_helpers.py`, `_types.py`, `_errors.py`,\n`_exceptions.py`, or `_constants.py`.\n\nA module is also exempt when no package `__init__.py` imports from it or names\nit, because then it has no public interface for a guide to describe. The check\nreads every `__init__.py` under `src\u002Fgoogle\u002Fadk\u002F`, and lazy re-exports count:\nan import under `if TYPE_CHECKING:` or inside `__getattr__`, and a string that\nnames the module in a lazy-import table. A `_`-prefixed name bound in\n`__init__.py`, such as `from ._mod import X as _X`, is private to that file and\ndoes not count as an export. The module's own `_` prefix decides nothing, so\nexport a public name from a new module and that module needs a guide.\n\nA page that documents several units covers each of them. The check reads every\npage in the module's own directory under `docs\u002Fguides\u002F` and below it, plus the\n`index.md` of each directory above that one, and passes the module when those\npages document everything the package exports from it. That is how\n`docs\u002Fguides\u002Ferrors\u002Findex.md`, one page for all of `google.adk.errors`, covers\n`InvocationNotFoundError`. The names come from the same imports and lazy-import\ntables, so a star import or `from . import _mod`, which take the module whole\nwithout naming anything, leaves it needing a page of its own, even when another\nimport names some of its exports. So does a module at the package root. Pages\nanywhere else are not read: `docs\u002Fguides\u002FREADME.md` is the table of contents\nand names nearly every unit, and a module documented only in another topic's\nguide still needs a waiver.\n\nA page documents a name where a heading, the first cell of a table row, or a\nfenced code example names it. A mention in prose or in another table column\n(such as a type column) only refers to the unit, so it does not count: the\n`InvocationContext` guide names `SequentialAgent` once, in passing, and says\nnothing else about it. Each name has to match as a whole word, so `RunResultV2`\ndoes not document `RunResult`.\n\nEverything else needs a guide or a waiver. A waiver is a `NO_UNIT_GUIDE=` or\n`SKIP_UNIT_GUIDE=` tag carrying the reason, and the two names behave\nidentically. It waives the unit guide requirement alone; the `_` prefix rule\nshares the same hook and the same error report, and has no waiver at all. One\ntag waives every file the change adds, not the one its reason names, so a\nchange adding several needs a reason that covers all of them.\n\nWrite a reason a reviewer can check against the code, because the tag becomes\nthe only record of why the guide is absent:\n\n```\nNO_UNIT_GUIDE=ElevenLabsTTS is shown in docs\u002Fguides\u002Flive\u002Fcascade_live\u002Findex.md, a guide in another topic.\n```\n\n### Where to put the waiver\n\nThe tag reaches the check through a commit message or through the environment,\nand which one applies depends on whether the commit exists yet.\n\nOnce the commit exists, its message carries the tag. Continuous integration\nreads the messages of the commits a pull request contains, so a waiver a\ncontributor writes there satisfies the check that gates the pull request. Start\nthe tag at the left margin with no space before the `=`, because the check\nmatches at the start of a line. An indented tag, or one inside a list item, is\nnot found, and nothing reports the miss.\n\nThe environment carries the tag for a commit that does not exist yet:\n\n```\nNO_UNIT_GUIDE='shown in docs\u002Fguides\u002Flive\u002Fcascade_live\u002Findex.md' git commit ...\n```\n\nReach for that form when the pre-commit hook stops you. A pre-commit hook runs\nbefore git records your message anywhere, and the check declines to read the\nprevious commit's message in its place, so the environment is the channel left\nopen. Quote the reason: an unquoted one ends at the first space, and the shell\ntakes the next word for the command to run, so no commit happens at all. Write\nthe tag into the message as well, so the reason survives in the history rather\nthan only in the shell that ran the commit.\n\nA tag carrying no reason waives nothing, in either channel. The reason is the\nonly record of the decision, so a waiver without one leaves nothing to review.\n\n## Code examples\n\n- One minimal example under \"Get started\", with enough of the surrounding\n  classes to show where the call belongs. Start from a unit test if one exists.\n- Keep the `google.adk` import lines, because the import path is the single\n  most error-prone thing a reader copies. Omit unrelated standard-library\n  imports and `asyncio.run(main())` runner boilerplate, which add nothing about\n  the unit.\n- Show what a developer would actually write. An example that only demonstrates\n  the shape of an interface, or that drives a service the reader would normally\n  reach through `Runner`, does not belong in a guide.\n- Do not set `model=` on a sample agent — guides stay model-agnostic, and no\n  guide in `docs\u002Fguides\u002F` currently pins a model.\n- For workflow nodes, show the logic as a plain Python function rather than a\n  `BaseNode` subclass, unless the use case genuinely requires the subclass.\n- Wrap a function as a node with the `@node` decorator rather than\n  `FunctionNode` directly, except when demonstrating `FunctionNode`\n  configuration itself.\n\n## Link related samples\n\nLink samples by repo-relative path from the guide, not by GitHub URL:\n`[Node Output](..\u002F..\u002F..\u002F..\u002Fcontributing\u002Fsamples\u002Fworkflows\u002Fnode_output\u002Fagent.py)`.\nConfirm the file exists before linking it.\n\n## Structure\n\nFollow [references\u002Fguide-template.md](references\u002Fguide-template.md) section by\nsection.\n","# ADK code unit guide\n\nA unit guide is granular usage documentation for one code unit, deeper than what\nships on adk.dev — so detail that would bloat the published documentation has\nsomewhere to live. The reader wants to call the unit from an application, so\nlead with working code.\n\nUnit guides focus on public APIs and caller-visible behavior. Do not\ndiscuss internal implementation details (such as private methods, internal state\nmechanisms, or unexported helpers).\n\n## Voice\n\nWrite to help the reader understand, not to instruct them from above.\n\n- **Give the reason, not only the rule.** Whenever the guide states a\n  constraint, a default, or a recommendation, say why it is that way. A reader\n  who knows the reason can handle the case the guide did not anticipate.\n- **Do not decide for the reader.** Phrasings such as \"most applications never\n  need this\" or \"you will rarely\" tell people what they want. State the\n  trade-off and let them choose.\n- **Explain at the caller's level.** Explaining what happens is required;\n  explaining the machinery that makes it happen is not. If an explanation needs\n  a private symbol to make sense, it is pitched at the wrong layer.\n- **Length follows understanding.** Brevity is not the goal. Where a reader\n  would have a follow-up question, answer it. Where the sentence already lands,\n  leave it.\n- **Problem before syntax.** Say what the reader is trying to do, then show the\n  code.\n- Every heading has at least one sentence under it before the next heading, and\n  every code block has a sentence introducing what it does.\n\nSentence-level rules, following the Google developer documentation style guide:\npresent tense, no contractions, no parentheticals (use commas), no bare \"This\"\nas a subject, no `e.g.` or `etc.`, no superlatives, sentence case in headings,\nand no heading deeper than H3.\n\n### What the difference looks like\n\nFrom the `BaseNode` guide. Before:\n\n> Most applications never subclass `BaseNode`, so the sections that follow cover\n> the settings first.\n\nThat decides for the reader and gives them nothing to check their own case\nagainst. After:\n\n> You usually configure a node rather than subclass one, because the settings\n> below cover what most graphs need. Subclassing earns its keep when you want\n> behavior the settings cannot express, and that case is at the end.\n\nSame length, same facts. The second one names the reason, so a reader can tell\nwhich of the two situations is theirs.\n\nA second pair, from the `JoinNode` guide. Before:\n\n> Here three tasks run in parallel on the same input, and a `JoinNode` collects\n> their results.\n\nThat opens in speech rather than documentation, and it drops the name of the\npattern the reader would search for. After:\n\n> This example builds a fan-out\u002Ffan-in workflow. Three tasks run in parallel on\n> the same input, and a `JoinNode` aggregates their results so that a final node\n> can present all three together.\n\n## Inputs\n\nRequire the source file, or a class or method named inside it. Also read, when\nthey exist: its unit tests (they give you an example to adapt) and its design\ndocument at `docs\u002Fdesign\u002F{topic}\u002F{unit}\u002Findex.md`.\n\n## Analyse before writing\n\n- Purpose and intended use of the unit.\n- Which classes depend on it, and which it depends on.\n- Configuration options the unit itself introduces, ignoring inherited ones.\n- Known limitations.\n- Exclude internal implementation details such as private methods and\n  attributes, internal helper functions, private execution state, or internal\n  data structures.\n\n## Where the guide goes\n\nMirror the source path under `docs\u002Fguides\u002F`, one directory per unit, guide named\n`index.md`. Drop the leading underscore of a private module:\n\n| Source | Guide |\n| :--- | :--- |\n| `src\u002Fgoogle\u002Fadk\u002Fworkflow\u002F_function_node.py` | `docs\u002Fguides\u002Fworkflow\u002Ffunction_node\u002Findex.md` |\n| `src\u002Fgoogle\u002Fadk\u002Fplugins\u002Freflect_retry_tool_plugin.py` | `docs\u002Fguides\u002Fplugins\u002Freflect_retry_tool_plugin\u002Findex.md` |\n\nUse named files instead of `index.md` only when one source file has genuinely\nseparate usage modes — `docs\u002Fguides\u002Fagents\u002Fllm_agent\u002F` holds `single_turn.md`\nand `task.md` for that reason.\n\nUpdate an existing guide in place, keeping the existing wording wherever the\ncode has not changed, so the diff shows only what the change actually altered.\n\nThen add the guide to `docs\u002Fguides\u002FREADME.md` under the right category heading,\nas `* [Title](path\u002Findex.md) - one-line summary.` That index is the only table\nof contents; a guide missing from it is unreachable.\n\n## When a guide is not required\n\n`scripts\u002Fcheck_new_py_files.py` enforces this convention on the Python files a\nchange adds under `src\u002Fgoogle\u002Fadk\u002F`. Some it passes over without asking, and\nthe rest you can waive, so work out which case you are in before writing a\nguide the rule does not ask for.\n\nThree subtrees sit outside the rule, because nothing in them is published:\n`src\u002Fgoogle\u002Fadk\u002Finternal\u002F`, `src\u002Fgoogle\u002Fadk\u002Fplatform\u002Finternal\u002F`, and\n`src\u002Fgoogle\u002Fadk\u002Fv1\u002F`.\n\nElsewhere a file is exempt on one of two grounds. It carries no unit of its\nown, which covers `__init__.py` and any path with a `cli\u002F` or `utils\u002F`\ncomponent. Or it holds declarations that belong in the guide of whatever uses\nthem rather than in a guide of their own, which covers any filename ending\n`_utils.py`, `_helper.py`, `_helpers.py`, `_types.py`, `_errors.py`,\n`_exceptions.py`, or `_constants.py`.\n\nA module is also exempt when no package `__init__.py` imports from it or names\nit, because then it has no public interface for a guide to describe. The check\nreads every `__init__.py` under `src\u002Fgoogle\u002Fadk\u002F`, and lazy re-exports count:\nan import under `if TYPE_CHECKING:` or inside `__getattr__`, and a string that\nnames the module in a lazy-import table. A `_`-prefixed name bound in\n`__init__.py`, such as `from ._mod import X as _X`, is private to that file and\ndoes not count as an export. The module's own `_` prefix decides nothing, so\nexport a public name from a new module and that module needs a guide.\n\nA page that documents several units covers each of them. The check reads every\npage in the module's own directory under `docs\u002Fguides\u002F` and below it, plus the\n`index.md` of each directory above that one, and passes the module when those\npages document everything the package exports from it. That is how\n`docs\u002Fguides\u002Ferrors\u002Findex.md`, one page for all of `google.adk.errors`, covers\n`InvocationNotFoundError`. The names come from the same imports and lazy-import\ntables, so a star import or `from . import _mod`, which take the module whole\nwithout naming anything, leaves it needing a page of its own, even when another\nimport names some of its exports. So does a module at the package root. Pages\nanywhere else are not read: `docs\u002Fguides\u002FREADME.md` is the table of contents\nand names nearly every unit, and a module documented only in another topic's\nguide still needs a waiver.\n\nA page documents a name where a heading, the first cell of a table row, or a\nfenced code example names it. A mention in prose or in another table column\n(such as a type column) only refers to the unit, so it does not count: the\n`InvocationContext` guide names `SequentialAgent` once, in passing, and says\nnothing else about it. Each name has to match as a whole word, so `RunResultV2`\ndoes not document `RunResult`.\n\nEverything else needs a guide or a waiver. A waiver is a `NO_UNIT_GUIDE=` or\n`SKIP_UNIT_GUIDE=` tag carrying the reason, and the two names behave\nidentically. It waives the unit guide requirement alone; the `_` prefix rule\nshares the same hook and the same error report, and has no waiver at all. One\ntag waives every file the change adds, not the one its reason names, so a\nchange adding several needs a reason that covers all of them.\n\nWrite a reason a reviewer can check against the code, because the tag becomes\nthe only record of why the guide is absent:\n\n```\nNO_UNIT_GUIDE=ElevenLabsTTS is shown in docs\u002Fguides\u002Flive\u002Fcascade_live\u002Findex.md, a guide in another topic.\n```\n\n### Where to put the waiver\n\nThe tag reaches the check through a commit message or through the environment,\nand which one applies depends on whether the commit exists yet.\n\nOnce the commit exists, its message carries the tag. Continuous integration\nreads the messages of the commits a pull request contains, so a waiver a\ncontributor writes there satisfies the check that gates the pull request. Start\nthe tag at the left margin with no space before the `=`, because the check\nmatches at the start of a line. An indented tag, or one inside a list item, is\nnot found, and nothing reports the miss.\n\nThe environment carries the tag for a commit that does not exist yet:\n\n```\nNO_UNIT_GUIDE='shown in docs\u002Fguides\u002Flive\u002Fcascade_live\u002Findex.md' git commit ...\n```\n\nReach for that form when the pre-commit hook stops you. A pre-commit hook runs\nbefore git records your message anywhere, and the check declines to read the\nprevious commit's message in its place, so the environment is the channel left\nopen. Quote the reason: an unquoted one ends at the first space, and the shell\ntakes the next word for the command to run, so no commit happens at all. Write\nthe tag into the message as well, so the reason survives in the history rather\nthan only in the shell that ran the commit.\n\nA tag carrying no reason waives nothing, in either channel. The reason is the\nonly record of the decision, so a waiver without one leaves nothing to review.\n\n## Code examples\n\n- One minimal example under \"Get started\", with enough of the surrounding\n  classes to show where the call belongs. Start from a unit test if one exists.\n- Keep the `google.adk` import lines, because the import path is the single\n  most error-prone thing a reader copies. Omit unrelated standard-library\n  imports and `asyncio.run(main())` runner boilerplate, which add nothing about\n  the unit.\n- Show what a developer would actually write. An example that only demonstrates\n  the shape of an interface, or that drives a service the reader would normally\n  reach through `Runner`, does not belong in a guide.\n- Do not set `model=` on a sample agent — guides stay model-agnostic, and no\n  guide in `docs\u002Fguides\u002F` currently pins a model.\n- For workflow nodes, show the logic as a plain Python function rather than a\n  `BaseNode` subclass, unless the use case genuinely requires the subclass.\n- Wrap a function as a node with the `@node` decorator rather than\n  `FunctionNode` directly, except when demonstrating `FunctionNode`\n  configuration itself.\n\n## Link related samples\n\nLink samples by repo-relative path from the guide, not by GitHub URL:\n`[Node Output](..\u002F..\u002F..\u002F..\u002Fcontributing\u002Fsamples\u002Fworkflows\u002Fnode_output\u002Fagent.py)`.\nConfirm the file exists before linking it.\n\n## Structure\n\nFollow [references\u002Fguide-template.md](references\u002Fguide-template.md) section by\nsection.\n",{"name":5,"description":7},"main","8cd3b12c8a5d658c5e0d3ea0731d8be34a092a4a",".agents\u002Fskills\u002Fadk-unit-guide",4355,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-python","https:\u002F\u002Fgoogle.github.io\u002Fadk-docs\u002F","https:\u002F\u002Fgithub.com\u002Fgoogle","https:\u002F\u002Fopensource.google\u002F","Google ❤️ Open Source","2026-11-14 01:11:23",{"source":8,"skillName":5,"commands":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add google\u002Fadk-python --skill adk-unit-guide",{"tool":66,"command":67},"bunx","bunx skills add google\u002Fadk-python --skill adk-unit-guide",{"tool":69,"command":70},"pnpm","pnpm dlx skills add google\u002Fadk-python --skill adk-unit-guide","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-python\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fadk-unit-guide\u002FSKILL.md",true,[74],{"path":75,"resourceType":76,"resourceTypeDesc":77,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fguide-template.md","REFERENCE","参考文档",1879,"https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-python\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fadk-unit-guide\u002Freferences\u002Fguide-template.md",[81,113,139,164,180,188],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":95,"publishedAt":45},"01M698ZJNXJCE7T81AK0Y5R01D","bigquery-graph","Skill for Graph Query Language (GQL) or SQL\u002FPGQ queries against a property graph.\nIncludes path finding, multi-hop traversal, topological connection, shortest path,\nnode reachability, edge connectivity, and semantic graph queries.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-python\u002Fblob\u002Fmain\u002Fsrc\u002Fgoogle\u002Fadk\u002Fintegrations\u002Fbigquery\u002Fskills\u002Fbigquery-graph\u002FSKILL.md",[87,92],{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":93,"categoryName":94,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师",[96,97,98,9,99,25,100,101,102,103,28,104,105,106,107,108,109,110,111,112],"graph","bigquery","bigquery graph","for","sql","edge","graph query","hop","queries","language","query","connectivity","gql","semantic","multi","connection","path",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":120,"publishedAt":45},"01M698ZEVMRDDFX2MH3GHQGSNW","bigquery-ai-ml","Leverages BigQuery's built-in machine learning and GenAI capabilities for advanced data analytics. Use when you need to write SQL queries that perform time-series forecasting, predict values, detect outliers or anomalies, find key drivers, perform semantic search or vector search, classify text, calculate similarity, summarize content, translate language, evaluate models, filter by semantic conditions, measure the causal effect of an intervention, compute correlations between columns, detect change points or structural breaks, extract trend or seasonality components, or leverage generative AI capabilities in BigQuery. Do not use for general BigQuery dataset, table, or job management requests.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-python\u002Fblob\u002Fmain\u002Fsrc\u002Fgoogle\u002Fadk\u002Fintegrations\u002Fbigquery\u002Fskills\u002Fbigquery-ai-ml\u002FSKILL.md",[119],{"categoryNo":93,"categoryName":94,"taxonomyType":21,"taxonomyTypeDesc":22},[121,97,122,123,124,29,125,126,31,127,128,129,130,131,132,9,133,134,25,135,136,137,138],"ai ml","ml","bigquery ai ml","vector","generative","you","dataset","leverage","structural","time","effect","search","summarize","genai","generative ai","translate","components","capabilities",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":150,"publishedAt":45},"01M698ZCN6SZ9SJ8E9970M47FQ","code-review-skill","Reviews code with feedback tailored to the developer's profile in session state.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-python\u002Fblob\u002Fmain\u002Fcontributing\u002Fsamples\u002Fenvironment_and_skills\u002Fskills_inject_state\u002Fskills\u002Fcode-review-skill\u002FSKILL.md",[145,148,149],{"categoryNo":146,"categoryName":147,"taxonomyType":90,"taxonomyTypeDesc":91},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[151,42,152,153,154,155,156,157,158,159,160,161,162,163],"review skill","code review skill","review","code review","session","state","developer","feedback","profile","with","session state","reviews","true",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":171,"publishedAt":45},"01M698ZAMH02NSGXMR533ETWYW","weather-skill","A skill that provides weather information based on reference data.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-python\u002Fblob\u002Fmain\u002Fcontributing\u002Fsamples\u002Fenvironment_and_skills\u002Fskills_agent\u002Fskills\u002Fweather-skill\u002FSKILL.md",[170],{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},[172,173,174,175,176,177,178,179],"weather skill","weather","data","reference","speed","get","wind","information",{"skillNo":181,"name":166,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":186,"publishedAt":45},"01M698Z8QFDZ713E03589BHEG5","A skill that provides weather information based on reference data and scripts.","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-python\u002Fblob\u002Fmain\u002Fcontributing\u002Fsamples\u002Fenvironment_and_skills\u002Fskills\u002Fskills\u002Fweather-skill\u002FSKILL.md",[185],{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},[173,172,179,178,187,177,176,175,174],"scripts",{"skillNo":189,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":193,"publishedAt":45},"01M698Z6P1NZFW6A6V342AWZPR","https:\u002F\u002Fgithub.com\u002Fgoogle\u002Fadk-python\u002Fblob\u002Fmain\u002Fcontributing\u002Fsamples\u002Fenvironment_and_skills\u002Flocal_environment_skill\u002Fskills\u002Fweather-skill\u002FSKILL.md",[192],{"categoryNo":88,"categoryName":89,"taxonomyType":90,"taxonomyTypeDesc":91},[172,173,175,179,174]]