Improve skills from eval feedback

skills/google-cicd-deploy/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: google-cicd-deploy
-description: Deploy an application to Google Cloud. Use when the user wants to deploy a new application on GCP.
+description: >
+  Use this skill when requested to deploy an application to Google Cloud (GCS, Cloud Run, GKE) or when analyzing an application to determine the best deployment target.
+  **Why**: This skill enforces mandatory security protocols, specifically secret scanning, and guides the selection of the optimal deployment workflow, preventing security risks and inefficient resource use. Activation ensures compliance with these standards and best practices.
 ---
 
 # Google Cloud CI/CD Assistant
@@ -68,7 +70,9 @@ Your job is to deploy the user's applications to Cloud Run from an image.
 1.  **Create Dockerfile**: If a Dockerfile does not already exist, consult the `references/how_to_write_dockerfile.md` guide to create a multistage, production-grade Dockerfile tailored to the project's archetype. Analyze port, environmental variables etc and setup the Dockerfile in a way that it works. Ensure the Dockerfile can be built locally using the Docker cli.
 2.  **Gather Parameters**: Analyze the request to find all necessary parameters to create an Artifact Registry repository and build and push the Docker image. If any mandatory parameters are missing, you MUST ask the user for them before proceeding. Do not guess or make assumptions.
 3.  **Create Artifact Registry Repository** Create the Artifact Registry repository using the `create_artifact_repository` tool.
-4.  **Build and Push Image**: Using the Docker cli, build the Docker image locally using the created Dockerfile and push the image to the created Artifact Registry repository.
+4.  **Build and Push Image**: Build the Docker image and push it to the created Artifact Registry repository.
+    *   **Preferred**: Use the Docker CLI to build the image locally and push it.
+    *   **Fallback**: If a local Docker daemon is not available or the build fails, use Google Cloud Build to build the image remotely. Run the command: `gcloud builds submit --tag <IMAGE_URI> .` in the project root.
 5.  **Gather Parameters**: Analyze the request to find all necessary parameters to deploy to Google Cloud Run(e.g., `repo_name: "my-app-images"`).
 6.  **Clarify if Needed**: If any mandatory parameters are missing to deploy to Google Cloud Run, you MUST ask the user for them before proceeding. Do not guess or make assumptions. Ask the user if they would like to create a public or private service if not specified.
 7.  **Deploy**: Deploy the built application to Google Cloud Run using the `deploy_cloudrun_service_from_image` tool and return the URL of the deployed application.
@@ -95,7 +99,7 @@ This workflow is for deploying container-based applications to a GKE cluster. Co
 
 These rules apply to all workflows.
 
-Always scan for secrets before uploading anything to docker or GCS using the `scan_code_for_secrets` tool. Always ignore directories where scanning is not useful e.g. dependencies which the user has no control over e.g. .venv or go_modules etc. Warn the user of any secrets available and ask if the user wants to ignore these files using dockerignore and gitignore. If they would like to ignore the files, create the corresponding dockerignore and gitignore files. Goal of scanning is to detect if the user inadvertently uploaded any secrets in *their* application code.
+Always scan for secrets before any build or deployment operation (including building Docker images or uploading files to GCS) using the `scan_code_for_secrets` tool. Always ignore directories where scanning is not useful e.g. dependencies which the user has no control over e.g. .venv or go_modules etc. Warn the user of any secrets available and ask if the user wants to ignore these files using dockerignore and gitignore. If they would like to ignore the files, create the corresponding dockerignore and gitignore files. Goal of scanning is to detect if the user inadvertently uploaded any secrets in *their* application code.
 First, analyze the user's application to determine the type of application. Proceed to the workflow only after analyzing the application.
 
 ### **Error Handling Protocol**

skills/google-cicd-pipeline-design/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: google-cicd-pipeline-design
-description: Design and implement a Google Cloud based CI/CD pipeline. Use when the user wants to build a new pipeline, design an architecture on GCP.
+description: Use this skill to design and implement a Google Cloud based CI/CD pipeline. This skill encodes best practices for pipeline design, ensuring proper pattern selection and implementation. You MUST activate this skill when tasked with building a pipeline, designing architecture on GCP, or migrating pipelines.
 ---
 
 # Google Cloud CI/CD Assistant

skills/google-cicd-release-orchestration/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: google-cicd-release-orchestration
 description: >
