google/agents-cli: skills and commands that teach a coding agent the Google Cloud agent stack

The gap agents-cli fills: your coding agent does not know the Google agent stack

A coding agent is good at Python and bad at the specific shape of an ADK project on Google Cloud. It does not know which scaffolding layout the platform expects, which metrics the eval harness offers, or how a deployment target is selected. The FAQ in the repository states the position plainly: agents-cli is a tool for coding agents, not a coding agent itself. The README frames the goal as giving your coding agent the skills and commands to build, scale, govern, and optimize enterprise-grade agents so you do not have to learn every CLI and service yourself.

The audience is therefore narrow and identifiable. You are already using Claude Code, Codex, Antigravity CLI or something similar as your daily driver. You are building on ADK, the Agent Development Kit, and you intend to run the result on Google Cloud rather than on your laptop. If any of those three is false, the tool has less to offer you. The README is explicit that local development through create, run and eval does not require Google Cloud, and that an AI Studio API key is enough to run Gemini with ADK locally. That distinction matters, because it means the evaluation half of the tool is usable before you have a billing relationship with Google.

How the mechanism actually works: skill files plus a CLI, not a runtime

There is no agent runtime here. The architecture is two layers. The first is a set of skill files that get installed into your coding agent. The README lists seven: google-agents-cli-workflow for lifecycle and model selection, google-agents-cli-adk-code for the ADK Python API including agents, tools, orchestration, callbacks and state, google-agents-cli-scaffold for create, enhance and upgrade, google-agents-cli-eval for metrics, datasets and LLM-as-judge grading, google-agents-cli-deploy for Agent Runtime, Cloud Run, GKE, CI/CD and secrets, google-agents-cli-publish for Gemini registration, and google-agents-cli-observability for Cloud Trace, logging and third-party integrations.

The second layer is the CLI itself, which the agent invokes. The data flow described in the README is a loop: agents-cli eval generate runs inference over the eval cases, agents-cli eval grade scores the resulting traces against metrics, agents-cli eval analyze clusters failure modes out of the grade results, and agents-cli eval optimize auto-tunes agent prompts using that eval data. The eval run command is documented as doing inference and grading in one step. This is the part of the project with the clearest internal logic: traces are the unit of work, metrics are applied to traces, and prompt tuning consumes the graded output. The scaffold layer sits underneath, with create for new projects and enhance for adding deployment or CI/CD to something that already exists.

Installation and the commands you actually type

Prerequisites are Python 3.11 or newer, uv, and Node.js. Installation is a single uvx invocation: uvx google-agents-cli setup. The README offers a narrower path for people who want only the skills, npx skills add google/agents-cli, with the note that the coding agent will handle the rest. After that you open your coding agent and ask it to build something, with the README's own example being a request to use agents-cli to build a caveman-style agent that compresses verbose text into terse technical grunts.

For direct CLI use, the commands worth knowing are agents-cli login and agents-cli login --status for authentication against either Google Cloud or AI Studio, agents-cli create <name> to scaffold, agents-cli run "prompt" for a single-prompt execution, agents-cli install for project dependencies, and agents-cli lint which the README says runs Ruff. On the eval side there is eval run, eval generate, eval grade, eval dataset synthesize for multi-turn scenarios against your local agent, eval compare for two result files, eval analyze, eval metric list and eval optimize. Deployment is agents-cli deploy, with agents-cli infra single-project for single-project provisioning and agents-cli infra cicd for a pipeline plus staging and production infrastructure. agents-cli info prints project config and CLI version, and agents-cli update force-reinstalls skills to all IDEs. That last command is the one to remember when a coding agent behaves as if it has stale instructions.

Where the design shows its edges: cloud coupling and a moving skill surface

The first limitation is stated by the project itself. Deployment and cloud features require Google Cloud. If your production target is AWS, Azure or a self-managed Kubernetes cluster outside GKE, the deploy and publish skills are not relevant to you, and what remains is scaffolding and evaluation. That is still useful, but it is a smaller product than the README's framing suggests.

