{"owner":"google","repo":"adk-samples","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Agent Guidelines for adk-samples\nAll agents must follow the guidelines below without being reminded.\n\n## General\n- Use the term **recipe** instead of **sample** everywhere — responses,\n  code comments, commit messages, PR descriptions, docs.\n- Two different things are called \"skills\"; keep the terms straight:\n  - **Vertical skills** — recipes under `skills/<vertical>/<solution>/`\n    (e.g. `skills/retail/store-ops/`). Shipped to users.\n  - **Repo skills** — AI coding-assistant helpers under `.agents/skills/`\n    (e.g. `prepare-python-recipe`). Used to build this repo.\n- Recipes live under `core/` (curated), `contrib/` (community), or\n  `skills/` (vertical skills). Repo skills are a completely separate\n  concept. Do NOT mix `.agents/skills/` changes and recipe/vertical-skill\n  changes in the same PR. If a tool run modifies files outside your task's\n  scope (e.g. a repo-wide ruff sweep touching an unrelated recipe), revert\n  those and mention them so the user can decide.\n- When your task is scoped to a specific recipe or skill, stay inside its\n  directory. If you notice similar issues elsewhere, flag them in your\n  response instead of opportunistically fixing them.\n\n## Git\n- Never run `git commit`, `git push`, `git rebase`, `git merge`,\n  `gh pr create`, `gh pr merge`, or any other command that mutates git history\n  or the remote, unless the user's **most recent message** contains an\n  **explicit** request to do that specific action (e.g. \"commit this\",\n  \"push it\", \"create a PR\", \"open a PR\"). Even a request scoped to the exact\n  paths you have just modified needs the explicit verb.\n- If, after doing the requested work, there are uncommitted changes and you\n  believe they should be committed, **ask first**. Show the diff summary,\n  suggest a commit message, and wait for an explicit \"yes, commit\" or\n  \"yes, push\".\n- Safe read-only git commands are always fine: `git status`, `git diff`,\n  `git log`, `git show`, `git branch`, `gh pr view`, `gh pr list`.\n- Reverting your own uncommitted work (`git checkout <path>` on a working-tree\n  change you made in this session) is also fine — it undoes, it doesn't\n  mutate history.\n\n## Models\n- Do NOT use `gemini-2.0-flash` or `gemini-2.5-flash` — both are deprecated. Use `gemini-3.5-flash` instead.\n\n## Python\n- Python recipes go under `contrib/python/` or `core/python/`. Vertical\n  skills go under `skills/<vertical>/<solution>/` (e.g.\n  `skills/retail/store-ops/`) — that middle folder is a **vertical**, not a\n  language, and it is mandatory. A skill's language comes from\n  `manifest.language`.\n- Minimum python version: 3.11\n- Package manager: Use `uv`, not `pip`\n- Formatter/linter: `ruff` — line length 80, double quotes. Config lives\n  in the root `pyproject.toml`; never create a standalone `ruff.toml` or\n  `.ruff.toml` inside a recipe.\n- Test runner: `pytest`.\n- Do not rely on `.env` being present for the unit tests. However,\n  `.env.example` files are present for each recipe and the unit tests can\n  rely on those.\n"},"files":{"AGENTS.md":"# Agent Guidelines for adk-samples\nAll agents must follow the guidelines below without being reminded.\n\n## General\n- Use the term **recipe** instead of **sample** everywhere — responses,\n  code comments, commit messages, PR descriptions, docs.\n- Two different things are called \"skills\"; keep the terms straight:\n  - **Vertical skills** — recipes under `skills/<vertical>/<solution>/`\n    (e.g. `skills/retail/store-ops/`). Shipped to users.\n  - **Repo skills** — AI coding-assistant helpers under `.agents/skills/`\n    (e.g. `prepare-python-recipe`). Used to build this repo.\n- Recipes live under `core/` (curated), `contrib/` (community), or\n  `skills/` (vertical skills). Repo skills are a completely separate\n  concept. Do NOT mix `.agents/skills/` changes and recipe/vertical-skill\n  changes in the same PR. If a tool run modifies files outside your task's\n  scope (e.g. a repo-wide ruff sweep touching an unrelated recipe), revert\n  those and mention them so the user can decide.\n- When your task is scoped to a specific recipe or skill, stay inside its\n  directory. If you notice similar issues elsewhere, flag them in your\n  response instead of opportunistically fixing them.\n\n## Git\n- Never run `git commit`, `git push`, `git rebase`, `git merge`,\n  `gh pr create`, `gh pr merge`, or any other command that mutates git history\n  or the remote, unless the user's **most recent message** contains an\n  **explicit** request to do that specific action (e.g. \"commit this\",\n  \"push it\", \"create a PR\", \"open a PR\"). Even a request scoped to the exact\n  paths you have just modified needs the explicit verb.\n- If, after doing the requested work, there are uncommitted changes and you\n  believe they should be committed, **ask first**. Show the diff summary,\n  suggest a commit message, and wait for an explicit \"yes, commit\" or\n  \"yes, push\".\n- Safe read-only git commands are always fine: `git status`, `git diff`,\n  `git log`, `git show`, `git branch`, `gh pr view`, `gh pr list`.\n- Reverting your own uncommitted work (`git checkout <path>` on a working-tree\n  change you made in this session) is also fine — it undoes, it doesn't\n  mutate history.\n\n## Models\n- Do NOT use `gemini-2.0-flash` or `gemini-2.5-flash` — both are deprecated. Use `gemini-3.5-flash` instead.\n\n## Python\n- Python recipes go under `contrib/python/` or `core/python/`. Vertical\n  skills go under `skills/<vertical>/<solution>/` (e.g.\n  `skills/retail/store-ops/`) — that middle folder is a **vertical**, not a\n  language, and it is mandatory. A skill's language comes from\n  `manifest.language`.\n- Minimum python version: 3.11\n- Package manager: Use `uv`, not `pip`\n- Formatter/linter: `ruff` — line length 80, double quotes. Config lives\n  in the root `pyproject.toml`; never create a standalone `ruff.toml` or\n  `.ruff.toml` inside a recipe.\n- Test runner: `pytest`.\n- Do not rely on `.env` being present for the unit tests. However,\n  `.env.example` files are present for each recipe and the unit tests can\n  rely on those.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Agent Guidelines for adk-samples\nAll agents must follow the guidelines below without being reminded.\n\n## General\n- Use the term **recipe** instead of **sample** everywhere — responses,\n  code comments, commit messages, PR descriptions, docs.\n- Two different things are called \"skills\"; keep the terms straight:\n  - **Vertical skills** — recipes under `skills/<vertical>/<solution>/`\n    (e.g. `skills/retail/store-ops/`). Shipped to users.\n  - **Repo skills** — AI coding-assistant helpers under `.agents/skills/`\n    (e.g. `prepare-python-recipe`). Used to build this repo.\n- Recipes live under `core/` (curated), `contrib/` (community), or\n  `skills/` (vertical skills). Repo skills are a completely separate\n  concept. Do NOT mix `.agents/skills/` changes and recipe/vertical-skill\n  changes in the same PR. If a tool run modifies files outside your task's\n  scope (e.g. a repo-wide ruff sweep touching an unrelated recipe), revert\n  those and mention them so the user can decide.\n- When your task is scoped to a specific recipe or skill, stay inside its\n  directory. If you notice similar issues elsewhere, flag them in your\n  response instead of opportunistically fixing them.\n\n## Git\n- Never run `git commit`, `git push`, `git rebase`, `git merge`,\n  `gh pr create`, `gh pr merge`, or any other command that mutates git history\n  or the remote, unless the user's **most recent message** contains an\n  **explicit** request to do that specific action (e.g. \"commit this\",\n  \"push it\", \"create a PR\", \"open a PR\"). Even a request scoped to the exact\n  paths you have just modified needs the explicit verb.\n- If, after doing the requested work, there are uncommitted changes and you\n  believe they should be committed, **ask first**. Show the diff summary,\n  suggest a commit message, and wait for an explicit \"yes, commit\" or\n  \"yes, push\".\n- Safe read-only git commands are always fine: `git status`, `git diff`,\n  `git log`, `git show`, `git branch`, `gh pr view`, `gh pr list`.\n- Reverting your own uncommitted work (`git checkout <path>` on a working-tree\n  change you made in this session) is also fine — it undoes, it doesn't\n  mutate history.\n\n## Models\n- Do NOT use `gemini-2.0-flash` or `gemini-2.5-flash` — both are deprecated. Use `gemini-3.5-flash` instead.\n\n## Python\n- Python recipes go under `contrib/python/` or `core/python/`. Vertical\n  skills go under `skills/<vertical>/<solution>/` (e.g.\n  `skills/retail/store-ops/`) — that middle folder is a **vertical**, not a\n  language, and it is mandatory. A skill's language comes from\n  `manifest.language`.\n- Minimum python version: 3.11\n- Package manager: Use `uv`, not `pip`\n- Formatter/linter: `ruff` — line length 80, double quotes. Config lives\n  in the root `pyproject.toml`; never create a standalone `ruff.toml` or\n  `.ruff.toml` inside a recipe.\n- Test runner: `pytest`.\n- Do not rely on `.env` being present for the unit tests. However,\n  `.env.example` files are present for each recipe and the unit tests can\n  rely on those.\n","category":"root","tokens":752}]}