gcp-cloud-run
GCP Cloud Run deployment skill. Use for Cloud Run Functions (event-driven Pub/Sub, Storage, HTTP webhooks), cold start optimization, and Cloud Run anti-pattern prevention. For Cloud Run service deployment use deployment-engineer agent. Triggers: cloud run, cloud function, pub/sub trigger, cold start, serverless, event-driven GCP, cloud storage trigger.
Works with
---
name: gcp-cloud-run
description: GCP Cloud Run deployment skill. Use for Cloud Run Functions (event-driven Pub/Sub, Storage, HTTP webhooks), cold start optimization, and Cloud Run anti-pattern prevention. For Cloud Run service deployment use deployment-engineer agent. Triggers: cloud run, cloud function, pub/sub trigger, cold start, serverless, event-driven GCP, cloud storage trigger.
license: MIT
---
# GCP Cloud Run
## Iron Law
```
NO CLOUD RUN FUNCTION WITHOUT:
1. A stack-specific health check endpoint (GET /health → 200)
2. GitHub Actions workflow (NEVER cloudbuild.yaml)
3. Workload Identity Federation (NEVER service account JSON keys)
```
---
## This Skill vs `deployment-engineer` Agent
| Task | Use This Skill | Use `deployment-engineer` Agent |
|------|---------------|---------------------------------|
| Pub/Sub consumer function | YES | No |
| Cloud Storage trigger function | YES | No |
| HTTP webhook / short-lived invocation | YES | No |
| Cold start optimization | YES | No |
| Long-running Cloud Run **service** | No | YES |
| CI/CD pipeline design (service) | No | YES |
| Terraform Cloud Run service module | No | YES (`terraform-specialist`) |
**Key distinction:** Cloud Run **Functions** = event-driven, ephemeral, short-lived invocations.
Cloud Run **Services** = long-running, persistent, serve steady traffic → use `deployment-engineer`.
---
## Pattern Selector
```
What are you building?
|
+-- Pub/Sub consumer, Storage trigger, HTTP webhook?
| -> Load: reference/cloud-run-functions.md
| -> Pick your stack section (Python, NestJS, Spring Boot, TypeScript/Fastify)
|
+-- Cold start is too slow in staging or prod?
| -> Load: reference/cold-start-optimization.md
| -> Apply flags from the optimization table
|
+-- Reviewing existing Cloud Run code or config?
-> Load: assets/cloud-run-antipatterns.md
-> Run through checklist before declaring done
```
---
## Quick Start Checklist
Before writing any Cloud Run Function code:
- [ ] Chose event trigger type: Pub/Sub push | Cloud Storage notification | HTTP
- [ ] Selected target stack: Python FastAPI | NestJS | Spring Boot WebFlux | TypeScript/Fastify
- [ ] Verified runtime version: `python:3.14-slim` | `node:24-alpine` | `eclipse-temurin:21-jre-alpine`
- [ ] Confirmed port binding: `PORT` env var (Cloud Run injects this, default 8080)
- [ ] Health check endpoint planned: `GET /health` → `{ "status": "ok" }`
- [ ] WIF configured or planned (no service account JSON keys)
- [ ] `docker` skill loaded for Dockerfile (multi-stage, non-root user)
---
## Reference Files
| File | Load When |
|------|-----------|
| `reference/cloud-run-functions.md` | Writing a Pub/Sub, Storage, or HTTP trigger function |
| `reference/cold-start-optimization.md` | Function is slow to start or you need `--cpu-boost` flags |
| `assets/cloud-run-antipatterns.md` | Reviewing any Cloud Run code or config for correctness |
---
## Cross-References
- **Dockerfiles**: Load `docker` skill → `reference/dockerfiles.md` for all 4 stack Dockerfiles
- **Cloud Run Service (long-running)**: Dispatch `deployment-engineer` agent
- **Terraform infrastructure**: Dispatch `terraform-specialist` agent
- **ADK agent on Cloud Run**: Use `adk-deploy-guide` skill (has ADK-specific Cloud Run patterns)
- **GitHub Actions pipeline**: `docs/workflows/deployment-ci-cd.md`
- **Security review (WIF, secrets)**: Dispatch `security-reviewer` agent after implementation
---
## GitHub Actions Deploy Snippet (All Stacks)
```yaml
# .github/workflows/deploy-function.yml
name: Deploy Cloud Run Function
on:
push:
branches: [develop, main]
env:
PROJECT_ID: ${{ vars.GCP_PROJECT_ID }}
REGION: us-central1
FUNCTION_NAME: my-function
REGISTRY: ${{ vars.GCP_REGION }}-docker.pkg.dev
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
id-token: write # Required for Workload Identity Federation
contents: read
steps:
- uses: actions/checkout@v4
- name: Authenticate to GCP
uses: google-github-actions/auth@v2
with:
workload_identity_provider: ${{ vars.WIF_PROVIDER }}
service_account: ${{ vars.WIF_SERVICE_ACCOUNT }}
- name: Build and push image
run: |
docker build -t $REGISTRY/$PROJECT_ID/$FUNCTION_NAME:${{ github.sha }} .
gcloud auth configure-docker $REGISTRY --quiet
docker push $REGISTRY/$PROJECT_ID/$FUNCTION_NAME:${{ github.sha }}
- name: Deploy to Cloud Run
run: |
gcloud run deploy $FUNCTION_NAME \
--image $REGISTRY/$PROJECT_ID/$FUNCTION_NAME:${{ github.sha }} \
--region $REGION \
--platform managed \
--no-allow-unauthenticated \
--cpu-boost \
--min-instances 0 \
--max-instances 10
```
> For cold start flags (`--cpu-boost`, `--min-instances`, memory/CPU ratio), see `reference/cold-start-optimization.md`.More API Design skills
lark-event
larksuite/cli
Lark/Feishu real-time event listening / subscribing / consuming: stream events as NDJSON via `lark-cli event consume <EventKey>` (covers IM messages/reactions/chat changes, Approval status changes, Task updates, VC meeting started/joined/ended, Minutes generated, Whiteboard updated, etc.). Use for Lark bots, real-time message processing, long-running subscribers, streaming webhook/push handlers. Supports `--max-events` / `--timeout` bounded runs and a stderr ready-marker contract — designed for AI agents running as subprocesses.
lark-contact
larksuite/cli
飞书 / Lark 通讯录:按姓名 / 邮箱解析成 open_id,或按 open_id 反查姓名 / 部门 / 邮箱 / 联系方式 / 个人状态 / 签名,以及按关键词搜索当前用户可见的机器人 / 智能体(agent)。当用户提到一个名字要下一步发消息 / 排日程,或拿到 open_id 想查具体信息时使用。不负责部门树遍历、按部门列员工、组织架构图,这类需求走原生 OpenAPI。
lark-openapi-explorer
larksuite/cli
飞书/Lark 原生 OpenAPI 探索:从官方文档库中挖掘未经 CLI 封装的原生 OpenAPI 接口。当用户的需求无法被现有 lark-* skill 或 lark-cli 已注册命令满足,需要查找并调用原生飞书 OpenAPI 时使用。

