Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add Goodsmileduck/claude-registry --skill gcp-iamgit clone --depth 1 https://github.com/Goodsmileduck/claude-registryWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/goodsmileduck/claude-registry/gcp-iam)<a href="https://agentmods.dev/skills/goodsmileduck/claude-registry/gcp-iam"><img src="https://agentmods.dev/badge/skills/goodsmileduck/claude-registry/gcp-iam/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/goodsmileduck/claude-registry/gcp-iam"><img src="https://agentmods.dev/badge/skills/goodsmileduck/claude-registry/gcp-iam.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00069 | $0.01998 |
| Opus 5 | $0.00034 | $0.00999 |
| Sonnet 5 | $0.00014 | $0.00400 |
| Haiku 4.5 | $0.00007 | $0.00200 |
Grade A, and why
gcp-iam scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 155 lines — stays where its author put it; the contents beside it link to each section on GitHub.
For the GitHub Actions caller side of Workload Identity Federation (
permissions: id-token: write,google-github-actions/authsetup, the OIDC token shape), see thegithub-actions-pipelinesskill. This skill covers the GCP side: pool provider attribute conditions, service accountiam.workloadIdentityUserbindings, impersonation chains.
GCP IAM Inheritance
When to invoke
Symptoms:
permission denied: <permission> on resource <X>despite the user being "in the right group at the org level."iam.serviceAccounts.getAccessTokendenied during Workload Identity, ESO sync, or CI/CD.- A service account can
geta resource but notlistsiblings (or vice versa). gcloud projects get-iam-policy <project>shows no binding for the user, but the user can log into the project console.- Cross-project SA impersonation works for human users via
gcloud auth loginbut fails from a workload.
The trap this prevents: assuming GCP IAM is additive across the hierarchy in all directions. It is — but with caveats around conditional bindings, deny policies, audit-log filtering, and the fact that some permissions only apply at specific resource levels.
The inheritance model (the part that does work)
Organization
└── Folder(s)
└── Project(s)
└── Resource(s) (Bucket, BQ Dataset, GCE Instance, etc.)
Rule: A role granted at level N applies to N and everything below it. Permissions are added — never subtracted (except by Deny policies, see below).
So roles/storage.admin granted at the folder level grants storage.admin on every project under that folder. This is the "obvious" inheritance and it does work as expected.
Why "group at org" sometimes fails to grant project access
Common reasons users report "I'm in the group but it doesn't work":
- The group has no IAM binding at any level. Group membership alone grants nothing. The group must appear as a
principalin an IAM binding somewhere in the hierarchy.# Find every binding that includes a group, project or higher gcloud projects get-iam-policy <project> \ --flatten="bindings[].members" \ --filter="bindings.members:group:<group-email>" \ --format="value(bindings.role)" gcloud organizations get-iam-policy <org-id> \ --flatten="bindings[].members" \ --filter="bindings.members:group:<group-email>" \ --format="value(bindings.role)"
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 155 lines · 69 tokens per session scan A b3c61bec0c79
gcp-iam is a skill published in the GitHub repository Goodsmileduck/claude-registry (1 stars, last pushed 1mo ago), licensed MIT. It adds 69 tokens to every session and 1,998 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
deployment-inspection
End-to-end investigation of a live client deployment — platform detection, subdomain discovery, deployment API access (Netlify), JS bundle analysis, repo discovery.
devops-best-practices
Opinionated production-grade DevOps defaults for Terraform, Kubernetes, CI/CD, Docker, cloud security, observability, cost, and disaster recovery. ALWAYS use when generating, reviewing, or modifying any infrastructure code, Kubernetes manifests (Deployment, Service, StatefulSet, Helm, Kustomize), Terraform (.tf…
gcp-logs
Query GCP Cloud Logging for errors, service logs, and request traces. Use when investigating GCP-hosted services.
production-audit
Local-evidence production readiness audit for shipped apps, pre-launch reviews, post-merge checks, and "what breaks in prod?" questions without sending repo data to an external audit service.
paperclip-dev
Develop and operate a local Paperclip instance — start and stop servers, pull updates from master, run builds and tests, manage worktrees, back up databases, and diagnose problems. Use whenever you need to work on the Paperclip codebase itself or keep a running instance healthy.
systematic-debugging
4-phase root cause debugging: understand bugs before fixing.