Somewhere in the last seven days, a repository called google/skills quietly became one of the fastest-growing projects on GitHub — 18,000+ stars total, over 2,300 of them added in a single week, landing at #3 on GitHub's weekly trending page as of this writing, ahead of most of the AI-agent hype-of-the-week repos sitting next to it. It's not a new model, not a new IDE, and not another agent framework. It's a folder of markdown files.
That undersells it slightly. What Google actually shipped is a library of first-party "Agent Skills" for Google Cloud — instructions that teach a coding agent how to correctly use gcloud, write Terraform for GKE, query BigQuery, or reason about the Well-Architected Framework — packaged in the exact format Anthropic popularized for Claude Code. And here's the part that makes it worth a second look: when you read the install instructions, the repo explicitly wires itself into Claude Code and OpenAI's Codex. Gemini CLI, Google's own open-source coding agent, isn't mentioned anywhere on the page.
A cloud vendor built distribution for a competitor's product before shipping it for its most obvious internal target. That's the actual story here, and it's worth unpacking properly — what the repo contains, how the mechanism works, what it replaces, and where the marketing narrative (there isn't much of one yet, which is itself telling) glosses over the rough edges.
What's actually in the repository
google/skills is an Apache 2.0-licensed monorepo organized into three top-level categories:
-
Cloud — by far the largest bucket, with 70+ skills spanning Vertex AI (Model Garden, Agent Platform, Gemini API, Live API), infrastructure (GKE, Compute Engine), databases (BigQuery, AlloyDB, Cloud SQL, Spanner, Bigtable), developer tooling (
gcloud, Google's own Agents CLI), operations (Cloud Monitoring, Cloud Logging, Workload Manager), and security/identity guidance mapped to the Well-Architected Framework. - Ads — roughly a dozen skills covering the Google Ads API, Mobile Ads SDK variants, and the Data Manager API.
- Analytics — a couple of skills for the Google Analytics Admin and Data APIs.
That's somewhere north of 80 individual skills at the time of writing, and the count will keep moving — the repo is explicitly labeled "under active development," with 240+ commits already. The README also points to sibling repositories for Android, Flutter, and Firestore, suggesting this is one arm of a broader push rather than a one-off drop.
How the mechanism actually works
If you haven't used Claude Skills before, the format is worth understanding because it's the whole reason this repo is interesting instead of just being another docs dump. A skill is a SKILL.md file with YAML frontmatter — a name and a description — followed by a body of instructions, optionally alongside bundled scripts or reference files. The agent doesn't load the full body into context up front. It scans the lightweight frontmatter of every installed skill, and only pulls in the full instructions when the current task actually matches one. Anthropic's own docs describe this as loading a skill's body "only when it's used," so a library of 80 skills costs you almost nothing in context until you touch BigQuery or GKE, at which point the relevant one gets pulled in on demand.
That's a meaningfully different cost model than Model Context Protocol (MCP) servers, which register their full tool schemas into context the moment they're connected, whether you use them in a given session or not. Skills are cheaper to keep installed in bulk and cheaper to ignore.
Installation is handled two ways. There's a harness-agnostic path via npx skills add google/skills, which routes through skills.sh, a lightweight package-manager-style installer for the emerging skills ecosystem — you get an interactive picker to select which skills you actually want. And there's a harness-specific path, spelled out explicitly for three tools:
-
Claude Code:
claude plugin marketplace add google/skills, thenclaude plugin install <plugin>@google-plugins -
Codex:
codex plugin marketplace add google/skills, then install via the plugin browser -
Antigravity CLI:
agy plugin install https://github.com/google/skills/<plugin-path>— Google's own agentic IDE, Antigravity, gets a supported path too
Three harnesses, and only one of them is Google's. Gemini CLI, which has existed as Google's flagship open-source terminal agent for the better part of a year, isn't in that list. It's possible that's simply a sequencing decision — Gemini CLI support could land in a future PR — but as shipped today, a developer sitting in Claude Code or Codex gets a smoother, first-party onboarding to Google Cloud than a developer sitting in Google's own CLI.
What a skill actually looks like
To make this concrete: the general SKILL.md pattern (illustrative, not copied from any specific file in the repo) is a short frontmatter block plus a body, roughly like this:
---
name: cloud-run-deploy
description: "Use when deploying a service to Google Cloud Run, including IAM bindings and revision configuration"
---
# Deploying to Cloud Run
1. Confirm the target project with `gcloud config get-value project`
2. Build and push the container: `gcloud builds submit --tag ...`
3. Deploy with the correct minimum flags for a stateless HTTP service: ...
4. Grant invoker IAM only to the intended principals, never `allUsers` unless the service is explicitly public
...
The agent only ever reads the name and description up front, across every skill you have installed. The moment your prompt looks like "deploy this to Cloud Run," it matches on the description, pulls in the full body, and proceeds with Google's actual current guidance instead of whatever gcloud syntax the underlying model happened to memorize at training time. Multiply that across 80-odd skills and you get a coding agent that behaves like it has a recent, correct internal GCP runbook — because, functionally, it does.
What changed versus how this used to work
Before this, if you wanted an AI coding agent to correctly scaffold a Cloud Run service or write valid AlloyDB Terraform, you had three realistic options, all worse than what's on offer now. You could rely on whatever the underlying model happened to memorize during training, which goes stale the moment Google ships a new API version or renames a flag. You could paste a slab of gcloud reference docs into your prompt or CLAUDE.md every session, paying the context cost every single time regardless of whether that session ever touches Cloud Run. Or you could stand up an MCP server — a persistent process wrapping GCP's APIs as callable tools, which is more powerful for actions that need live state (checking whether a bucket already exists, reading real quota numbers) but is meaningfully more infrastructure to write, host, and keep patched.
Skills don't replace MCP servers for that live-state use case — a SKILL.md file is static text, not a running program, so it can't tell you your current billing balance or list your actual GKE clusters. What it replaces is the "how do I even format this correctly" layer: the procedural knowledge an agent needs to not hallucinate a gcloud flag that stopped existing two releases ago. It's closer to a well-maintained internal wiki page than a live integration, and that's a legitimate, underserved gap — most teams' internal cloud runbooks are exactly this kind of static procedural knowledge, and most of them are stale within a quarter.
Why this matters beyond one repo
Cost and token efficiency. Because skill bodies only load on demand, you can install the entire library without paying a standing context tax, unlike bulk-loading MCP tool schemas. For anyone tracking agent token spend, that's a real, measurable difference, not a marketing abstraction.
Lock-in, or the lack of it. These are plain markdown files under Apache 2.0. There's no SDK to vendor, no proprietary client library, nothing to migrate off later. If Google stops maintaining a skill, you fork the file and keep going. That's a sharply lower lock-in profile than adopting a vendor's proprietary agent framework or a closed MCP binary — arguably the most underrated property of the whole skills pattern.
Security surface. This cuts both ways. Human-readable markdown is easier to audit than an opaque compiled MCP server binary — you can actually read what you're installing before you trust it. But it's still natural-language instructions that an agent will follow with real credentials and real GCP permissions attached. A malicious or subtly wrong skill is a prompt-injection vector with production blast radius, and nothing in the repo's current structure (no visible signing, no version pinning in what's exposed at install time) gives you a way to verify a skill hasn't changed since you last reviewed it. Treat this the way you'd treat any third-party dependency with write access to your cloud account: pin it, diff it before upgrading, don't blanket-enable the whole Cloud category on day one.
Maintainability. A Google-maintained skill for, say, Spanner schema migrations is far more likely to track breaking API changes than a skill scraped from a two-year-old blog post baked into a model's training data. Whether Google actually keeps this repo current six months from now is an open question — plenty of vendor-maintained GitHub repos start strong and stall — but the intent, at least, points the right direction.
Practical use cases
The categories map fairly directly onto real workflows: scaffolding a new Cloud Run service with correct IAM bindings instead of a hallucinated service account structure, generating Terraform for a GKE cluster that actually matches current provider syntax, writing BigQuery SQL against the real current dialect instead of a syntax that got deprecated, running a security pass against a project using the Well-Architected Framework skill as a checklist, or standing up Firebase hosting from inside Claude Code without tab-switching to documentation. None of these are capabilities the agent didn't have before — they're accuracy and reliability improvements on capabilities it already attempted, badly, from memorized training data.
Picture the workflow concretely: a developer working in Claude Code on a Spanner-backed service asks the agent to add a new index without downtime. Without a skill, the agent reasons from general SQL knowledge and general Spanner familiarity baked into its weights, which is close enough to be dangerous — Spanner's DDL and interleaving rules are specific enough that "close enough" produces migrations that compile but lock tables or violate interleave constraints in ways that only surface in production. With the relevant skill installed, the agent's description match pulls in Google's actual current guidance on online schema changes before it writes a single line, and the difference shows up as fewer failed apply attempts and fewer 2 a.m. incident channels, not as a flashier demo.
The same logic applies to the Ads and Analytics categories, just for a different audience: a growth engineer wiring up conversion tracking through the Google Ads API gets an agent that knows the current OAuth flow and current API version instead of one confidently citing a deprecated endpoint from two major versions ago.
Where this sits next to what other clouds are doing
This isn't happening in a vacuum. Over the past year, the major cloud vendors have converged on shipping official MCP servers as their primary answer to "how do developers use AI agents against our platform" — AWS has done this for a range of its services, and the pattern has become close to table stakes for any infrastructure vendor that wants agent-native developers to reach for its product instead of a competitor's. google/skills is a genuinely different bet on top of that trend rather than a replacement for it: instead of (or in addition to) building the live, stateful integration layer, Google is investing in the static, procedural-knowledge layer, and doing it in a format explicitly compatible with rival vendors' agents rather than gated behind its own. That combination — MCP for state, skills for procedure, shipped for competitors' tools as readily as your own — is likely to look like the obvious playbook in hindsight if it works, which is exactly the kind of move that's easy to miss while it's still just a trending GitHub repo.
What the marketing (such as it is) leaves out
There isn't much marketing yet — this shipped as a GitHub repo, not a keynote slide — which is itself worth noting as a limitation: there's no official blog post explaining the strategy, versioning policy, or long-term support commitment as of this writing. Beyond that:
- Coverage is lopsided. Cloud dominates with 70+ skills; Ads and Analytics are thin afterthoughts by comparison. If your work lives in Analytics Admin API territory, this library barely helps you yet.
- No visible versioning or pinning at the install layer. A skill you installed last week could read differently today with no changelog forcing your attention to it.
-
It still requires your own tooling and auth. A skill teaches the agent how to call
gcloudcorrectly; it doesn't installgcloud, authenticate it, or grant it permissions. All the usual credential and IAM hygiene is still entirely on you. - The Gemini CLI gap is either a bug or a signal, and either reading is a little uncomfortable for Google. If it's a bug, it says the launch was rushed. If it's a signal — that competitor coding agents currently have larger active user bases worth chasing first — that's a genuinely interesting admission about where developers are actually spending their time in mid-2026.
- "Under active development" is doing a lot of work. Early adopters are the QA layer here, same as any pre-1.0 open-source project.
How this stacks up against the alternatives
Against a hand-rolled MCP server, skills are lighter-weight, cheaper in context, and far easier to audit line-by-line, but strictly less capable for anything requiring live state or side effects — you'd realistically want both, not one instead of the other. Against Anthropic's own community and first-party skill libraries, google/skills is narrower in scope (Google Cloud only) but has the advantage of being maintained by the actual API owner rather than a third party trying to keep pace with someone else's release notes. Against the old pattern of just trusting whatever an LLM memorized about gcloud syntax during pretraining, this is a straightforward, meaningful upgrade in correctness — that comparison isn't close. And against static internal documentation or Confluence runbooks, the difference is that skills are designed to be loaded automatically and selectively by the agent rather than requiring a human to remember they exist and go copy-paste from them.
An independent read
What's genuinely notable isn't the repo's technical content — none of these 80-odd skills are individually surprising; they're competent, unglamorous procedural docs. What's notable is what Google's harness list says about how the company is thinking about distribution in 2026. Rather than betting that developers will consolidate around Gemini CLI or Antigravity, Google is meeting people in the tools they're already using — including a direct competitor's flagship coding product — and optimizing for "developers write correct GCP code," full stop, regardless of which agent they typed it into. That's a more mature and more confident strategy than it might first look like, and it's also a quiet, useful data point that the SKILL.md format itself is drifting from "a Claude Code feature" toward "a de facto interoperable standard," the way MCP did before it. Whether Google backfills Gemini CLI support, and how fast the Ads and Analytics categories catch up to Cloud, will say a lot about whether this is a strategic long-term commitment or a fast-follow experiment that fizzles once the trending-repo attention fades.
Who should actually use this
If you're building against Google Cloud from inside Claude Code or Codex, installing this today carries close to zero downside — it's free, Apache 2.0, and skills you don't invoke cost you nothing. Review individual skill files before trusting them with real infrastructure changes, the same way you'd review any dependency with credential access, rather than blanket-installing the whole Cloud category unread. If your primary agent is Gemini CLI, there's currently nothing here for you, which is the strangest part of this whole launch — watch the repo rather than the marketing for when, or if, that changes. And if your team already has a mature internal skills or prompt-library setup for GCP, this is worth diffing against what you have rather than replacing it outright — Google's version will likely be better-maintained long-term, but your internal one may already encode organization-specific conventions this generic library never will.
For platform and DevOps teams specifically, there's a secondary decision buried in here beyond "install or don't": whether to let individual engineers npx skills add this on their own laptops, or to pull it through the same review-and-pin process you'd apply to any other dependency with production credential access, then distribute an approved subset internally. Given the lack of visible signing or version pinning at install time, treating this as ad hoc, engineer-initiated tooling is the riskier of the two options for any team with real compliance obligations — the low friction that makes this appealing for a solo developer is the same property that makes it worth a second look before an org rolls it out fleet-wide. Solo developers and small teams experimenting on personal projects have the least to lose here and are probably the right first adopters; regulated enterprises with change-control requirements around anything touching IAM should wait for the repo to mature past "under active development" and for Google to publish an actual versioning or release policy before making it a standard part of the toolchain.
What's your read on cloud vendors shipping first-party integrations for competitors' agent tools before their own — smart distribution, or a sign that internal agent products aren't gaining the traction their teams hoped for?
Sources:
Top comments (0)