Antigravityにはエージェントの動きをカスタマイズする仕組みがいくつか用意されています。まずは全体像の中で、Skillがどのような役割を受け持っているのかを確認しておきましょう。

「Rules」と「Skills」はどう使い分けるべきか？

現場で一番よく迷うのが、「この指示は GEMINI.md に書くべきか、それとも Skill にすべきか」という点です。見分け方はとてもシンプルです。

Rulesは「常に守るべきガードレール」です。「コードには日本語でコメントを付けること」「本番DBに直接DDLを流さないこと」「PowerShellの強制削除コマンドは使わないこと」など、どんな作業をしている最中でも絶対に破ってほしくない制約やスタイルを定義します。常にプロンプトに含まれるため、内容は短く絞り込む必要があります。

Skillsは「特定の作業をするときだけ取り出す手順書（ランブック）」です。「Cloud Runへのカナリアデプロイ手順」「Terraformコードのセキュリティ監査手順」「結合テストを回して落ちた箇所を自己修正するループ」といった、そのタスクを頼まれた時だけ知っていればよい一連の実行手順をまとめます。

もしデプロイ手順のような長い文章を GEMINI.md（Rules）に書いてしまうと、普通の関数を1つ直しているだけの時でも、毎ターン何千トークンものデプロイ手順がコンテキストに送り込まれてしまいます。その結果、モデルのアテンションが散漫になり、肝心のコード修正で指示を見落としたり、応答が遅くなったりします。「制約はRulesに、作業手順はSkillsに」と切り分けるのが鉄則です。

毎回チャットで指示する運用からSkillへ切り替えるメリット

チャット欄に毎回「〇〇のコマンドを叩いてビルドして、GCPにデプロイして、エラーが出たらログを見て……」と手作業で打ち込む運用と比べると、Skill化には次のような良さがあります。

• 誰がエージェントを動かしても、検証ステップやチェック項目を漏らさず同じ品質で実行できる
• プロジェクトのリポジトリ（.agents/skills/）に置いてGit管理できるため、運用のノウハウをチーム全員で共有・レビューできる
• 毎回「スキル〇〇を使って」と指定しなくても、エージェントがユーザーの依頼内容を読み取って自律的に該当スキルを見つけて起動してくれる

Skillの根底にある設計思想が、Progressive Disclosure（段階的開示）です。なぜこの仕組みがトークンの節約と推論精度の維持に効くのか、内部の動きを見てみましょう。

コンテキストの詰め込みすぎが引き起こす問題

最近のLLMはコンテキストウィンドウが広く、膨大なテキストを一度に読み込めます。しかし、入るからといって何でもプロンプトに詰め込むと、自己注意機構（Attention）が分散してしまい、次のような不都合が起こりやすくなります。

• 文章の奥に書いた指示をうっかり見落とす、あるいは無関係な手順の設定値を混ぜてしまう
• プロンプトの処理量が増えて、1往復ごとの思考・応答待ち時間が長くなる
• 無駄なトークンを毎ターン消費するため、APIコストが膨らむ

3階層の段階的読み込みフロー

Antigravityでは、必要な情報だけをその都度手元に引き寄せる3段階の構成をとっています。

【Level 0: メタデータの常駐】

  常時インデックス: スキルの name と description のみ（わずか数十トークン）

         │

         ▼ （ユーザーの依頼がマッチした時に自律起動）

【Level 1: SKILL.md のオンデマンド読み込み】

  メイン指示書: 前提条件、ステップ順の手順、検証コマンド

         │

         ▼ （さらに詳細な仕様やスクリプトが必要な時だけ参照）

【Level 2: スクリプトや詳細ドキュメントの参照】

  実行スクリプト（scripts/）、実装例（examples/）、

  設定テンプレート（resources/）、詳細マニュアル（references/）

