fix: Remove internal name

Change-Id: I0426d093d7dd4c69d4beaba476a01d2613c62137
GitOrigin-RevId: fd04d82ed31cef86831970fe5af3a804998304e1

Author: aburhan

projects/gemini-powered-migrations-to-google-cloud/.gemini/commands/aws-container-migration-analysis.toml

@@ -1,54 +1,54 @@
-description = "Analyzes KubeScan inventory data to assess EKS workloads for migration to Google Kubernetes Engine (GKE)."
+description = "Analyzes Kubernetes clusters and objects inventory data to assess Amazon EKS workloads for migration to Google Kubernetes Engine (GKE)."
 
 prompt = '''
-You are a Senior Cloud Migration Architect specializing in AWS to Google Cloud migrations. Your task is to analyze KubeScan assessment data (JSON and CSV files) and generate a strategic migration assessment for moving EKS workloads to GKE Autopilot.
-Review the EKS cluster inventory files provided in the folder defined by "{{args}}" and help identify stateless workloads suitable for a direct "lift-and-shift" versus stateful workloads requiring database migration.
+You are a Senior Cloud Migration Architect specializing in AWS to Google Cloud migrations. Your task is to analyze Kubernetes clusters and objects data (JSON and CSV files) and generate a strategic migration assessment for moving Amazon EKS workloads to GKE.
+Review the Amazon EKS cluster inventory files in the {{args}} directory, and help identify stateless workloads suitable for a direct "lift-and-shift" versus stateful workloads requiring data migration (e.g., from databases, persistent volumes, or object storage).
 
-## EKS Workload Assessment Rules
+## Amazon EKS Workload Assessment Rules
 
 **1. Workload Type (The "State" of the Pod):**
 * **Stateless**: Workloads that do NOT use PersistentVolumeClaims (PVCs). These are "Lift and Shift" candidates.
 * **Stateful**: Workloads that mount PVCs (e.g., EBS volumes). These require complex migration (e.g., using StatefulSets or migrating data to Cloud Storage).
 
 **2. Dependencies (External Data):**
-* **External Database**: Workloads connecting to RDS/ElastiCache. The *workload* remains Stateless, but the *database* requires a separate migration path (DMS).
+* **External Database**: Workloads connecting to Amazon RDS/ElastiCache. The *workload* remains Stateless, but the *database* requires a separate migration path (DMS).
 * **Self-Hosted Data**: Workloads hosting their own DB (StatefulSet + PVC).
 
 **3. Network Strategy:**
 * Identify AWS annotations (e.g., `service.beta.kubernetes.io/aws-load-balancer`) that need refactoring to GKE Ingress.
 
 ## Your Process
 
-- Thoroughly examine files in the provided folder (`{{args}}`) that contains information about EKS workloads (specifically `workloads.csv`, `pods.csv`, `configmaps.csv`, `services.csv`, and `eks_data.json`).
-- If you think that some assessment data is missing, examine all the files in the provided folder to check if it contains that missing data.
-- List all analyzed workloads in the EKS Cluster Analysis Summary and use emojis as complexity indicators (🟢 Simple/Stateless, 🟡 Moderate/Config Changes, 🔴 Complex/Stateful).
+- Thoroughly examine files in the provided folder (`{{args}}`) that contains information about Amazon EKS workloads (specifically `workloads.csv`, `pods.csv`, `configmaps.csv`, `services.csv`, and `eks_data.json`).
+- If you think that some assessment data is missing, warn the customer that the data is incomplete and describe what is missing and the impact that will have on the output.
+- List all analyzed workloads in the Amazon EKS Cluster Analysis Summary and use emojis as complexity indicators (🟢 Simple/Stateless, 🟡 Moderate/Config Changes, 🔴 Complex/Stateful).
 
 ### 2. Analysis & Reasoning
 
 Document your findings by explaining:
 
 - What you discovered from files inspection
 - Which workloads are strictly stateless vs. stateful.
-- Specific AWS dependencies found (e.g., "Found RDS endpoint in ConfigMap 'backend-config'").
+- Specific AWS dependencies found (e.g., "Found Amazon RDS endpoint in ConfigMap 'backend-config'").
 - Networking changes required (e.g., "Service 'frontend' uses Classic ELB annotations").
 
 ### 3. Plan Creation
 
 ## Output Format for `eks-migration-assessments/[plan_name].md`
 
-**Note: Please strictly follow Markdown format for the entire output.**
-
 You **MUST** format the contents of `eks-migration-assessments/[plan_name].md` exactly as follows:
 
 - Use markdown.
 - The plan name should be short and descriptive, also make sure it can be used as a filename.
 
+Output Example:
+
 ```markdown
-# EKS Migration Assessment: [plan_name]
+# Amazon EKS Migration Assessment: [plan_name]
 
-## Current date and time
+[Current date and time]
 
-## EKS Cluster Analysis Summary:
+## Amazon EKS Cluster Analysis Summary:
 
 Table with columns:
 
@@ -58,11 +58,11 @@ Workload Name │ Namespace │ Type (Stateless/Stateful) │ External Dependenc
 
 **Infrastructure Provisioning:**
 * Recommended GKE Cluster Mode (Autopilot/Standard) based on node analysis.
-* Recommended Cloud SQL sizing based on detected RDS connections.
+* Recommended Cloud SQL sizing based on detected Amazon RDS connections.
 
 **Workload Strategy:**
 * **Stateless Workloads (Lift & Shift)**: List workloads ready for immediate redeployment.
-* **Data Migration (External Dependencies)**: Identify workloads dependent on RDS and define the DMS strategy.
+* **Data Migration (External Dependencies)**: Identify workloads dependent on Amazon RDS and define the DMS strategy.
 * **Stateful Workloads (Refactoring Required)**: Identify workloads using PVCs that require storage migration.
 
 **Missing Data / Assumptions:**

projects/gemini-powered-migrations-to-google-cloud/README.md

@@ -27,14 +27,23 @@ The following custom commands are configured in this project under
 The custom commands in this section are aimed at helping you accelerate the
 evaluation.
 
-- **aws-container-migration-analysis:** This command analyzes KubeScan inventory
-  files to categorize Amazon EKS workloads and generate a Google Kubernetes
-  Engine (GKE) migration plan. To run this command, you must first generate
-  kubescan output files
-  [Kubescan](https://github.com/GoogleCloudPlatform/professional-services/blob/main/tools/k8s-discovery/README.md).
+- **aws-container-migration-analysis:** This command analyzes cluster and object
+  inventory files from Amazon EKS workloads to generate a Google Kubernetes
+  Engine (GKE) migration plan. The command expects a path to the directory
+  containing the inventory output files. You must first generate these files
+  using the
+  [Kubernetes Cluster Discovery Tool](https://github.com/GoogleCloudPlatform/professional-services/blob/main/tools/k8s-discovery/README.md).
+
+    **Usage:**
+
+    ```sh
+    /aws-container-migration-analysis [PATH/TO/KUBERNETES_INVENTORY/DIRECTORY]
+    ```
+
+    **Usage (Try with Sample Data):**
 
     ```sh
-    /aws-container-migration-analysis review files in test-data/aws-container-migration-analysis
+    /aws-container-migration-analysis test-data/aws-container-migration-analysis
     ```
 
 - **/aws-lambda-to-cloud-run-poc-selection:** This command assists in reviewing
@@ -128,8 +137,8 @@ outputs and are used by the custom Gemini CLI commands to demonstrate the
 migration selection process without requiring actual cloud environments. This
 data includes:
 
-- **`aws-container-migration-analysis/`**: Contains mock KubeScan inventory
-  files for Amazon EKS workloads.
+- **`aws-container-migration-analysis/`**: Contains mock Kubernetes clusters and
+  objects inventory files for Amazon EKS workloads.
 - **`aws-lambda-assessment-results/`**: Contains mock data for AWS Lambda
   functions.
 - **`aws-s3-assessment-results/`**: Contains mock data for S3 bucket locations,

projects/gemini-powered-migrations-to-google-cloud/test-data/sample-selection/aws-container-migration-analysis.md

@@ -1,30 +1,30 @@
-# AWS EKS Migration Assessment
+# Amazon EKS Migration Assessment
 
-## EKS Cluster Analysis Summary
+## Amazon EKS Cluster Analysis Summary
 
 | Workload Name      | Namespace | Type (Stateless/Stateful) | External Dependencies (DB/Cache) | Complexity  | Migration Action                  |
 | ------------------ | --------- | ------------------------- | -------------------------------- | ----------- | --------------------------------- |
-| balancereader      | default   | Stateless                 | PostgreSQL (Assumed RDS)         | 🟡 Moderate | Lift & Shift, Reconfigure DB      |
+| balancereader      | default   | Stateless                 | PostgreSQL (Assumed Amazon RDS)  | 🟡 Moderate | Lift & Shift, Reconfigure DB      |
 | contacts           | default   | Stateless                 | Not specified                    | 🟢 Simple   | Lift & Shift                      |
 | frontend           | default   | Stateless                 | Not specified                    | 🟡 Moderate | Lift & Shift, Reconfigure Ingress |
-| ledgerwriter       | default   | Stateless                 | PostgreSQL (Assumed RDS)         | 🟡 Moderate | Lift & Shift, Reconfigure DB      |
+| ledgerwriter       | default   | Stateless                 | PostgreSQL (Assumed Amazon RDS)  | 🟡 Moderate | Lift & Shift, Reconfigure DB      |
 | loadgenerator      | default   | Stateless                 | Not specified                    | 🟢 Simple   | Lift & Shift                      |
-| transactionhistory | default   | Stateless                 | PostgreSQL (Assumed RDS)         | 🟡 Moderate | Lift & Shift, Reconfigure DB      |
+| transactionhistory | default   | Stateless                 | PostgreSQL (Assumed Amazon RDS)  | 🟡 Moderate | Lift & Shift, Reconfigure DB      |
 | userservice        | default   | Stateless                 | Not specified                    | 🟢 Simple   | Lift & Shift                      |
 
 ## Recommendations for GKE Migration
 
 **Infrastructure Provisioning:**
 
 - **Recommended GKE Cluster Mode:** GKE Autopilot is highly recommended. The
-  current EKS cluster has a single worker node, which indicates that the
+  current Amazon EKS cluster has a single worker node, which indicates that the
   workloads are not resource-intensive. GKE Autopilot will provide a hands-off
   operational experience by managing the underlying nodes automatically.
 - **Recommended Cloud SQL sizing:** Based on the presence of PostgreSQL
   connection strings in the ConfigMaps, it is recommended to provision a Cloud
   SQL for PostgreSQL instance. The size should be determined after a performance
-  baseline analysis of the source RDS instance. A good starting point would be a
-  `db-n1-standard-2` instance.
+  baseline analysis of the source Amazon RDS instance. A good starting point
+  would be a `db-n1-standard-2` instance.
 
 **Workload Strategy:**