一键在 Manus 中运行任何 Skill

operator-api-standards

星标215

分支157

更新时间2026年6月18日 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.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

tigera

tigera/operator

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

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.

同仓库更多 Skills

同仓库

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.