エージェントが起動した時点では、プロジェクト内にスキルが何十個あっても、システムプロンプトには各スキルの name と description（YAMLフロントマターの情報）しか入りません。消費するトークンはスキル1件あたりわずか数十トークン程度です。

ユーザーから「Cloud Runに新しいイメージをデプロイして確認して」と依頼が来た段階で、エージェントはメタデータ一覧から該当するスキルを見つけ、view_file ツールを使って SKILL.md の本文を初めて読み込みます。

さらに、数千行に及ぶAPI仕様書やトラブルシューティング集は references/ フォルダに分けておけば、通常時は一切読み込まれず、エラーが起きて詳しく調べたい時にだけピンポイントで参照されます。普段はコンテキストをすっきり清潔に保ち、いざという時だけ専門家になる仕組みです。

スキルの読み込み優先度（Loading Priority）

Antigravityでは複数の場所からスキルを探索します。同名のスキルが見つかった場合は、以下の優先順位に従って上位のものが適用されます。

基本的には、「個人でよく使う汎用スキルは Global（~/.gemini/skills/ や ~/.gemini/config/）に置いておき、プロジェクト固有の事情がある場合は Workspace（.agents/skills/）に同名スキルを置いて上書きする」という使い方がスムーズです。

ここからは、実際に動くカスタムSkillを作る際の手順を見ていきましょう。

標準ディレクトリ構造

Skillは、プロジェクト直下の .agents/skills/<skill-name>/ フォルダに配置します。公式仕様で推奨されている標準的な構成は以下の通りです。

.agents/skills/gcp-cloudrun-deploy/

├── SKILL.md              # 【必須】メインの指示書（YAMLフロントマター付き）

├── scripts/              # 【任意】エージェントが実行するスクリプト（PythonやShell等）

│   ├── build_and_push.sh

│   └── verify_health.py

├── examples/             # 【任意】設定ファイルの記述例やコマンド出力のサンプル

│   └── service-staging.yaml

├── resources/            # 【任意】Terraformモジュールや設定テンプレート素材

│   └── cloudrun-template.json

└── references/           # 【任意】詳細な仕様書、マニュアル、設計書（長文ドキュメント）

    └── gcp_deploy_troubleshooting.md

ここでポイントになるのが、resources/ と references/ の使い分けです。

• references/ は「エージェントに読ませるためのドキュメント」: 長文のマニュアル、API仕様書、過去の障害事例など、必要な時だけ参照させたい読み物を置きます。
• resources/ は「エージェントに展開・流用させるための素材」: 設定テンプレート、定型設定のひな形など、作業中に加工・配置するファイルを置きます。

SKILL.md のYAMLフロントマターを書く

SKILL.md の冒頭には、必ずYAML形式のフロントマターを記述します。エージェントがこのスキルを見つけて起動できるかどうかは、この記述にかかっています。

---

name: gcp-cloudrun-deploy

description: >-

  Builds container images, deploys services to Google Cloud Run with traffic migration,

  and verifies deployment health via Cloud Logging and HTTP endpoints.

  Use this skill whenever the user asks to deploy, release, or update Cloud Run services,

  or perform zero-downtime deployment verification on Google Cloud.

---

公式仕様における各フィールドの要件は次の通りです。

• name（必須）: スキルの一意な識別名です。小文字の英数字とハイフン（ケバブケース）を使用します。トラブルを避けるためにも、フォルダ名と一致させておくのが確実です。
• description（必須）: エージェントが依頼に対してこのスキルを使うべきか判断するための説明文です。「何をするスキルか（What）」だけでなく、「どんな依頼を受けたときに使うべきか（When）」を三人称で具体的に記述します。deploy や Cloud Run、release など、ユーザーがプロンプトで使いそうなキーワードを含めておくと、検知の精度が上がります。

指示がブレないSKILL.mdを作る5つの構成要素

エージェントに安定した作業をさせるため、SKILL.md 本文には以下の5つの要素を盛り込んでおくのがおすすめです。

