adk-samples

Transforms raw metrics and analysis into visual charts and published, shareable HTML reports using Google Cloud Storage.

Extracts the true audience mood and key feedback by analyzing comment sentiment and keyword frequency.

Provides an executive dashboard comparing Creator vs Audience verdicts for a recent client product launch.

Extracts specific local activity recommendations and sentiment from travel vlogs into a shareable HTML BD report.

Performs high-density targeted extraction across 10+ videos to map semantic landscapes, consensus, and controversies.

Identifies and ranks Key Opinion Leaders (KOLs) based on engagement metrics, active rate, and sentiment rather than just views.

Equips sellers with macro industry trends by analyzing trending data and specific analyst/competitor channels.

Saves time by autonomously reading transcripts, synthesizing arguments, and generating direct jump-links to key moments.

Extracts the strongest arguments from heated YouTube comment threads, identifying key battlegrounds and community consensus.

Provides a high-signal briefing on events in a specific location and timeframe, backed by primary video sources and transcripts.

Deconstructs high-performing or viral videos to extract actionable creative insights from metadata and transcript.

Performs a strict evaluation of a video asset using Google's official 'ABCD' framework (Attract, Brand, Connect, Direct) based on transcript and metadata.

Content research and SEO writing methodology. Guides the agent through topic research, keyword identification, competitive analysis, and writing SEO-optimized content that ranks well and provides genuine value to readers.

Blog post writing skill with structure templates and style guidelines. Guides the agent through writing well-structured, engaging technical blog posts with proper formatting, section flow, and reader engagement techniques.

This skill should be used when the user wants to "create a new Python ADK sample", "scaffold a new Python sample recipe", "generate a new Python sample in contrib", "add a new Python sample to the adk-samples repository", or "create a Python adk sample". It utilizes an automated script to copy template files and resolve basic placeholders.

End-to-end orchestration to prepare or update a Python recipe under core/python/, contrib/, or skills/python/ so it passes every check in .github/workflows/python-validate-recipe.yml. Runs seven phases in order on an already-in-place recipe: manifest.yaml generation, environment-variable extraction, pyproject.toml alignment, ruff format+check, per-recipe `uv lock`, runnability-test generation, and a final `py_compile` verification of the generated test file. Assumes the user has already done the manual prep (deactivated any venv, `git pull` and `uv sync` from the repo root, placed the recipe at its target path, renamed if needed). Delegates to the existing sub-skills (generate-manifest, extract-python-environment-variables, align-recipe-pyproject, generate-python-runnability-test) so the master never duplicates their logic. Pauses at fixed decision points (description mismatch, existing test regeneration) AND is free to interrupt for clarification any time a phase's output looks ambiguous, unexpected, or would benefit from a human judgment call — this is an interactive skill by design. Use when the user wants to "prepare a recipe", "update a recipe end to end", "run all the checks and fixes", "make this recipe PR-ready", or invokes it by name.

Generates a lightweight `tests/test_runnability.py` for a Python recipe. The test just imports the recipe's agent module and asserts that `root_agent is not None` (and `app is not None` if the module defines one). The skill parses agent.py with `ast` to figure out which import-time side effects need mocking (`vertexai.init`, `google.auth.default`) and which env vars need setting (`GOOGLE_CLOUD_PROJECT`, `INTEGRATION_TEST`), and only emits the boilerplate the recipe actually needs. Runs in dry-run (report + preview) and apply (write to disk) modes. Use when the user wants to "add a runnability test", "generate test_runnability.py", "create a smoke test for the recipe", or fix the missing-required-file failure from `python-validate-recipe.yml`.

Scan an ADK recipe directory and generate a manifest.yaml for it based on the schema at .github/schemas/manifest-schema.json. Use when the user wants to create or generate a manifest.yaml for a recipe under core/, contrib/, or skills/.

Scans a Python recipe to find every place an environment variable is accessed — including `os.environ.setdefault("V", "d")`, whose "d" would otherwise be a hidden default a user editing .env.example has no way to discover — then ensures all variables are declared in `.env.example`, that `load_dotenv()` is bootstrapped in the package `__init__.py`, and that `python-dotenv>=1.0.0` is listed in `pyproject.toml`. When a new entry is added to `.env.example`, the extracted default from source is written as the value (with a `# extracted-by:extract-env-vars` marker and provenance comment); values that look like stubs (`"my-project-id"`, `"changeme"`, `"<...>"`) are downgraded to the TODO placeholder but the source string is preserved in the marker comment. Also detects hardcoded model-name string literals (e.g. `"gemini-3.5-flash"` in `agent.py`) and rewrites them to bare `os.getenv("MODEL_NAME")` (single model) or `os.getenv("MODEL_NAME_GENERATED_1")` / `MODEL_NAME_GENERATED_2`, … (multiple models) — no fallback default in the Python source. The model string is written as the value in `.env.example` with a comment prompting a rename. When re-run against a recipe whose `.env.example` already has entries, the writer classifies each entry (skill-authored vs. user-authored, TODO vs. real value) and only rewrites lines it can prove it authored; user-authored lines are always preserved. A stale TODO (either skill-authored or a bare v1-era `<TODO: update-this-value>` with no inline comment) is upgraded in place when source can supply a real default. IMPORTANT — two hard rules the skill NEVER breaks: (1) USER-EDIT SAFETY. Any `.env.example` line the skill cannot prove it authored is USER_OWNED and is never modified. The rewriter fails closed on any structural ambiguity (quoted values, backslash continuation, duplicate declarations) — a stale TODO left in place is cheap; a clobbered user edit is not. (2) ADDITIVE-ONLY FOR PYTHON FILES. The skill never writes new `os.environ.setdefault(...)` bootstrap lines into any Python file. Pre-existing `os.environ.setdefault(...)` or `os.getenv("VAR", "default")` calls that the recipe author wrote by hand are LEFT UNTOUCHED — the skill's only writes to Python files are (a) the `load_dotenv()` bootstrap; (b) `# noqa: E402` on trailing relative imports that would otherwise trip Ruff; (c) hardcoded model-literal replacement. Use when the user wants to "extract env vars", "update .env.example", "add load_dotenv", "surface setdefault defaults", "upgrade stale TODOs in .env.example", "replace hardcoded model names", or "fix environment variables" in a Python recipe.

Aligns a Python recipe's pyproject.toml with the repo's standards enforced by .github/workflows/python-validate-recipe.yml, plus one critical [build-system] presence check. Scope is pyproject.toml only — standalone ruff.toml / .ruff.toml files (also forbidden in recipes) are caught by the CI workflow instead, not by this skill. Runs in two modes: a read-only --dry-run that reports what needs alignment, and an apply mode that rewrites pyproject.toml (and optionally manifest.yaml) using comment-preserving TOML/YAML editors. Use when the user wants to "align the recipe's pyproject.toml", "fix pyproject to match the repo standard", "check what needs changing in a recipe's pyproject", or clean up a recipe before submitting a PR.