Add operator-api-standards Claude Code skill

[Brian-McM]

Description

Adds a project-scoped Claude Code skill that guides contributors on conventions and dos/don'ts when adding or changing CRD types under api/v1/.

The skill distills the rationale already captured in docs/principles.md ("API Design", "Respect User Input", "Resource Ownership") and docs/dev_guidelines.md ("API code") into concrete, checkable rules, and pairs them with the repo's actual kubebuilder/Go coding conventions observed across the existing *_types.go files:

• Design rules: minimal API surface, declarative convergence, kubebuilder-over-reconcile-loop defaulting/validation, every-container-needs-overrides, backward compatibility.
• Respect user input: never overwrite/delete user fields or resources, error don't guess, no OwnerRefs on user-provided resources.
• Coding conventions: pointer + omitempty + +optional for optional fields, the Enabled/Disabled enum idiom over *bool, CEL MaxLength/MaxItems bounds and the single-quote gotcha, the top-level Kind marker block + List + init() registration, copyright header, shared-type reuse.
• Deployment/container override pattern modeled on whisker_deployment_types.go.
• Required post-change workflow: make gen-files, cluster-scope check, convert package, pkg/common/validation, make dirty-check.
• A copy-paste checklist for adding a new field.

It auto-triggers whenever a contributor (using Claude Code) edits files under api/v1/, so the guidance surfaces at the moment it's relevant.

For PR author

• Added or updated tests for any new code (n/a — docs/tooling only)
• If changing programmatic behavior of the operator, my commit message explains what behavior changed (n/a)

For PR reviewers

This is purely additive (a new .claude/skills/ markdown file); no operator behavior changes. Feedback welcome on the conventions themselves — whether anything is inaccurate, missing, or too prescriptive.

🤖 Generated with Claude Code