Run any Skill in Manus with one click

operator-api-standards

Stars215

Forks157

UpdatedJune 18, 2026 at 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

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

tigera

tigera/operator

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·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.

More from this repository

same 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.