1. 前提条件の確認（Prerequisites）: 必要なCLIツール（gcloud, docker等）の有無や認証状態、環境変数の事前チェック手順
2. 明確な作業手順（Step-by-Step Execution）: 順番に進めるステップ。長くなるコマンドは scripts/ 内のスクリプトを呼び出す形にする
3. 検証と確認（Verification）: デプロイや変更が本当に成功したかをエージェント自身に確認させるテストコマンドと合格基準
4. エラー時の対応（Troubleshooting）: エラーが起きた場合のログ取得コマンドや、切り戻し手順（必要に応じて references/ に詳細を逃がす）
5. 完了報告のフォーマット（Output Format）: ユーザーに最後に報告すべき項目（URL、リビジョン番号、確認結果の要約など）

ここからは、Google Cloudの現場で実際に使える3つのSkillパターンを紹介します。

※本記事で紹介するコードは、設計の骨組みを示す実践的なテンプレートです。プロジェクトID、サービス名、テストファイル名などはお手元の環境やリポジトリ構成に合わせて適宜書き換えてご利用ください。

パターン1: Google Cloud Run セキュアデプロイ・Skill

Cloud Runへのコンテナビルドから、ゼロトラフィックでのカナリアデプロイ、ヘルスチェック、そして100%トラフィック移行までを一連のフローとして安全に実行するSkillです。

ファイル配置: .agents/skills/gcp-cloudrun-deploy/SKILL.md

---

name: gcp-cloudrun-deploy

description: >-

  Guides the build, push, deployment, and health verification for Google Cloud Run services.

  Use this skill whenever the user requests deploying application code to Cloud Run,

  updating Cloud Run revisions, or validating production/staging deployments on GCP.

---



# Google Cloud Run Secure Deployment Runbook



Follow these sequential steps to safely deploy the application to Google Cloud Run.



## 1. Prerequisites Check

Before executing any deployment commands, verify the local environment:

- Verify active GCP project: `gcloud config get-value project`

- Verify authentication: `gcloud auth print-access-token > /dev/null`

- Verify Docker/Cloud Build access to Artifact Registry:

  `gcloud artifacts repositories list --location=asia-northeast1`



If any prerequisite fails, STOP and request the user to authenticate via `gcloud auth login`.



## 2. Container Build & Push

Build the container image using Google Cloud Build to ensure consistent remote builds:

```bash

# Configuration variables (adapt to your repository)

PROJECT_ID=$(gcloud config get-value project)

REGION="asia-northeast1"

REPO_NAME="app-containers"      # Target Artifact Registry repository

IMAGE_NAME="backend-api"        # Target image name

TAG=$(git rev-parse --short HEAD)

TARGET_IMAGE="${REGION}-docker.pkg.dev/${PROJECT_ID}/${REPO_NAME}/${IMAGE_NAME}:${TAG}"



gcloud builds submit --tag "${TARGET_IMAGE}" .

```



## 3. Deploy Revision with 0% Initial Traffic (Canary/Verification)

`--no-traffic` is only accepted when adding a revision to an **already-existing** Cloud Run service — Cloud Run rejects it on the very first deployment of a brand-new service (`ERROR: --no-traffic not supported when creating a new service`). Always check whether the service exists first; the first-ever deployment serves 100% traffic immediately and has no canary phase.

```bash

SERVICE_NAME="backend-api-service" # Target Cloud Run service name



if ! gcloud run services describe "${SERVICE_NAME}" --region "${REGION}" > /dev/null 2>&1; then

  echo "First-time deployment: creating ${SERVICE_NAME} (serves 100% traffic immediately)"

  gcloud run deploy "${SERVICE_NAME}" \

    --image "${TARGET_IMAGE}" \

    --region "${REGION}" \

    --set-env-vars="ENVIRONMENT=production"

  exit 0

fi



gcloud run deploy "${SERVICE_NAME}" \

  --image "${TARGET_IMAGE}" \

  --region "${REGION}" \

  --no-traffic \

  --tag "canary" \

  --set-env-vars="ENVIRONMENT=production"

```



## 4. Run Automated Health Verification

Execute the cross-platform Python verification script against the canary revision:

- Run: `python ./scripts/verify_deploy.py`

- If the verification returns HTTP 200 and no crash logs are found in Cloud Logging within 60 seconds, proceed to step 5.

- If verification fails, inspect logs via `gcloud logging read` and abort deployment.



## 5. Migrate 100% Traffic to New Revision

```bash

gcloud run services update-traffic "${SERVICE_NAME}" \

  --region "${REGION}" \

  --to-latest

```



## 6. Deployment Summary

Report the following to the user:

- Service Name & Target Region

- Active Revision ID

- Deployed Image Tag

- Health check verification status (HTTP status code and response latency)

検証用ヘルパースクリプト: .agents/skills/gcp-cloudrun-deploy/scripts/verify_deploy.py

クロスプラットフォーム（Windows / macOS / Linux）で確実に動作するよう、Python標準ライブラリのみで実装した検証スクリプトです。Cloud RunのJSON出力からタグが canary のURLを厳密に抽出してヘルスチェックを実行します。

実機検証で判明した2点の注意点を反映しています。① Windowsでは gcloud の実体が gcloud.cmd（バッチファイル）であるため、subprocess.run([“gcloud”, …]) をそのまま呼ぶと FileNotFoundError になります。shutil.which(“gcloud”) で実行ファイルの実パスを解決してから渡すことで、shell=Trueを使わずに安全にクロスプラットフォーム対応できます。② ヘルスチェックのエンドポイントは /healthz ではなく /health など別名にしてください。実機で検証したところ、Cloud Run側のフロントエンドが /healthz 宛のリクエストをアプリケーションコンテナへ転送せず、Google共通の404ページを返してしまう（アクセスログにも記録されない）挙動が確認されました。

#!/usr/bin/env python3

"""

Cloud Run カナリアデプロイ自動検証スクリプト

Windows / macOS / Linux クロスプラットフォーム対応

"""

import json

import shutil

import subprocess

import sys

import urllib.request



SERVICE_NAME = "backend-api-service"  # 対象のCloud Runサービス名

REGION = "asia-northeast1"



# Windowsではgcloudの実体がgcloud.cmdのため、shell=Trueを使わず

# shutil.whichで実行ファイルの実パスを解決してから呼び出す

GCLOUD = shutil.which("gcloud")

if not GCLOUD:

    print("Error: gcloud コマンドが見つかりません。PATHを確認してください。", file=sys.stderr)

    sys.exit(1)



print("=== [1/2] カナリアURLの取得 ===")

cmd_desc = [

    GCLOUD, "run", "services", "describe", SERVICE_NAME,

    f"--region={REGION}", "--format=json"

]

res = subprocess.run(cmd_desc, capture_output=True, text=True)

if res.returncode != 0:

    print(f"Error: サービス情報の取得に失敗しました:\n{res.stderr}", file=sys.stderr)

    sys.exit(1)



service_data = json.loads(res.stdout)

traffic_list = service_data.get("status", {}).get("traffic", [])



# tag == 'canary' のエントリから正確にURLを取得

canary_url = None

for t in traffic_list:

    if t.get("tag") == "canary":

        canary_url = t.get("url")

        break



if not canary_url:

    print("Error: タグ 'canary' のURLが見つかりませんでした。", file=sys.stderr)

    sys.exit(1)



print(f"ヘルスチェック実行中: {canary_url}/health")

try:

    req = urllib.request.Request(f"{canary_url}/health", headers={"User-Agent": "Antigravity-Verifier/1.0"})

    with urllib.request.urlopen(req, timeout=10) as response:

        if response.status == 200:

            print("SUCCESS: ヘルスチェック成功 (HTTP 200 OK)")

        else:

            print(f"FAILED: ステータスコード {response.status}", file=sys.stderr)

            sys.exit(1)

except Exception as e:

    print(f"FAILED: ヘルスチェック接続エラー: {e}", file=sys.stderr)

    sys.exit(1)



print("=== [2/2] Cloud Logging エラーログの確認 ===")

filter_expr = f'resource.type="cloud_run_revision" AND resource.labels.service_name="{SERVICE_NAME}" AND severity>=ERROR'

cmd_log = [

    GCLOUD, "logging", "read", filter_expr,

    "--limit=5", "--freshness=2m", "--format=value(textPayload)"

]

log_res = subprocess.run(cmd_log, capture_output=True, text=True)

error_logs = [line for line in log_res.stdout.splitlines() if line.strip()]



if error_logs:

    print(f"WARNING: 直近2分間に {len(error_logs)} 件のエラーログが検出されました。", file=sys.stderr)

    for err in error_logs[:3]:

        print(f"  - {err}", file=sys.stderr)

    sys.exit(1)



print("全検証チェックをクリアしました！")

sys.exit(0)

パターン2: Google Cloud アーキテクチャ＆セキュリティレビュー・Skill

Terraformコードに対して、Google Cloud Well-Architected FrameworkやIAMの最小権限原則に沿ってセキュリティチェックを実施するSkillです。詳細なチェックリストは references/ 配下に切り出し、必要な時だけ参照させます。

ファイル配置: .agents/skills/gcp-architecture-review/SKILL.md

---

name: gcp-architecture-review

description: >-

  Conducts comprehensive Google Cloud architecture, security, IAM least privilege,

  and cost-optimization reviews on Terraform and infrastructure code.

  Use this skill whenever the user asks for GCP security audit, infrastructure review,

  or architectural validation against Google Cloud Well-Architected principles.

---



# Google Cloud Architecture & Security Review Skill



Review all infrastructure code and proposed changes against Google Cloud Enterprise Standards.



## 1. Review Pillars



Examine the codebase across the following 4 pillars:



### Pillar A: IAM & Access Control (Least Privilege)

- [ ] No `roles/owner` or `roles/editor` assigned to service accounts.

- [ ] Dedicated per-service Service Accounts (avoid sharing default Compute Service Account).

- [ ] Workload Identity Federation used for external/CI/CD authentication (no exported JSON service account keys).



### Pillar B: Data Protection & Network Security

- [ ] Cloud Storage buckets have `uniform_bucket_level_access = true` and `public_access_prevention = "enforced"`.

- [ ] Cloud SQL instances have `ipv4_enabled = false` (Private IP only via Private Service Access) and require SSL/TLS.

- [ ] Artifact Registry repositories have immutable tags and vulnerability scanning enabled.

- [ ] Encryption at rest: Customer-Managed Encryption Keys (CMEK) via Cloud KMS for sensitive data stores.



### Pillar C: Reliability & Scalability

- [ ] Multi-zone/Regional deployment for high availability.

- [ ] Appropriate auto-scaling limits (`min_instances`, `max_instances`) configured on Cloud Run / GKE.

- [ ] Cloud Monitoring alerts and Cloud Logging sinks defined for critical error thresholds.



### Pillar D: Cost Optimization

- [ ] Automated lifecycle rules on Cloud Storage buckets (transition to Nearline/Coldline/Archive or delete old versions).

- [ ] Cloud SQL automated backups and deletion protection configured.



## 2. Inspection Workflow

1. Run static analysis using `trivy` or `tfsec` if installed:

   ```bash

   tfsec . --format table || true

   ```

2. Scan all `.tf` files for hardcoded secrets, open CIDR blocks (`0.0.0.0/0`), and overly permissive IAM roles.

3. For detailed remediation guidelines, refer to [./references/security_checklist.md](./references/security_checklist.md).



## 3. Output Format

