Menu
Guides the implementation of KRM types and CRD scaffolding for migrating existing resources to "direct" controllers.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Automate the initial scaffolding of a KCC "direct" resource, including CRD types and generation scripts. Use this when starting a new "direct" implementation for a GCP resource.
Creates or updates the _identity.go and _reference.go files for a Config Connector resource, ensuring they follow the canonical gcpurls.Template pattern. Use this when you need to make sure the identity and reference is up to date for a KCC resource or when implementing IdentityV2 and refs.Ref for a resource.
Standards and workflows for creating direct KRM Go types for an existing CRD while maintaining strict schema compatibility.
Comprehensive review guide and criteria for PRs adding or modifying features in legacy resources (TF patches, DCL patches, CRD changes, MockGCP alignment, and Direct Controller alignment).
Implement the controller, mappers, and fuzzer for a direct KCC resource, ensuring package isolation and CI compliance. Use this when implementing the main reconciliation logic for a "direct" resource.
Guides modifying, patching, and updating resources and fields managed by the Terraform/legacy controller, including patching the local/vendored Terraform Google Beta provider.
| name | kcc-direct-brownfield-types-implementer |
| description | Guides the implementation of KRM types and CRD scaffolding for migrating existing resources to "direct" controllers. |
This skill provides the mandatory standards for creating the initial KRM types (_types.go) and generation scripts (generate.sh) when migrating an existing (brownfield) resource to the direct controller approach.
Create or update apis/<service>/v1alpha1/generate.sh. Use a versioned proto source path to ensure stability.
#!/bin/bash
set -o errexit
set -o nounset
set -o pipefail
REPO_ROOT="$(git rev-parse --show-toplevel)"
cd ${REPO_ROOT}/dev/tools/controllerbuilder
# Use the pinned SHA from apis/git.versions or a specific override
PROTO_SHA="<sha>"
PROTO_OUT="${REPO_ROOT}/.build/googleapis-${PROTO_SHA}.pb"
./generate-proto.sh ${PROTO_SHA} ${PROTO_OUT}
go run . generate-types \
--service <proto.package> \
--api-version <service>.cnrm.cloud.google.com/v1alpha1 \
--resource <Kind>:<ProtoMessage> \
--proto-source-path ${PROTO_OUT}
After running the generator, verify the _types.go file meets these requirements:
// Copyright 2026 Google LLC.// +kubebuilder:metadata:labels="cnrm.cloud.google.com/managed-by-kcc=true"
// +kubebuilder:metadata:labels="cnrm.cloud.google.com/system=true"
// +kubebuilder:metadata:labels="cnrm.cloud.google.com/stability-level=alpha"
+kcc:proto tags are present on the Spec and ObservedState structs to link them to the GCP API definitions.status.observedGeneration must be an *int64.apis/refs/ instead of hand-coding or defining duplicate types.
ProjectRef (which lives in apis/refs/v1beta1/project_ref.go) and other resource reference types should be imported from github.com/GoogleCloudPlatform/k8s-config-connector/apis/refs/v1beta1 rather than being defined locally in <kind>_types.go.externalRef or observedState under Status yet.dev/tasks/diff-crds to verify schema compatibility and ensure no unintended new fields are introduced.kcc-direct-controller-implementer skill for details on implementing fuzzers.apis/<service>/v1alpha1/register.go.dev/tasks/generate-crds and verify the YAML appears in config/crds/resources/.