-  Design Cloud Deploy delivery pipelines and manage releases when deploying applications to Cloud Run and Google Kubernetes Engine (GKE). Use when users want to deploy their applications to multiple environments (e.g. dev and prod), leverage deployment strategies (i.e. canary), or rollback (manually or automatically) when there are issues deploying their application.
+  Use this skill when you need to design Cloud Deploy delivery pipelines or manage releases for applications deploying to Cloud Run or Google Kubernetes Engine (GKE). This skill encodes best practices for multi-environment deployment, deployment strategies (like canary), and release management (including rollbacks and automations). Always activate this skill for these tasks to ensure robust and consistent configuration.
 version: "0.1.0"
 ---
 
@@ -39,7 +39,7 @@ This workflow provides steps for designing a Cloud Deploy `DeliveryPipeline`.
 2. Identify if promotions should require user approval.
 3. Define each of the deployment environments as Cloud Deploy `Target` resources in a `clouddeploy.yaml` file. 
     - Use `references/configure-targets.md` as a reference when generating the resource YAML.
-    - Use the application name provided by the user when naming the Cloud Deploy `Target` resources. For example, if the user wants to deploy an application named "hello-world" to a test and production environment then use "hello-world-test" and "hello-world-prod" as the `Target` IDs.
+    - Always prefix target IDs with the application name provided by the user (e.g., `[app-name]-[env]`) to prevent resource name collisions when multiple applications are deployed to different environments. For example, if the user wants to deploy an application named "hello-world" to test and prod environments, then use "hello-world-test" and "hello-world-prod" as the `Target` IDs.
 
 ### Step 2: Define the delivery pipeline
 
@@ -79,6 +79,7 @@ gcloud deploy apply --file=clouddeploy.yaml --region=<REGION> --project=<PROJECT
     - **If GKE**: Generate a Kubernetes `Deployment` and `Service`manifest. Use `references/basic-k8s-manifests.md` as a reference.
 2. Create a `skaffold.yaml` file required to create a Cloud Deploy `Release` for the `DeliveryPipeline`.
     - Use `references/configure-skaffold.md` as a reference when generating the `skaffold.yaml` file.
+    - **For multi-environment pipelines**: You must define a Skaffold profile for each Cloud Deploy target environment, named to match the target ID exactly. Do NOT use generic names like 'staging' or 'prod' for profile names unless they match the target IDs.
 
 
 ### Step 7: Setup IAM permissions

skills/google-cicd-terraform/SKILL.md

@@ -1,7 +1,6 @@
 ---
 name: google-cicd-terraform
-description: "Architect, provision, and troubleshoot production-grade Google Cloud infrastructure using Terraform and OpenTofu. Use to design landing zones (Shared VPCs, Folders), deploy core services (GKE, Cloud Run, Cloud SQL), implement IAM least-privilege, and manage GCS-backed state. Enforces Google’s Cloud Foundation Fabric patterns and rigorous validation protocols to ensure secure, idempotent, and scalable deployments across environments."
-version: "0.1.0"
+description: Architect, provision, and troubleshoot infrastructure on Google Cloud using Terraform. This skill ensures best practices like GCS backend usage and least-privilege IAM are followed. Enforces Google’s Cloud Foundation Fabric patterns and rigorous validation protocols to ensure secure, idempotent, and scalable deployments across environments. Activate when the user requests infrastructure changes, pipeline design involving Terraform, or debugging Terraform issues.
 ---
 
 # Terraform GCP Skill
@@ -147,6 +146,18 @@ To maintain a clean module interface, use the main identifier for singleton reso
     }
     ```
 
+5. Developer Connect Git Repository Link
+   When configuring `google_developer_connect_git_repository_link`, use `parent_connection` and `git_repository_link_id` as required arguments.
+
+    ```hcl
+    resource "google_developer_connect_git_repository_link" "main" {
+      location                = var.region
+      parent_connection       = google_developer_connect_connection.main.connection_id
+      git_repository_link_id  = "my-repo-link"
+      clone_uri               = var.github_repo_uri
+    }
+    ```
+
 ## 📂 Directory Structure
 Follow this standard to ensure compatibility with Antigravity (AGY) discovery and Google best practices:
 
@@ -165,6 +176,8 @@ Follow this standard to ensure compatibility with Antigravity (AGY) discovery an
     └── helpers/             # Scripts NOT called by Terraform
 ```
 ## ⚠️ Anti-Patterns (Do NOT do these)
+   - ❌ Legacy GitHub Triggers: Do not use the legacy `github` block in `google_cloudbuild_trigger`. Always use `developer_connect_event_config`.
+
    - ❌ Hardcoded IDs: Never hardcode Project IDs. Use variables or data "google_project" sources.
 
    - ❌ Service Account Keys: Never generate or store .json keys. Use Workload Identity Federation or the default metadata server.