Present findings in a markdown table grouped by Severity (`CRITICAL`, `HIGH`, `MEDIUM`, `LOW`), including:

- File & Line Number

- Identified Risk & Well-Architected Pillar

- Concrete Code Fix (Before vs After diff snippet)

※ references/security_checklist.md について:
上記スキル内で参照している references/security_checklist.md には、社内のセキュリティ規程や監査項目をまとめておきます。もしこのファイルが存在しない場合でも、エージェントは学習済みのWell-Architected原則に基づいて自律的にレビューを継続します。

パターン3: 結合テスト＆自律自己修復・Skill

結合テストを実行し、失敗した場合はエラーログをパースして原因箇所を特定、修正パッチを当てて再テストする一連のループを自動で回すSkillです。

※事前準備: テスト結果をJSON形式で構造化解析するため、あらかじめ pip install pytest pytest-json-report をインストールした環境で実行してください。

ファイル配置: .agents/skills/automated-integration-testing/SKILL.md

---

name: automated-integration-testing

description: >-

  Runs integration and end-to-end test suites, parses failure logs,

  analyzes root causes, and implements self-healing code fixes in a test-fix loop.

  Use this skill whenever the user asks to run integration tests, verify system integrity,

  or fix failing test suites automatically.

---



# Automated Integration Testing & Self-Healing Loop



Execute the test suite, isolate failures, and iterate until 100% green.



## 1. Environment Setup & Test Execution

Ensure testing tools are installed (`pytest` and `pytest-json-report`).

Run the test runner script to execute tests and produce structured JSON output:

```bash

python ./scripts/run_and_analyze.py --suite=integration

```



## 2. Failure Analysis Protocol

When test failures occur:

1. Inspect `target/test-results.json` generated by the runner.

2. For each failed assertion:

   - Identify the exact test file and line number.

   - Trace the underlying API/Service call stack.

   - Differentiate between flaky/timeout errors and logic/regression errors.



## 3. Self-Healing Loop (Max 3 Iterations)

1. Formulate a minimal, atomic code fix targeting the root cause.

2. Apply the fix using precise file modification tools.

3. Re-run only the failing test case identified in step 2 to verify the fix:

   ```bash

   # Dynamically target the failing file and test identified in step 2

   pytest tests/integration/.py -k ""

   ```

4. If passed, run the full integration suite again to guard against regressions.

5. If still failing after 3 iterations, stop and summarize the blockers for the user.



## 4. Verification & Final Report

Provide a clean summary containing total tests executed, passing rate, and a diff of changes made during self-healing.

結果解析スクリプト: .agents/skills/automated-integration-testing/scripts/run_and_analyze.py

#!/usr/bin/env python3

import subprocess

import json

import sys

import os



def main():

    print("[+] Running Integration Test Suite via pytest...")

    cmd = ["pytest", "tests/integration", "--json-report", "--json-report-file=target/test-results.json", "-v"]

    os.makedirs("target", exist_ok=True)

    

    result = subprocess.run(cmd, capture_output=True, text=True)

    

    report_path = "target/test-results.json"

    if not os.path.exists(report_path):

        if "unrecognized arguments: --json-report" in result.stderr:

            print("[-] Error: 'pytest-json-report' が見つかりません。\n    実行前に 'pip install pytest-json-report' を実行してください。", file=sys.stderr)

        else:

            print(f"[-] Test execution failed to generate report:\n{result.stderr}", file=sys.stderr)

        sys.exit(1)

        

    with open(report_path, "r", encoding="utf-8") as f:

        data = json.load(f)

        

    summary = data.get("summary", {})

    total = summary.get("total", 0)

    passed = summary.get("passed", 0)

    failed = summary.get("failed", 0)

    

    print("==========================================")

    print(f"Test Summary: Total={total}, Passed={passed}, Failed={failed}")

    print("==========================================")

    

    if failed > 0:

        print("\n[!] Failure Details:")

        for test in data.get("tests", []):

            if test.get("outcome") == "failed":

                nodeid = test.get("nodeid")

                call_info = test.get("call", {})

                crash_msg = call_info.get("crash", {}).get("message", "Unknown error")

                print(f"  - Failed Test: {nodeid}")

                print(f"    Message: {crash_msg}\n")

        sys.exit(1)

        

    print("[+] All integration tests passed successfully!")

    sys.exit(0)