The second is the skill surface. Skills are files installed into a coding agent, which means their behaviour depends on a third party you do not control. The release cadence visible in the repository is fast: v1.10.0 on 2026-10-12, v1.11.0 on 2026-10-20, v1.12.0 on 2026-10-27. Three releases in roughly two weeks. The existence of agents-cli update and agents-cli scaffold upgrade suggests the maintainers expect drift between installed skills and the current version. A team that pins skills and forgets them will get advice that no longer matches the CLI.

The third is the eval pipeline itself. Treat the eval commands as a harness whose thresholds you will have to calibrate yourself.

The honest alternative: ADK directly, or a general agent framework

The repository's own FAQ addresses this. ADK is an agent framework; agents-cli gives your coding agent the skills and tools to build, evaluate and deploy ADK agents end to end. The practical difference is who holds the knowledge. With ADK alone, you read the framework documentation and write the orchestration, tool definitions and callbacks yourself, then wire up your own evaluation harness and deployment scripts. With agents-cli, those conventions are encoded in skill files that your coding agent reads, and the CLI supplies the eval and deploy commands. You are trading direct control of the project layout for a scaffold that the tool can upgrade with agents-cli scaffold upgrade.

There is a second alternative worth naming: skipping the coding agent entirely. The README confirms the CLI works standalone: you can run agents-cli scaffold, eval, deploy and every other command directly from your terminal. So the skills are optional. If you prefer to drive the CLI yourself and read the ADK documentation, you can use create, eval and deploy without installing anything into Claude Code or Codex. What you lose is the ADK API knowledge the google-agents-cli-adk-code skill carries, which is the part that saves the most reading.

Maintenance, upgrade cost and the Apache-2.0 licence

The licence is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notices intact and comply with its patent and attribution terms. That is the standard permissive position and it is not a constraint for most teams. I am not a lawyer and this is not legal advice; if you are redistributing a modified version inside a product, have counsel read the actual text rather than this paragraph.

The maintenance cost is not in the licence. It is in keeping three things aligned: the installed CLI version, the skill files inside your coding agent, and the scaffolded project. The tool provides commands for each. agents-cli update reinstalls skills to all IDEs. agents-cli scaffold upgrade moves a project to a newer agents-cli version. agents-cli info reports the project config and CLI version, which is the command to run first when something behaves unexpectedly. Given the release cadence seen in the recent releases, plan on running that check more often than you would for a library that ships quarterly. The repository also maintains a RELEASE_NOTES.md, which is the file to read before an upgrade rather than after.

What to verify before you commit a team to it

Verify the deploy path against your actual target. The deploy skill names Agent Runtime, Cloud Run and GKE. If your destination is one of those, the skill covers it. If it is not, the infra cicd command builds staging and production infrastructure for a pipeline the project assumes, and you should read that command's behaviour before assuming it fits your existing pipeline. Verify the eval dataset story too: eval dataset synthesize produces multi-turn scenarios for a local agent, which means the quality of your evaluation depends on synthesized scenarios unless you supply your own cases. Check eval metric list early, because the metrics available determine what eval grade can tell you and therefore what eval optimize can tune against.

Finally, verify that the coding agent you use is one the skills were written for. The README names Antigravity CLI, Claude Code and Codex, and adds that it works with any other coding agent. That last clause is a claim about file format compatibility, not a guarantee that every agent will follow the workflow skill's code preservation rules correctly. Test it on a throwaway project before you point it at a repository you care about.

Editorial conclusion

Adopt agents-cli if you are already building ADK agents and deploying them to Google Cloud, because the eval subcommands and the skill files are the parts you would otherwise assemble by hand. Do not adopt it if your target runtime is not Google Cloud, or if you want a coding agent rather than a tool for one. Before committing, run agents-cli info to see the project config and CLI version, check the release cadence in RELEASE_NOTES.md against your own upgrade tolerance, and confirm whether the deploy path you need is covered by the deploy skill or requires the infra cicd command to build staging and production infrastructure first.

Frequently asked questions

Official sources

1. google/agents-cli on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases