Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

Google Antigravity を使用した KCC オペレーションの習得

1. はじめに

この Codelab では、エージェント型開発プラットフォームである Google Antigravity（以降、Antigravity と呼びます）について学習します。Antigravity は、IDE をエージェントファーストの時代へと進化させるプラットフォームです。

行を自動補完するだけの標準的なコーディングアシスタントとは異なり、Antigravity は、計画、コーディング、ウェブの閲覧まで行える自律型エージェントを管理するための「ミッションコントロール」を提供し、構築を支援します。

Antigravity は、エージェントファーストのプラットフォームとして設計されています。AI は、コードを作成するツールではなく、人間による介入を最小限に抑えながら、複雑なエンジニアリングタスクの計画、実行、検証、反復処理を行える自律型アクターであることを前提としています。

学習内容

Antigravity のインストールと構成。
エージェントマネージャー、エディタ、ブラウザなど、Antigravity の主要なコンセプトの探索。
Google Cloud リソースを安全かつコンプライアンスに準拠して管理するための本番環境グレードの KCC Ops スキルをゼロから構築 。

必要なもの

現在、Antigravity は個人の Gmail アカウント向けのプレビュー版として提供されています。最上位モデルを使用するための無料割り当てが付属しています。

Antigravity は、システムにローカルにインストールする必要があります。このプロダクトは、Mac、Windows、特定の Linux ディストリビューションで利用できます。ご自身のマシンに加えて、次のものが必要になります。

Gmail アカウント（個人の Gmail アカウント）。
Google Cloud アカウントと Google Cloud プロジェクト
Google Cloud コンソールと Cloud Shell をサポートするウェブブラウザ（Chrome など）

2. 設定と要件

プロジェクトのセットアップ

Google Cloud プロジェクトの作成

Google Cloud コンソールのプロジェクト選択ページで、Google Cloud プロジェクトを選択または作成します。
Cloud プロジェクトに対して課金が有効になっていることを確認します。プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。

この Codelab は、初心者を含むあらゆるレベルのユーザーとデベロッパーを対象としています。

3. インストール

Antigravity がまだインストールされていない場合は、Antigravity のインストールから始めましょう。現在、このプロダクトはプレビュー版として提供されており、個人の Gmail アカウントを使用して開始できます。

ダウンロードページに移動し、該当するオペレーティングシステムのバージョンをクリックします。アプリケーションインストーラを起動し、マシンにインストールします。インストールが完了したら、Antigravity アプリケーションを起動します。

セットアップの主な手順は次のとおりです。

セットアップフローを選択する: この Codelab では、最初から始めることをおすすめします。
レビュー主導の開発（推奨）: このオプションを選択します。これにより、エージェントが意思決定を行い、ユーザーに承認を求めることができます。これはインフラストラクチャオペレーションにとって重要です。

次に、エディタを構成 してGoogle にログイン します。最後に、利用規約 に同意します。

4. インフラストラクチャのセットアップ: GKE と Config Connector

スキルを構築するには、Config Connector（KCC） が手動でインストールされ、名前空間モード で構成された Google Cloud 環境が必要です。これにより、GCP リソースを Kubernetes オブジェクトとして管理できます。

ステップ 0: 環境を準備する

1. クラスタの前提条件

必要な機能が有効になっている新しい GKE クラスタを作成します。

# Set your variables
export PROJECT_ID=$(gcloud config get-value project)
export CLUSTER_NAME="kcc-ops-cluster"
export REGION="us-central1"

# Create the cluster
gcloud container clusters create ${CLUSTER_NAME} \
    --region ${REGION} \
    --release-channel "regular" \
    --workload-pool=${PROJECT_ID}.svc.id.goog \
    --logging=SYSTEM \
    --monitoring=SYSTEM

# Get cluster credentials
gcloud container clusters get-credentials ${CLUSTER_NAME} --region ${REGION}

**2. Config Connector Operator をインストールする

オペレーターはインストールを最新の状態に保ちます。

# Download the latest Config Connector operator
gcloud storage cp gs://configconnector-operator/latest/release-bundle.tar.gz release-bundle.tar.gz

# Extract the bundle
tar zxvf release-bundle.tar.gz

# Install the operator (Standard Cluster)
kubectl apply -f operator-system/configconnector-operator.yaml

3. 名前空間モードを構成する

ConfigConnector リソースを作成して、動作モードを指定します。

# configconnector.yaml
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnector
metadata:
  name: configconnector.core.cnrm.cloud.google.com
spec:
  mode: namespaced
  stateIntoSpec: Absent

kubectl apply -f configconnector.yaml

4. ID と Namespace を作成する

このラボでは、default Namespace と専用の Google サービスアカウント（GSA）を使用します。

# Set your variables
export PROJECT_ID=$(gcloud config get-value project)
export NAMESPACE="default"

# Create the Google Service Account
gcloud iam service-accounts create kcc-identity --project ${PROJECT_ID}

# Grant permissions on the project
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/owner"

# Grant Metric Writer permissions
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/monitoring.metricWriter"

# Bind GSA to KSA via Workload Identity
gcloud iam service-accounts add-iam-policy-binding \
    kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com \
    --member="serviceAccount:${PROJECT_ID}.svc.id.goog[cnrm-system/cnrm-controller-manager-${NAMESPACE}]" \
    --role="roles/iam.workloadIdentityUser"

5. Namespace を構成する

ConfigConnectorContext を作成して Namespace を監視します。

# configconnectorcontext.yaml
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnectorContext
metadata:
  name: configconnectorcontext.core.cnrm.cloud.google.com
  namespace: default
spec:
  googleServiceAccount: "kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com"
  stateIntoSpec: Absent

kubectl apply -f configconnectorcontext.yaml

6. インストールを検証する

コントローラが default Namespace の準備ができるまで待ちます。

kubectl wait -n cnrm-system \
    --for=condition=Ready pod \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -l cnrm.cloud.google.com/scoped-namespace=default

5. エージェントマネージャー: ミッションコントロール

Antigravity はオープンソースの Visual Studio Code（VS Code）の基盤をフォークしていますが、テキスト編集よりもエージェント管理を優先するようにユーザーエクスペリエンスを大幅に変更しています。インターフェースは、Editor と Agent Manager の 2 つの異なるプライマリウィンドウに分割されています。

エージェントマネージャー

Antigravity を起動すると、通常はエージェントマネージャーが表示されます。このインターフェースはミッションコントロール ダッシュボードとして機能します。これは高度なオーケストレーション用に設計されており、デベロッパーはさまざまなワークスペースやタスクで非同期に動作する複数のエージェントを生成、モニタリング、操作できます。

このビューでは、デベロッパーはアーキテクトとして機能します。大まかな目標を定義します。これらのリクエストごとに、専用のエージェントインスタンスが生成されます。UI には、これらの並行ワークフローの視覚化が表示され、各エージェントのステータス、生成されたアーティファクト （計画、結果、差分）、人間による承認が必要な保留中のリクエストが表示されます。

6. Antigravity ブラウザとアーティファクト

Antigravity は、計画を立てて作業を完了すると、アーティファクト を作成します。これらは、リッチマークダウンファイル、アーキテクチャ図、画像、ブラウザの記録、コードの差分です。

アーティファクトは「信頼のギャップ」を解消します

エージェントが「バグを修正しました」と主張した場合、デベロッパーはコードを読んで確認する必要がありました。Antigravity では、エージェントがアーティファクトを生成して証明します。

アーティファクト

Antigravity によって生成される主なアーティファクトは次のとおりです。

Task Lists: コードを記述する前に生成される構造化された計画。
Implementation Plan: 技術的な詳細を含むアーキテクチャの変更。
Walkthrough: 変更の概要とテスト方法。
Browser Recordings: UI 検証用のブラウザセッションの動画記録。

Antigravity ブラウザ

エージェントがウェブを操作する必要がある場合は、ブラウザサブエージェント を呼び出します。このサブエージェントは、クリック、スクロール、入力、コンソールログの読み取りを行うことができます。専用のモデルを使用して、Antigravity で管理されるブラウザ内で開いているページを操作します。

7. エディタの操作

エディタは VS Code の使い慣れた操作性を維持しています。標準のファイルエクスプローラ、構文ハイライト、拡張機能エコシステムが含まれています。

エディタの主な機能:

自動補完: Tab キーを押すと、スマートな候補が受け入れられます。
Tab キーでインポート: 不足している依存関係の追加を提案します。
コマンド（Cmd + I）: 自然言語を使用してインライン補完をトリガーします。
エージェントサイドパネル（Cmd + L）: エージェントパネルを切り替えて、質問したり、@ を使用してファイルを参照したりします。

8. フィードバックする

Antigravity の中核となるのは、フィードバックを簡単に収集できることです。これらのアーティファクトは、Google ドキュメントスタイルのコメント でエージェントにフィードバックを提供する方法です。

計画やタスクにコメントを追加する場合は、必ずコメントを送信してください。これにより、エージェントを目的の方向に導くことができます。

9. KCC Ops スキルを構築する

プラットフォームについて理解できたので、KCC Ops スキル を構築しましょう。

Kubernetes Config Connector（KCC）を使用すると、GCP リソースを K8s オブジェクトとして管理できます。ただし、構成のドリフト、コンプライアンス違反、リソースの誤った再作成を防ぐための安全対策が必要です。

ステップ 1: スキルを構造化する

ワークスペースのルートに、スキルのディレクトリ構造を作成します。

mkdir -p .agents/skills/kcc-ops/scripts
mkdir -p .agents/skills/kcc-ops/resources/policies/templates
mkdir -p .agents/skills/kcc-ops/resources/policies/constraints

ステップ 2: SKILL.md（ブレイン）を作成する

SKILL.md は、エージェントのメタデータとコアの「ゴールデンルール」を定義します。.agents/skills/kcc-ops/SKILL.md を作成します。

---
name: kcc-ops
description: Assists with Config Connector (KCC) configuration, resource generation, and troubleshooting on Google Cloud.
---

# Config Connector (KCC) Operations Skill

Use this skill to manage Google Cloud resources using Kubernetes-style configuration (Config Connector).

## 🛑 GOLDEN RULE: Separate Generation from Application

**NEVER generate and apply a manifest in a single autonomous step.**

1. **Craft:** Write the generated manifest to a local file.
2. **Analyze:** Present the manifest to the user. Perform Impact Analysis and Dry Runs. Explain the consequences of the change (e.g., "If this topic is deleted, the attached subscription becomes orphaned").
3. **Wait:** Pause execution and explicitly wait for user permission to proceed.
4. **Apply:** Only run `kubectl apply` *after* the user has reviewed the manifest and the impact analysis, and then unequivocally confirmed you should proceed.

## Core Responsibilities

0. **Context Verification**: Verify the execution context (cluster, namespace, GCP project, user account) with the user before performing any operations.
1. **Installation & Health**: Verify KCC is properly installed and healthy on the target cluster.
2. **Resource Inventory**: Query and summarize existing KCC resources within a namespace.
3. **Brownfield Bulk Export (Adoption)**: Export existing GCP project resources into valid KCC YAML manifests.
4. **Manifest Generation**: Generate valid YAML manifests for GCP resources using KCC CRDs.
5. **Impact Analysis**: Identify ancillary services and resources (e.g., Cloud Run, Apps) that depend on a resource being modified.
6. **Change Differentiation**: Generate diff summaries for resource edits to support change control.
7. **Policy Compliance**: Vet KCC manifests against OPA/Gatekeeper policies.
8. **Troubleshooting**: Analyze resource status, and consult the troubleshooting guide to resolve reconciliation issues.

## Guidelines for Operations

### 0. Context Verification

Before performing **any operations or executing commands** (including health checks), you **MUST** verify the current execution context and obtain explicit user confirmation.

1. **Read Context:** Use commands like `kubectl config current-context`, `kubectl config view --minify -o jsonpath='{.contexts[0].context.namespace}'`, `gcloud config get-value project`, and `gcloud config get-value account` to determine the active environment.
2. **Present & Ask:** Show this information to the user clearly (e.g., "I see my context is X, namespace is Y, project is Z, and account is A. Is this correct?").
3. **Wait:** Do not proceed with any other steps or scripts until the user has confirmed or provided corrections.

### 1. Installation & Health Check

Before performing operations, ensure the environment is ready:

- **Automation**: You MUST use `./scripts/check-health.sh` to verify namespaces, controllers, and CRDs. Do not use manual kubectl commands for health checks, as the script enforces standard formatting and context verification.

### 2. Resource Inventory & Discovery

To understand the current state of infrastructure:

- **Automation**: You MUST use `./scripts/inventory.sh` to get a summary table of all KCC resources. Do not use manual kubectl queries, as the script is optimized to securely discover all CRDs with context validation.

### 3. Manifest Structure

- All KCC resources belong to the `cnrm.cloud.google.com` API group.
- Use the `cnrm.cloud.google.com/project-id` annotation for cross-project resource management if not using Namespaced Mode.
- Always include `apiVersion`, `kind`, `metadata`, and `spec`.

### 4. Official Resource Reference (Agent Action)

When generating or troubleshooting manifests, you **must not guess** the API schema. Always consult the [Official Config Connector Reference](https://cloud.google.com/config-connector/docs/reference/overview) for the exact API version, kind, and required fields for the specific resource and cross reference with the official [github repository](https://github.com/GoogleCloudPlatform/k8s-config-connector/tree/master/config/crds/resources).

### 5. Troubleshooting Checklist

When a resource is not reconciling (check `kubectl get <kind> <name> -o yaml`):

- **Ready Condition**: Look for `status.conditions` where `type: Ready` and `status: "False"`.
- **Reason/Message**: Check the `reason` and `message` fields in the status conditions.
- **Consult the Guide**: Immediately check `./resources/troubleshooting-guide.md` for definitions of the error reason (e.g. `DependencyInvalid`, `ManagementConflict`) and follow its resolution steps.
- **Common Issues**:
  - Permissions: The KCC service account lacks IAM roles.
  - Quotas: GCP project quota exceeded.
  - Conflicts: Resource already exists or is managed by another tool.
  - Immutable Fields: Attempting to change a field that requires resource recreation. Look for "Update failed" errors related to immutable fields.
  - Reference Resolution: Check if the resource is waiting for a dependency (e.g., `referenced project not found`).

### 6. Impact Analysis (Ancillary Services)

Before modifying a resource (e.g., GCS Bucket, Pub/Sub Topic), verify whatElse depends on it:

- **Reference Search (Cluster-wide)**: Search for other KCC resources that reference the item.

  ```bash
  # Example: Find resources referencing a bucket named 'my-data-bucket'
  kubectl get-all -n <namespace> -o yaml | grep -C 5 "my-data-bucket"
  ```

- **IAM-based Analysis**: Check for IAM Service Accounts that have roles on the specific resource. A Cloud Run job or GKE Workload Identity might be using those permissions.
- **Common Ancillary Dependencies**:
  - **Storage Buckets**: Look for Cloud Run/GKE mounts (CSI), Cloud Functions triggers, or Dataflow jobs.
  - **Networks**: Check for Firewall rules, Forwarding rules, and GKE cluster assignments.
  - **IAM Policies**: Changing a policy might break access for external applications not managed by KCC.
- **Resource Graph**: Use `gcloud asset search-all-resources` to find resources that might have implicit links.

### 3. Policy Compliance & Best Practices

Evaluate KCC manifests against security and governance policies. The vetting tool supports three source modes:

- **Built-in Mode (Default)**: Uses the skill's high-fidelity `v1beta1` library (300+ Anthos constraints).
  - `Usage: ./scripts/vet-policy.sh <manifest-path>`
- **Remote Mode**: Clones and vets against an external Git repository.
  - `Usage: ./scripts/vet-policy.sh <manifest-path> <repo-url> [git-ref]`
  - ⚠️ **Note**: External libraries like the legacy GCP Policy Library may be out-of-date and cause schema validation errors with modern `gator`.
- **Local Mode**: Vets against a local directory of policies.
  - `Usage: ./scripts/vet-policy.sh <manifest-path> /path/to/local/policies`

**Interaction Model:**

1. Call `./scripts/vet-policy.sh` with the appropriate arguments.
2. Interpret the `=== KCC Best Practices ===` and `=== OPA/Gatekeeper ===` reports.
3. Supplement automated findings with manual review for specific security features not yet covered by OPA (e.g., `publicAccessPrevention: enforced`, `versioning: {enabled: true}`).

  ```bash
  # Run the skill's helper script (repo URL and branch are optional)
  ./scripts/vet-policy.sh manifest.yaml [policy-repo-url] [policy-ref]
  ```

## Skill Assets

This skill includes additional resources to streamline operations:

- **`scripts/`**: Automation scripts (e.g., `vet-policy.sh`, `bulk-export.sh`).
- **`examples/`**: Reference KCC manifests (e.g., `restricted-bucket.yaml`).
- **`resources/`**: Common templates, documentation snippets, and troubleshooting guides (e.g., `troubleshooting-guide.md`).

### 4. Safety Rails for Applying Manifests

Before applying any KCC manifest update to an existing resource, you MUST:

- **Verify Immutable Fields**: Call `./scripts/verify-immutable.sh <manifest-path>` to detect updates to fields (like `location`, `name`, `project-id`) that trigger destructive resource recreation.
- **Explain Impact**: If destructive changes are detected, you MUST warn the user and explain the downtime/data loss implications before requesting approval.

### 5. Emergency Recovery & Troubleshooting

If a resource is stuck in a "Deletion" or "Error" state:

- **Check for Abondon Flag**: Check if the resource has the `cnrm.cloud.google.com/deletion-policy: abandon` annotation. If it does, you will need to remove the annotation and then force delete the resource.
- **Force Delete**: Call `./scripts/force-delete.sh <kind> <name> [namespace]` to bypass Kubernetes finalizers and remove the resource from the cluster.
- **Orphan Warning**: Inform the user that force-deleting a KCC object may leave an orphaned resource in Google Cloud that requires manual cleanup.

### 6. Change Differentiation

When editing an existing resource, always generate a diff to summarize the change for reviewers or Git history:

- **Local Diff**:

  ```bash
  # Diff a local file against the cluster state
  kubectl diff -f modified-resource.yaml
  ```

- **Commit Summary Template**:

  ```text
  [KCC Change] Update <ResourceName> (<Kind>)
  - Field 'spec.foo' changed from 'X' to 'Y'
  - Impact: Ancillary service <ServiceName> will see updated <Config>
  ```

### 9. Best Practices

- **Namespaced Mode**: Prefer namespaced mode for better isolation.
- **Sensitive Data**: Use `spec.credential.secretRef` or similar for sensitive fields.
- **Resource Naming**: Use consistent naming conventions that match your Kubernetes/GCP standards.
- **Annotations**:
  - `cnrm.cloud.google.com/deletion-policy: abandon`: Keep GCP resource on KCC deletion.
  - `cnrm.cloud.google.com/state-into-spec: absent`: Prevents KCC from syncing GCP state back into the Kubernetes object (useful for avoiding reconciliation loops on fields like node counts).

## Common Resource Examples

### Compute Instance

```yaml
apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeInstance
metadata:
  name: instance-sample
  annotations:
    cnrm.cloud.google.com/project-id: "my-project-id"
spec:
  machineType: n1-standard-1
  zone: us-central1-a
  bootDisk:
    initializeParams:
      sourceImage: projects/debian-cloud/global/images/family/debian-11
  networkInterface:
    - networkRef:
        name: default
```

### Storage Bucket

```yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: bucket-sample
spec:
  location: US
```

### Pub/Sub Topic & Subscription

```yaml
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
  name: order-events-topic
---
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubSubscription
metadata:
  name: order-processor-sub
spec:
  topicRef:
    name: order-events-topic
  ackDeadlineSeconds: 30
```

ステップ 3: インベントリツールを実装する

.agents/skills/kcc-ops/scripts/inventory.sh を作成して、KCC リソースを検出します。

#!/bin/bash
# List all resources in the cnrm.cloud.google.com group
KCC_KINDS=$(kubectl api-resources --no-headers | awk '/\.cnrm\.cloud\.google\.com/ {print $1}')
KCC_KINDS_CSV=$(echo "$KCC_KINDS" | paste -sd, -)

printf "%-40s %-30s %-10s %s\n" "KIND" "NAME" "READY" "STATUS/MESSAGE"
kubectl get "$KCC_KINDS_CSV" -A -o custom-columns="KIND:.kind,NAME:.metadata.name,READY:.status.conditions[?(@.type=='Ready')].status,MSG:.status.conditions[?(@.type=='Ready')].message" --ignore-not-found --no-headers

ステップ 4: ポリシーの審査ロジックを追加する

.agents/skills/kcc-ops/scripts/vet-policy.sh を作成します。このスクリプトは gator を使用して、OPA ポリシーに対してマニフェストを審査します。

#!/bin/bash
MANIFEST=$1
SKILL_ROOT=$(dirname "$(dirname "$0")")
POLICY_SRC="$SKILL_ROOT/resources/policies"

echo "=== OPA/Gatekeeper Policy Vetting ==="
if command -v gator >/dev/null 2>&1; then
    gator test -f "$MANIFEST" -f "$POLICY_SRC/templates" -f "$POLICY_SRC/constraints"
else
    echo "Gator not found. Skipping OPA audit."
fi

ステップ 5: 不変フィールド保護を実装する

これは重要な安全対策です。.agents/skills/kcc-ops/scripts/verify-immutable.sh を作成します。

#!/bin/bash
MANIFEST=$1
KIND=$(grep "^kind:" "$MANIFEST" | awk '{print $2}')
NAME=$(grep "name:" "$MANIFEST" | head -n 1 | awk '{print $2}')

# Check for changes in common immutable fields
IMMUTABLE_FIELDS=("location" "project-id" "name" "zone" "region")
TEMP_FILE=$(mktemp)
kubectl get "$KIND" "$NAME" -o yaml > "$TEMP_FILE" 2>/dev/null

for field in "${IMMUTABLE_FIELDS[@]}"; do
    NEW=$(grep "$field:" "$MANIFEST" | awk '{print $2}')
    OLD=$(grep "$field:" "$TEMP_FILE" | awk '{print $2}')
    if [ -n "$NEW" ] && [ -n "$OLD" ] && [ "$NEW" != "$OLD" ]; then
        echo "🚨 WARNING: Immutable field '$field' is changing! Potential resource recreation."
    fi
done
rm "$TEMP_FILE"

ステップ 6: 緊急復旧（強制削除）

.agents/skills/kcc-ops/scripts/force-delete.sh を作成します。

#!/bin/bash
KIND=$1; NAME=$2; NS=${3:-default}
echo "Removing finalizers for $KIND/$NAME in $NS..."
kubectl patch "$KIND" "$NAME" -n "$NS" -p '{"metadata":{"finalizers":null}}' --type=merge
kubectl delete "$KIND" "$NAME" -n "$NS" --wait=false

ステップ 7: リソースを確定する

すべてのスクリプトを実行可能にします。

chmod +x .agents/skills/kcc-ops/scripts/*.sh

10. 新しいスキルをテストする

新しい会話を開始して、スキルをテストします。

検出: @kcc-ops Show me all KCC resources in my cluster.
コンプライアンス: StorageBucket を使用してファイル bucket.yaml を作成します。質問: @kcc-ops Vet my bucket.yaml manifest.
安全性: 既存のバケットの location を bucket.yaml で更新してみます。質問: @kcc-ops Verify my bucket.yaml for immutable changes.

エージェントが正しいスクリプトをインテリジェントに選択し、SKILL.md の「ゴールデンルール」に従っていることを確認します。

11. エージェントを保護する

AI エージェントにターミナルへのアクセス権を付与することは強力ですが、制御が必要です。

Antigravity - Settings - Terminal に移動し、Allow List と Deny List を確認します。

許可リスト: ls、kubectl get、スキルスクリプトをここに追加します。
Deny List: sudo、rm -rf、その他の破壊的なコマンドを追加して、エージェントが常に権限を要求するようにします。

12. おわりに

おめでとうございます。Antigravity のインストールから、忠実度の高い KCC Operations スキル の構築まで完了しました。

学習内容は次のとおりです。

カスタム bash ツールを使用してエージェントを拡張する方法。
オペレーションの「ゴールデンルール」を SKILL.md にエンコードする方法。
複雑なインフラストラクチャ管理のための安全対策を提供する方法。

次のステップ

resources/policies フォルダに OPA 制約を追加するか、check-health.sh スクリプトを追加してクラスタの準備状況のチェックを自動化します。