菜单
Use when reviewing Helm chart structure, values, templates, and best practices. Only triggers when Chart.yaml is detected.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when a skill needs step tracking, progress visibility, and resume support within a single phase. Called by skills, not directly by users.
Use when breaking down a project phase into stories with acceptance criteria, creating ADRs, or planning infrastructure work. Triggers on /plan, story breakdown, detailed plan, architecture doc.
Use when generating, editing, or merging Low-Level Design (LLD) documents at `docs/lld/<component>.md` or `docs/shield/<feature>/lld-<component>.md`. Triggers on /lld command (Path A) and on /plan TRD-driven authoring (Path B, M2 plan). Owns the backend and infra templates, atomic write, provenance stamp, and §14 Changelog convention.
Use when authoring a new PRD or upgrading a lean PRD to standard. Walks user through 20-section problem-first scaffold (or 10-section lean), pre-populates from prior /research transcript if present, defers Terminologies (§2) until after the rest is drafted (auto-fills from research glossary + scan of body), invokes shield:story-coverage between Sections 6 and 8 and shield:milestone-coverage between Sections 8 and 15, prompts for story Type (new/enhancement/existing), supports custom team templates via .shield.json. Triggers on /prd, write a PRD, author a PRD.
Use when the user invokes /backlog or asks to capture, view, promote, or remove an idea from the project backlog at docs/shield/backlog.json. Triggers on /backlog add|view|remove|promote and on agent-side "capture this as a backlog entry" calls during research/PRD/plan/implement flows.
Use when a plan, architecture doc, or execution plan exists and needs expert review before implementation. Produces a scored analysis with a P0-gated verdict and an enhanced plan. Triggers on /plan-review, review my plan, document review.
| name | kubernetes-helm-review |
| description | Use when reviewing Helm chart structure, values, templates, and best practices. Only triggers when Chart.yaml is detected. |
Reviews Helm chart structure and best practices. Covers chart metadata, values defaults, template patterns, dependency management, hooks, and tests. Complements the K8s security/cost/operational skills by focusing on Helm-specific concerns like template hygiene and chart packaging.
Only triggers when Chart.yaml is detected. Does not trigger for raw K8s manifests — use the core K8s skills for those.
values.yaml defaults and documentationkubernetes-kustomize-reviewChart.yaml is foundChart.yaml exists at the target path. If not found, do not proceed.Chart.yaml for completeness, version constraints, maintainer info.values.yaml for sensible defaults, documentation, no hardcoded secrets.test-connection.yaml).Chart.lock committed, version ranges appropriate, subchart value passthrough.deprecation-check-and-upgrade.See check-tables.md for detailed check definitions.
Chart.yaml missing appVersion or versionvalues.yaml_helpers.tpl for common labels and namesNOTES.txt (users get no post-install guidance)Chart.lock (dependency versions not reproducible)| Mistake | Why It Happens | Correct Approach |
|---|---|---|
| Flagging missing tests on library charts | Library charts have no installable templates | Tests only apply to application charts (type: application) |
| Requiring NOTES.txt on subcharts | Subcharts don't display NOTES independently | NOTES.txt is for the parent chart only |
Flagging {{ .Release.Namespace }} usage | Some see this as hardcoding namespace | This is correct — it uses the release namespace dynamically |
Treating all default values as problems | default template function is normal Helm pattern | Only flag default when it masks missing required values |
| Requiring version pinning to patch level | Overly strict pinning blocks security patches | Minor version pinning (~1.2.0) is appropriate for most deps |
check-tables.md — Chart structure and template checks with pass/fail criteria