operator-api-standards

Sterne215

Forks157

Aktualisiert18. Juni 2026 um 16:29

Standards, conventions, and dos/don'ts for adding or changing CRD types in the tigera/operator API (api/v1). Use this skill whenever editing or creating files under api/v1/ (any *_types.go), adding/removing/renaming a CRD field, introducing a new Kind/CRD, adding kubebuilder validation or defaulting markers, or designing an overrides/configuration field. Trigger even if the user doesn't mention "standards" — any change to operator CRD types should follow these conventions.

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

tigera

tigera/operator

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

name

operator-api-standards

description

Operator API Standards

When adding or changing CRD types under api/v1/:

Read docs/api_design.md — the API design principles plus the concrete Go/kubebuilder coding conventions (optional vs required fields, the Enabled/Disabled enum idiom, validation/CEL markers, the top-level Kind marker block, shared-type reuse, the Deployment override pattern) and the end-of-file checklist. Apply all of it, and run the checklist before you finish.
Read docs/principles.md for related rules ("Respect User Input", "Resource Ownership") when a judgement call isn't settled by api_design.md.
Follow the post-change workflow in docs/dev_guidelines.md — make gen-files, verify scope didn't flip to Namespaced, update convert if relevant, and make dirty-check.

Mehr aus diesem Repository

gleiches Repository

pr-template

tigera/operator

Use whenever creating a pull request in this repo (gh pr create, opening a PR, drafting a PR body). The repo requires every PR body to follow .github/PULL_REQUEST_TEMPLATE.md. When creating a PR, ask the user whether they want a release note. Trigger even if the user does not explicitly mention the template.

2026-06-16215

operator-versioning

tigera/operator

Map between Calico/enterprise versions and tigera/operator release branches. Use this skill whenever you need to determine which operator branch corresponds to a Calico or enterprise release (e.g., "which operator branch is Calico v3.30?"), or the reverse (e.g., "what Calico version does release-v1.40 ship?"). Also use this skill whenever cherry-picking to operator release branches, creating cherry-pick PRs targeting release branches, or any task that requires knowing the operator↔Calico version relationship. Trigger even if the user doesn't explicitly ask about versioning — if the task involves targeting an operator release branch by Calico version, use this skill to find the right branch.

2026-03-13215

name

operator-api-standards

description

Operator API Standards

When adding or changing CRD types under api/v1/:

Read docs/api_design.md — the API design principles plus the concrete Go/kubebuilder coding conventions (optional vs required fields, the Enabled/Disabled enum idiom, validation/CEL markers, the top-level Kind marker block, shared-type reuse, the Deployment override pattern) and the end-of-file checklist. Apply all of it, and run the checklist before you finish.
Read docs/principles.md for related rules ("Respect User Input", "Resource Ownership") when a judgement call isn't settled by api_design.md.
Follow the post-change workflow in docs/dev_guidelines.md — make gen-files, verify scope didn't flip to Namespaced, update convert if relevant, and make dirty-check.