reviewgen-brownfield-new-types

Reviews pull requests adding new KCC types for Brownfield GCP resources against defined criteria.

1.1k|377|Updated Apr 8, 2019
One-click install
npx skills add https://github.com/GoogleCloudPlatform/k8s-config-connector --skill reviewgen-brownfield-new-types
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: reviewgen-brownfield-new-types
Source: https://github.com/GoogleCloudPlatform/k8s-config-connector/tree/main/.gemini/skills/reviewgen-brownfield-new-types
Command: npx skills add https://github.com/GoogleCloudPlatform/k8s-config-connector --skill reviewgen-brownfield-new-types

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Reviewing pull requests that add new Kubernetes Resource Model types for Brownfield GCP resources in Config Connector requires checking many invariants manually, which is error-prone and inconsistent across reviewers.

Core Features & Use Cases

  • Structured Review Criteria: Enforces checks for API versioning, copyright years, Go pointer rules for optional primitives, and resource reference mappings.
  • Schema Compatibility Validation: Verifies no breaking CRD schema changes versus the master branch using the diff-crds task, with parity-over-completeness rules for proto-to-CRD mapping.
  • Standardized Review Output: Produces a consistent KCC Auto-Review Results comment template with pass/fail status per criterion.
  • Use Case: When a contributor opens a PR migrating an existing GCP resource to the direct controller approach, apply these criteria to confirm v1beta1 versioning, pointer correctness, and zero schema drift before approving.

Quick Start

Review this pull request that adds a new Brownfield KCC type using the Brownfield review criteria and report the results.

Frequently Asked Questions about reviewgen-brownfield-new-types

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a PR adding new KCC Brownfield types?

Check API versioning (v1beta1 in apis/<group>/<version>/), copyright year 2026 on new files, pointer rules for optional Go primitives, reference structs for GCP identifiers, and schema parity with the master branch CRD. Report results using the KCC Auto-Review Results template.

How to verify CRD schema compatibility against the master branch?

Run ./dev/tasks/diff-crds --base master from the repository root. Any added or removed fields under spec or status fail the review, except removal of the boilerplate top-level status block with acceptedNames and storedVersions.

When should Go fields be pointers in KCC types?

Optional scalar primitives like string, bool, int, int32, int64, and float64 must be pointers, while required scalars stay as values. Slices and maps must never be pointers, so *[]string and *map[string]string are not allowed.

Does Brownfield migration allow adding new proto fields to the CRD?

No. Brownfield migration requires strict schema parity with the existing master branch CRD, so proto fields not already present must not be added. OUTPUT_ONLY proto fields map only to status, and other fields map to spec.

What copyright year is required for new files in KCC PRs?

All new .go and .sh files must carry a copyright header with the year 2026. Copyright years on existing files must not be modified during the review.