Kubernetes Operator — detection

Declares when the k8s-operator profile activates on a given set of files. Consumed by klaude-plugin/skills/_shared/profile-detection.md. Detection is additive: an operator project typically activates both k8s-operator (for controller code) and k8s (for the manifests it generates/deploys).

Evaluation follows the shared cost-ordered procedure (path → filename → content). Authority runs filename ≈ content > path: filename or content signals activate the profile; path alone never does, it only promotes a file to a candidate.

Path signals

Case-insensitive substring match anywhere in the file's path. Pre-filter only — a path hit alone does NOT activate the profile.

• internal/controller/
• api/
• controllers/

Filename signals

Authoritative: any match activates the profile. Filename matches short-circuit content inspection for the matched file.

• PROJECT (exact) → kubebuilder project marker. This file is generated by kubebuilder init and contains the project's domain, layout, and plugin metadata. Its mere presence signals an operator project.
• Any file under config/crd/ → CRD kustomize bases generated by controller-gen.
• Any file under config/webhook/ → admission/conversion webhook kustomize configuration.

Content signals

Authoritative for files not already caught by a filename signal. Inspection is bounded to the first ~16 KB per file.

• A Makefile containing the literal string controller-gen OR a target named manifests (line starting with manifests:) → kubebuilder/operator-sdk generated Makefile with CRD/RBAC generation targets.
• A Go source file (.go extension) containing an import of sigs.k8s.io/controller-runtime → controller-runtime dependency, the standard library for writing Kubernetes controllers.

Design signals

display_name: Kubernetes Operator tokens:

• operator
• controller
• kubebuilder
• controller-runtime
• CRD authoring
• custom resource definition authoring
• reconciliation loop