菜单
Use for a recurring unattended task (cron; pull data, open a PR, post a digest), or to test/dry-run a routine first. Explains authoring and testing via the routine tool.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/google/adk-samples --skill routines命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Makes an existing Python recipe deployable: generates the serving files a container needs (Dockerfile, .dockerignore, fast_api_app.py, app_utils/a2a.py, app_utils/services.py, app_utils/reasoning_engine_adapter.py) and configures the recipe to match (required serving dependencies, the App object in agent.py, the hatch wheel package, manifest.deployable). Interactive by design — it asks the recipe owner about runtime data directories and stops for a human decision when a recipe needs an ADK migration or carries a legacy app_utils generation. When docker is available it offers to PROVE the claim: it builds the generated Dockerfile, runs it, probes it, and refuses to flag a recipe deployable if the container does not come up. Does NOT deploy or write terraform. Use when the user wants to "make this recipe deployable", "add a Dockerfile to a recipe", "add the serving files", "containerize a recipe", "verify the container builds", or prepare a recipe for Cloud Build / Artifact Registry.
End-to-end orchestration to prepare or update a Python recipe under core/python/, contrib/python/, or skills/<vertical>/<solution>/ so it passes every check in .github/workflows/python-validate-recipe.yml. Runs eight 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, compile-and-run verification of the generated test file, and a final pass through the repo's own `validate manifest` / `validate structure` validators. 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 regeneratio
Creates virtual try-on agents supporting image and video (catwalk animation) try-ons on Google Cloud (Gemini image models and Veo on Gemini Enterprise Agent Platform). Handles resource setup, user photo uploading, image/video generation pipelines, local testing, and evaluation.
基于 SOC 职业分类
正在显示 SKILL.md
| name | routines |
| description | Use for a recurring unattended task (cron; pull data, open a PR, post a digest), or to test/dry-run a routine first. Explains authoring and testing via the routine tool. |
A routine is a recurring task that runs unattended on a cron schedule, in a fresh sandbox isolated from the user's workspace, holding only the secrets the routine declares. Use it for "every morning, summarize X and report" / "weekly, bump deps and open a PR" — work that should happen without the user present. There is no one-off reminder tool: it cannot ask the user anything mid-run, so it is the wrong fit for a plain "remind me at 9pm" ping.
lhart-<id>), never the user's — so it
cannot see their workspace, other projects, or undeclared secrets.secrets: — that list IS the
blast-radius boundary. Declare the minimum the task needs (check the "Available
secret env vars" line for the names).git clone, pip install, build, commit/push all
work, since the sandbox is the blast radius. Secret-exfiltration and
known-destructive commands are still refused, and any non-shell action that
would need approval is auto-denied — design the task to avoid those, or do an
irreversible external step as a draft for the user to confirm later.Call routine(action="create", name=..., schedule=..., task=..., secrets=[...]):
schedule: a 5-field cron expression ("0 8 * * *" = daily 08:00 UTC).task: a self-contained instruction — the routine has no memory of this chat
and no access to the user's files, so state everything it needs.secrets: the exact secret env names the task requires (e.g.
["GITHUB_PAT"]), or omit for none.ALWAYS dry-run a routine before you create it:
routine(action="test", name=..., task=..., secrets=[...])
This runs the task ONCE right now under the routine's real isolation — its own
lhart- sandbox, headless (shell runs; non-shell approvals denied), only the declared secrets —
and blocks until it finishes, returning {success, status, output, ...}. Read the
output: if the task didn't work (missing secret, needed an approval, wrong
assumption), fix task/secrets and test again. A test schedules nothing (no
schedule row, no chat session) — but it does provision the routine's real
lhart- sandbox, which the scheduled routine then reuses, so pass the same name
you'll create with. Then create.
The tool asks the user to confirm before scheduling. On the first call it
returns status: "awaiting_user_response" — stop, let the user decide, and do
NOT claim the routine is scheduled until you get success: true with an id.
Use routine(action="list") to show scheduled routines and
routine(action="cancel", id=...) to remove one (the user can also type
/routines / /routines remove <id>).