Menu
Base skill containing shared standards for all KCC direct resource types (both greenfield and brownfield).
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
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.
Standards and workflows for creating direct KRM Go types for an existing CRD while maintaining strict schema compatibility.
Guides the implementation of export support for a direct controller, including implementing AdapterForURL and verifying it through the unified test runner.
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.
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-base-types-implementer |
| description | Base skill containing shared standards for all KCC direct resource types (both greenfield and brownfield). |
This skill provides the mandatory baseline standards that apply to all new KRM types (_types.go) for direct resources in Config Connector, regardless of whether they are greenfield or brownfield migrations.
After running the generator (via generate.sh), you must verify and enforce the following baseline requirements on the resulting _types.go file:
// Copyright 2026 Google LLC.// +kubebuilder:metadata:labels="cnrm.cloud.google.com/managed-by-kcc=true"
// +kubebuilder:metadata:labels="cnrm.cloud.google.com/system=true"
stability-level label to append.)status.observedGeneration must be exactly *int64.pubsubv1beta1.PubSubTopicRef or refsv1beta1.KMSCryptoKeyRef), following the Ref suffix naming convention. You MUST NOT add new exceptions to tests/apichecks/testdata/exceptions/missingrefs.txt. All reference-like fields must be implemented as proper references.<Kind>Ref implementing refsv1beta1.Ref) is needed, it must always be defined and implemented in its own separate file named <kind>_reference.go (e.g., filestorebackup_reference.go) rather than inside _types.go. This keeps the main type definitions clean and isolated from reference resolution boilerplate.