review-addon

name	review-addon
description	Use when performing a thorough KubeBlocks addon Helm chart review for API compatibility, annotations, naming, role configuration, lifecycle script robustness, and test readiness.

Reference resolution: when this source-derived skill mentions docs/..., resolve it from the shared support package beside the installed user skills: ~/.codex/skills/kubeblocks-addon-source-docs/docs/... for Codex or ~/.claude/skills/kubeblocks-addon-source-docs/docs/... for Claude Code. In the shared kubeblocks-addon-docs checkout, the same files live under skills/kubeblocks-addon-source-docs/docs/.... When it mentions scripts/..., resolve it from the same support package under scripts/.... If you are working inside a checkout of the original apecloud/kubeblocks-addon-skills, repo-relative paths are also valid.

Perform a thorough code review of the KubeBlocks addon Helm chart.

Target: $ARGUMENTS (Engine name, e.g., redis. If not specified, review the most recently modified addon.)

---

Step 0: Detect KubeBlocks Version

KB_VERSION=$(kubectl get deployment -n kb-system kubeblocks \
  -o jsonpath='{.metadata.labels.app\.kubernetes\.io/version}' 2>/dev/null \
  | grep -oE '^[0-9]+\.[0-9]+' || echo "unknown")
echo "KubeBlocks version: $KB_VERSION"

Select and read the API reference for the target environment:

• 1.0.x → docs/kb-api-reference-1.0.md
• 1.1.x → docs/kb-api-reference-1.1.md
• 1.2.x or unknown → docs/kb-api-reference.md

This determines which fields and behaviors are valid for this deployment.

Step 1: Identify the Addon

# If engine name provided:
find addons/<engine>/templates/ -type f | sort

# If not provided, find recently touched addons:
find addons/ -name "*.yaml" -newer addons/redis/Chart.yaml -not -path "*/charts/*" | head -20

Step 2: Read All Files

Read every file in:

• addons/<engine>/Chart.yaml and values.yaml
• addons/<engine>/templates/ (all .yaml and .tpl files)
• addons/<engine>/config/ (ConfigMaps for config templates)
• Any scripts referenced in the templates

Step 3: Validate Helm Syntax

helm dependency update addons/<engine> 2>/dev/null || true
helm template test-addon addons/<engine>

Any rendering error is a blocking failure — the review cannot pass.

Step 4: Review Criteria

Criterion 1: API Compliance

• All CRD resources use apps.kubeblocks.io/v1?
• No ClusterVersion kind anywhere?
• configs[].template used (not templateRef)?
• configs[].volumeName matches a volume in runtime.volumes AND a volumeMount in runtime.containers[*].volumeMounts?
• ComponentVersion.spec.releases[*].images keys match container names in ComponentDefinition.spec.runtime.containers[*].name plus any action container keys (switchover, accountProvision, etc.)?
• ClusterDefinition.spec.topologies[*].components[*].compDef uses a regex pattern (not a hard-coded full name)?

Criterion 2: Required Annotations

Check every ClusterDefinition, ComponentDefinition, and ComponentVersion:

• kubeblocks.io/crd-api-version: apps.kubeblocks.io/v1 present?
• apps.kubeblocks.io/skip-immutable-check: "true" present?

Missing the skip-immutable-check annotation is a blocking issue — helm upgrade will fail without it.

Criterion 3: ComponentDefinition Naming

• Name includes $.Chart.Version suffix? (e.g., redis-7-1.1.0 not just redis-7)
• compDef in ClusterDefinition uses regex that matches these versioned names?

Criterion 4: Role Configuration

• Leader/primary role has isExclusive: true?
• Leader role has higher updatePriority than follower (updated last)?
• roleProbe command is correct for this engine version and port?

Criterion 5: Version Alignment

Identify the target version(s) from the goal or Chart.yaml appVersion.

For each version X.Y.Z:

• ComponentDefinition.spec.serviceVersion == X.Y.Z?
• Image tags in ComponentVersion.spec.releases[*].images == X.Y.Z (or correct imageTag from values)?
• Chart.yaml appVersion reflects the primary/latest version?
• Config ConfigMap contains parameters actually valid for version X.Y.Z?

Criterion 6: Logic Robustness

• Lifecycle scripts handle the specific version's behavior (do NOT assume behavior from a different major version)?
• roleProbe script correctly identifies roles for this version's protocol?
• postProvision / memberJoin / switchover scripts are idempotent (safe to run multiple times)?
• Shell scripts use set -e or explicit error checking?
• Init containers handle the case where data directory already exists (idempotent initialization)?

Criterion 7: Backward Compatibility

• Existing entries in the versions array (<engine>Versions) are unchanged?
• All original {{- define "..." -}} blocks in _helpers.tpl still present?
• Existing ComponentVersion releases still present (only new ones added)?
• Existing ClusterDefinition topologies unchanged (only new ones added)?

Criterion 8: Config Accuracy

• Config template for version N uses parameters specific to version N?
• Not blindly copied from version N-1 without reviewing changed/removed parameters?
• Default values are appropriate for this engine version?

Step 5: Do NOT Flag (Intentional)

These are acceptable and must not be flagged as issues:

• securityContext with privileged: true or elevated capabilities
• High resource requests/limits
• Running as root / user 0
• Accessing host paths
• Container-to-container communication on internal ports

These are required by database internals.

Step 6: Output Review Report

## Review Result: PASSED / FAILED

### Helm Rendering
[ ✓ Passed | ✗ FAILED: <error> ]

### API Compliance
[ ✓ All OK | ✗ Issues: <list> ]

### Required Annotations
[ ✓ Present on all resources | ✗ Missing on: <resource-names> ]

### ComponentDefinition Naming
[ ✓ Correct | ✗ Issues: <detail> ]

### Role Configuration
[ ✓ OK | ✗ Issues: <detail> ]

### Version Alignment
[ ✓ All OK | ✗ Discrepancies: <list> ]

### Logic Robustness
[ ✓ OK | ✗ Issues (with file:section references): <list> ]

### Backward Compatibility
[ ✓ OK | ✗ Breaking changes: <list> ]

### Config Accuracy
[ ✓ OK | ✗ Issues: <list> ]

---

### Blocking Issues (must fix before deploy)
1. <specific actionable issue — file path, field name, what to change>
2. ...

### Non-blocking Suggestions
1. ...

If FAILED: do not proceed to deployment until all blocking issues are resolved.