Menu
Base skill containing shared standards for all KCC direct resource types (both greenfield and brownfield).
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
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-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: The file must start with // Copyright 2026 Google LLC.
CRD Labels: Include at least these two labels in the type definition:
// +kubebuilder:metadata:labels="cnrm.cloud.google.com/managed-by-kcc=true"
// +kubebuilder:metadata:labels="cnrm.cloud.google.com/system=true"
(Note: See greenfield/brownfield skills for the correct stability-level label to append.)
Status Fields: status.observedGeneration must be exactly *int64.
Reference Fields: Ensure that fields referencing other GCP/KCC resources are implemented as proper KCC reference fields (e.g., using 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.
Reference Types Location: Whenever a reference type (e.g. <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.
KCC Proto Annotations:
To enable auto-generation of mappers, you must add the correct "kcc:proto" annotations to Go structs in _types.go:
// +kcc:spec:proto=<proto_type> (e.g. // +kcc:spec:proto=google.cloud.compute.v1.ServiceAttachment).// +kcc:observedstate:proto=<proto_type>.// +kcc:status:proto=<proto_type>.// +kcc:proto=<proto_sub_type> (e.g. // +kcc:proto=google.cloud.compute.v1.ServiceAttachmentConnectedEndpoint).