if __name__ == "__main__":

    main()

実際にSkillを作って運用していると、いくつか引っかかりやすいポイントが出てきます。現場で役立つ対策をまとめました。

1. description が短すぎて起動しない、あるいは無関係な依頼で誤爆する

「せっかくSkillを作ったのにエージェントが全然使ってくれない」「関係ない作業なのに勝手にSkillが動き出した」というトラブルは、大半が description の書き方に原因があります。

たとえば次のように短すぎる説明文を書いてしまうと、エージェントはいつ使えばいいのか判断できません。

# NG例: 曖昧で短すぎる

description: Deploys to GCP.

これでは普通にシェルコマンドを1回叩いて終わらされてしまいます。次のように、対象サービス、行う処理、そしてユーザーが言いそうなトリガーフレーズを具体的に盛り込むのが正解です。

# OK例: 動作内容とトリガーキーワードを具体的に指定

description: >-

  Builds container images, deploys services to Google Cloud Run, and validates canary health.

  Use this skill whenever the user asks to deploy, update, release to Cloud Run,

  or perform zero-downtime canary deployment verification on Google Cloud.

2. SKILL.md にドキュメントを書きすぎてファイルが太る

Skillをしっかり作ろうとするあまり、過去のトラブル事例や何ページもある設定一覧を1つの SKILL.md に全部詰め込んでしまうケースです。これではせっかくの段階的開示が台無しになってしまいます。

SKILL.md 本体は100〜200行程度の「実行フローの骨組み」に留め、長いマニュアルや詳細なエラー対応集は references/troubleshooting.md などに切り出して、リンクを貼る形にしましょう。エージェントはリンク先を「本当に必要になった時だけ」読みに行きます。

3. OSの違い（Windows / Mac / Linux）でスクリプトが止まる

チーム内でmacOS、Linux、Windows（PowerShell等）が混在していると、BashスクリプトがWindows環境で動かずにエラーになることがあります。

複数OSで動かす可能性がある複雑な処理は、シェルスクリプトではなく Pythonスクリプト（scripts/*.py）で書いておく のが最も安心です。外部ライブラリを入れず、Python標準ライブラリ（subprocess, json, os, sys）だけで書いておけば、どの環境でもエラーなく実行できます。

4. リポジトリへの秘密情報（APIキー・サービスアカウントキー）の混入

.agents/skills/ はGitにコミットしてチーム共有するのが基本ですが、スクリプトや設定例の中にGCPサービスアカウントキーやDBのパスワードを絶対に直接書き込まないでください。

認証情報は gcloud auth のセッションや、Google Secret Manager、環境変数からその場で取得する作りに徹底しましょう。

今回は、Google Antigravityの「Skill」機能の仕組みと、現場で即使える実践的なパターンを紹介しました。

実際にプロジェクトで運用してみると分かりますが、Skillの一番のメリットは「プロンプト入力の手間が減る」こと以上に、「チーム内の優れた運用ノウハウがコードとしてリポジトリに残り、誰がエージェントを動かしても同じ高水準で作業が完了する」という点にあります。

いきなり完璧な巨大Skillを作ろうとする必要はありません。まずは普段よく叩いているデプロイコマンドやテスト実行など、身近な定型タスクを1つ .agents/skills/ にまとめて動かしてみてください！
その手軽さと快適さにきっと驚くはずです！

システムサポートでは、Google Cloudの導入や活用を支援しております。

Google Cloudを導入したい・導入したけど使いこなせていない…という方は、お気軽にご相談ください！