The retrieving-developer-knowledge skill documented batch document fetch as
POST /v1/documents:batchGet with a JSON body. No such method exists, and the
call returns a 404, so the operation never worked as documented.
The v1 discovery document defines documents.batchGet as a GET with repeated
`names` query parameters and no request body. This corrects the endpoint in
SKILL.md and references/api-fallback.md, documents the optional `view`
parameter, the 20-document ceiling and the response shape, and states plainly
that the endpoint takes no request body.
Also adds the credential guidance the skill was missing. Neither file told a
reader how to obtain a credential when none is present; both now link the
public Developer Knowledge quickstart, which covers enabling the API and
creating a key.
PiperOrigin-RevId: 980133878
Bumps the google-cloud-developer plugin from 1.1.1 to 1.1.2 across plugin.json,
.claude-plugin/plugin.json, .codex-plugin/plugin.json, and
gemini-extension.json.
The release carries one functional fix: mcp_config.json now sets
"authProviderType": "google_credentials" on the Developer Knowledge MCP server.
Without it, clients reading that descriptor sent unauthenticated requests and
received 401 Unauthorized. The field is documented as mandatory in
skills/cloud/gcloud/references/mcp-usage.md, and the sibling
gemini-extension.json already carried it.
PiperOrigin-RevId: 980018211
The google-cloud-developer plugin declares the Developer Knowledge MCP server
in mcp_config.json with only a serverUrl. The repository's own documentation,
in skills/cloud/gcloud/references/mcp-usage.md, states that
"authProviderType": "google_credentials" is mandatory, and that omitting it
causes the client to send unauthenticated requests and receive 401
Unauthorized errors.
The sibling gemini-extension.json already carries the field. This adds it to
mcp_config.json so clients reading that descriptor attach Application Default
Credentials rather than calling the server anonymously.
PiperOrigin-RevId: 979969884
- Introduces the dpop-adoption skill for implementing Demonstrating Proof-of-Possession (RFC 9449) across WebCrypto, Node.js ES6, and browser runtimes.
- Enforces hardware-backed non-extractable key pairs (P-256), IEEE P1363 signature formatting, and single-retry nonce challenge rotation loops.
- Adds EVAL.txtpb test suite and registers skill under the new Identity category in the central catalog.
PiperOrigin-RevId: 976380835
Adds a public agent skill under third_party/skills/skills/cloud/gke-node-notready
for diagnosing GKE nodes that report NotReady or Unknown status.
The skill is a read-only diagnostic workflow that maps kubelet/containerd/event
signatures to root causes (container runtime down, system OOM, disk throttling,
PLEG unhealthy, kubelet<->control-plane connectivity, CNI failure, admission
webhook interference, and kube-node-lease flapping) and proposes remediations as
kubectl/gcloud commands or GitOps manifest changes without mutating the cluster.
All commands use public kubectl/gcloud and Cloud Logging/Monitoring, and the
workflow is derived from the public GKE "Troubleshoot nodes with the NotReady
status" documentation (linked in the skill's References section).
Contents:
- SKILL.md: diagnostic workflow + root-cause decision table.
- EVAL.txtpb: 13 evaluation cases, each with 4 MUST/MUST NOT expectations.
- OWNERS.
PiperOrigin-RevId: 975725704
- Improve agent-platform-prompt-management and endpoint_mgmt skill with explicit Python execution instructions, post-deletion verification, and prompt attribute documentation.
- Route Model Garden deploy requests through the A2UI deploy panel and confirmation card instead of a text preview, and document the two-step (collect -> confirm) deploy flow in the agent-platform-a2ui skill.
PiperOrigin-RevId: 975179372
On some clients the Developer Knowledge MCP server does not connect at all, and
the skill did not describe the situation its users are actually in.
The connection failure is structural rather than a misconfiguration. The
Claude-facing manifest declares the server with no auth method, so the client
follows the MCP authorization spec, discovers the protected-resource metadata,
and is pointed at Google as the authorization server. Completing that handshake
without a pre-registered client requires dynamic client registration, and
Google's discovery documents advertise no registration endpoint. The client
cannot mint an identity, the handshake ends, and no answer_query,
search_documents or get_documents tool is ever exposed. The skill previously
said a declared tool might return an error. The tools are not there to return
one.
The REST fallback is therefore the only transport on those clients, and the
skill documented it as needing an API key. It does not. The v1 REST API accepts
an ordinary Google bearer token, so anyone with an authenticated gcloud has a
working path already and needs nothing installed or configured. That form is now
shown first, with the API key kept as the alternative, and the REST fallback
reference is reordered to match so the two do not disagree. Where a bearer token is
refused, the note explains that the application-default credential often
succeeds where the account credential does not, because which one the API
accepts depends on how the environment was authenticated.
A verification step also now sits between retrieval and output. The skill told
an agent to answer immediately upon receiving the documentation response,
without checking that what came back was documentation. PERMISSION_DENIED,
UNAUTHENTICATED, HTTP 401 or 403, an empty result set, or any error payload is a
failed lookup even when the tool reported no error. On a failure the agent tries
the other transport once, and if that also fails it says it could not reach
Developer Knowledge and is answering without it.
PiperOrigin-RevId: 974811356
The Codex manifest for google-cloud-developer showed the plugin to users as
"Google Cloud Core", which is a different plugin. The value was left over from
when this package was derived from that one. Its name field was correct, so
anything checking only the name saw nothing wrong, while the string a Codex user
actually reads named the wrong product.
Auditing the rest of the package turned up two more. The plugin carried two
different descriptions across its four manifests, because three were copies made
before it gained a skill. And every one of those descriptions opened with "Core
Google Cloud guidance", which is again the other plugin's framing. All four now
carry the same text and none of them begins with Core. The string core no longer
appears anywhere in the package.
An audit of the remaining seven plugins found no other manifest text naming a
different plugin, and no other description disagreeing across manifests.
Two conformance cases now hold this ground. The first rejects a manifest string
that contains, as a whole word, a token distinguishing another plugin's name from
its own, which catches both the display name and the prose. URLs are exempt,
because hostnames such as agent-plugins.org legitimately contain such tokens, and
without that exemption the case fires on every plugin. The second requires a
plugin's manifests to agree on their description. Both run for every plugin.
PiperOrigin-RevId: 974750814
- Allow for user to specify domain name or to test in dev mode without a domain name using a self-signed cert.
- Ommitting record_client_address because it is not supported for Cloud SQL instances with Private Service Connect connectivity enabled.
PiperOrigin-RevId: 974582104
Two lists in this repository had drifted from what they describe, for the same
reason. Both are maintained by hand and nothing makes you update them when the
thing they describe changes.
The google-cloud-developer rules file opened with "This plugin installs three
skills" and named three. The plugin ships five. The count was correct when it
was written and went stale the moment the plugin gained a skill, which is a
defect that will recur every time it gains another. Rather than correct the
number, the paragraph no longer states one. It tells the agent to check what is
actually available instead of trusting the file. A count that is not written
down cannot go out of date.
The same file closed by telling the agent to browse GitHub and install through
npx to find more skills. The plugin now bundles finding-google-skills, which
fetches the current index and returns exact entry points, so that advice routed
agents around the better tool. It now prefers the bundled skill and keeps the
browse URL as a fallback.
The two marketplace manifests describe one marketplace and had drifted apart.
The Claude manifest listed seventeen plugins and the agents manifest sixteen,
with db-context-engineering present in the first and missing from the second.
Whoever added it updated one file and missed the other.
Three conformance cases now hold this ground:
A rules file that names two or more bundled skills is treated as enumerating
them and must name all of them. One mention is a reference, not a list, so a
file may point at a single skill by name without triggering the check.
A rules file that states how many skills a plugin installs must state the right
number, whether written as a digit or a word.
The two marketplace manifests must list the same set of plugins.
The first two cases skip when a rules file makes no such claim, so the fix above
costs nothing to keep and the checks only bite if someone writes a hardcoded
list back in.
PiperOrigin-RevId: 972849207
Testing the published skill against the live catalog turned up three problems
that reading the file did not, and checking the plugin that carries it turned up
a fourth.
A certificate failure is now terminal. The skill already classified a TLS error
as a failed retrieval but never forbade working around one, and a test agent
responded to a certificate error by reissuing the request with verification
disabled. It disclosed that afterwards, so it was honest about it, but the next
thing the skill does is follow instructions from whatever came back, which makes
certificate validation the only thing standing between an intercepted catalog
and execution. The rule now names the specific escapes. Not curl -k or --insecure. Not
-SkipCertificateCheck, and on Windows PowerShell 5.1, where that parameter does
not exist, not the ServicePointManager certificate callback.
The repository-tree fallback command is quoted. It was printed unquoted, so the
bare question mark in the query string is a glob. In zsh it aborts before curl
runs and reports "no matches found", which resembles nothing like a network
problem. That command exists to rescue a failed fetch, so it needed to be the
one line that always runs.
The catalog is about 75 KB and does not fit in a single tool result on at least
one runtime, which truncated it to a preview and spilled the rest to a file. A
truncated preview is alphabetical, so it reads as though only the first few
products exist. Step 1 now shows how to narrow the catalog before reading it,
with jq, with Windows PowerShell, and with grep where neither is available, and
offers writing it to a file and reading it in parts as the option that works
everywhere. The rule that forbade copying the catalog into a file said more than
it meant; it now permits a working copy while filtering and still forbids
keeping one or summarizing it back into the conversation.
The skill's front matter is unchanged, so the generated catalog index does not
move.
Separately, the google-cloud-developer plugin manifest pointed its homepage at
the google-cloud-core directory, left over from when the package was derived
from it. It now points at its own. This is the only plugin manifest in the
repository that sets a homepage at all, which is why nothing else needs the same
correction.
PiperOrigin-RevId: 972728486
The google-cloud-developer plugin now ships five bundled skills. Two are new:
finding-google-skills, which lets a coding agent discover which Google-published
skills exist and pick the right one for the task in front of it rather than
guessing from whichever plugin happens to be loaded, and
retrieving-developer-knowledge, which searches official Google developer
documentation through the Developer Knowledge MCP server the plugin already
declares. They join gcloud, google-cloud-recipe-auth, and
google-cloud-recipe-onboarding.
Both new skills live outside skills/cloud/, which the bundling machinery could
not express. Every entry in PLUGIN_SKILLS now carries its category directory,
and both readers of that list resolve skills/<category>/<name>: the copy
transformation in copy.bara.sky and plugin_conformance_test.py. The three
existing entries are rewritten to the qualified form. The exported package still
holds each skill at <plugin-root>/skills/<directory name>, so the category
prefix decides only where the canonical copy is read from and the exported
layout does not change.
Bundling additional components is backwards compatible, so the plugin version
moves from 1.0.0 to 1.1.0 in all four manifests: plugin.json,
gemini-extension.json, .claude-plugin/plugin.json, and
.codex-plugin/plugin.json.
PiperOrigin-RevId: 972698973
An agent that needs one of the skills in this repository has no way to find
out which one applies without reading every SKILL.md. This adds a small
router skill that resolves the lookup at runtime instead.
skills/developers/finding-google-skills/SKILL.md is the router. It fetches
the catalog, matches a request against the entry descriptions, and then
retrieves only the skills that matched. It carries no copy of the catalog,
so having it loaded costs little more than its frontmatter.
The skill is named for the capability it provides rather than for a product
surface, so a reader who does not already know the catalog can still tell
what it is for.
Retrieval has to be byte-exact, because the agent uses each entry point URL
verbatim and a paraphrased catalog yields invented links. The skill asks for
a raw shell fetch first and names the alternatives that also return bytes,
including Node where no shell fetch tool exists. On Windows it calls for
curl.exe rather than curl, since bare curl resolves to an Invoke-WebRequest
alias in Windows PowerShell that returns a formatted object.
Where only a summarizing fetch tool is available, the skill phrases the
request as extraction rather than transcription. Requesting the document
verbatim returns nothing usable; requesting a list of the entry point fields
returns all of them.
A failed retrieval has to be reported rather than papered over. The skill
retries, then falls back to listing the repository tree, and if it still has
no catalog it says so instead of answering from memory.
The catalog may be fetched once and reused within a session, since skills
land infrequently enough that a second fetch between two lookups buys
nothing. It is not carried beyond the session. If a lookup finds no match,
the skill refetches once before concluding that none exists.
index.json is the catalog: a "skills" array holding one entry per published
skill, with the skill name, its description, and the raw URL of its
SKILL.md. A "generator" note sits above the array, so the first thing anyone
opening the file reads is that it is generated rather than maintained by
hand. Entries are sorted by name and the formatting is fixed, so
regenerating an unchanged tree reproduces the file byte for byte. It
currently lists 126 skills.
The note carries no timestamp and no content hash. Either one would make an
unchanged tree regenerate to a different file, which would cost the
staleness check its determinism.
Fetching the catalog on demand rather than carrying it in context means a
session that never needs a lookup pays nothing for it.
PiperOrigin-RevId: 972667621
Follows the change that renamed google-cloud-core to
google-cloud-developer and removed five plugin packages. This removes the
sixth, leaving google-cloud-developer as the only cloud plugin.
No skill content is removed. The three skills gemini-api bundled stay in
skills/cloud and remain individually installable, as do the 54 skills
unbundled by the previous change. This removes a package, not skills.
The plugin directory is deleted and both marketplace manifests drop its
entry: .claude-plugin/marketplace.json goes from 18 entries to 17, and
.agents/plugins/marketplace.json from 17 to 16.
PiperOrigin-RevId: 972198583
This skill integrates with the Developer Knowledge MCP server and REST API fallback to provide natural language guidance, tool routing protocols, parameter precedence rules, and documentation grounding for developer queries across Google Cloud, Android, Flutter, Go, and Firebase.
PiperOrigin-RevId: 972158490
Renames google-cloud-core to google-cloud-developer, and removes five
plugin packages: google-cloud-well-architected, google-cloud-run,
google-cloud-gke, google-cloud-gke-workloads, and
gemini-enterprise-agent-platform.
Seven cloud plugins become two: google-cloud-developer and gemini-api.
No skill content is removed. The plugins are packaging over skills that
live in skills/cloud, and every one of those skills stays in the catalog
and remains individually installable. This change removes 5 bundles, not
57 skills. Specifically retained: 6 Well-Architected skills, 31 GKE
skills, 1 Cloud Run skill, 15 Agent Platform skills, and the 4 skills the
renamed developer plugin continues to bundle.
Changed alongside the packages:
* copy.bara.sky, both in PLUGIN_SKILLS and in the exported package list
* .claude-plugin/marketplace.json, 23 entries to 18
* .agents/plugins/marketplace.json, 22 entries to 17
The marketplace entry for the renamed plugin also has its source path
repointed to ./plugins/cloud/google-cloud-developer. A renamed directory
behind a stale source path would leave the marketplace advertising a
plugin that cannot install.
PiperOrigin-RevId: 971948257
The plugins have shipped in this repository since last week, but neither
marketplace lists them. A user who follows the README and runs
`claude plugin marketplace add google/skills` sees only the sixteen
externally hosted entries and none of the plugins that live here.
This adds all seven to both marketplace files:
google-cloud-core
google-cloud-well-architected
google-cloud-gke
google-cloud-gke-workloads
gemini-enterprise-agent-platform
gemini-api
google-cloud-run
Every existing entry points at a separate repository, so none of them
model an in-repo plugin. These use a repository-relative source path,
following the pattern the Data Agent Kit marketplace already uses for a
plugin stored alongside its own marketplace file.
Descriptions are copied verbatim from each plugin.json so the marketplace
and the plugin cannot drift. The .agents entries also carry the
installation policy and a category, matching the convention already in
that file.
The change is additive. No existing entry is modified, reordered, or
removed, and both file headers are unchanged.
PiperOrigin-RevId: 971239082
Cloud IX Team