AgentSkillsCN

deployment-readiness

保持Kubernetes部署资产始终处于生产就绪状态，以支持此应用的迭代更新。在应用变更需要更新Helm图表、调整values/模板配置，或在发布前进行部署验证时使用。

SKILL.md
--- frontmatter
name: deployment-readiness
description: Keep Kubernetes deployment assets production-ready for this app. Use when application changes require Helm chart updates, values/template alignment, and deployment validation before release.
license: MIT

Deployment Readiness

When to Use This Skill

Use this skill when a code or configuration change may affect deployment.

Typical triggers:

  • •Container port/env/probe behavior changes.
  • •New runtime configuration is added.
  • •Service exposure, scaling, resources, or security settings change.
  • •Helm chart values/templates must be updated for release readiness.

Execution Workflow

  1. •Review application and container changes that impact deployment.
  2. •Compare current application behavior and API contract against the previous released version.
  3. •Classify change impact using semantic versioning:
    • •Breaking changes (backward-incompatible behavior, removed/renamed endpoints/fields, incompatible contract changes) => major bump.
    • •Non-breaking feature changes (backward-compatible new behavior/capabilities) => minor bump.
    • •Fix-only changes (bug fixes/internal corrections with no new external behavior) => patch bump.
  4. •Only consider version updates after the application is tested and confirmed deployment-ready.
  5. •Before changing versions, ask the user explicitly: "The app appears tested and ready for deployment. Update application version across the repository now? (yes/no)"
  6. •If the user says yes, update all release version fields together:
    • •package.json -> version
    • •helm/todo-api/Chart.yaml -> version and appVersion
  7. •If the user says no, do not change versions; treat the release as not yet ready/completed.
  8. •Ensure bumped versions are consistent across files.
  9. •Update Helm values.yaml and templates in a consistent, minimal way.
  10. •Validate probes, ports, env variables, and resource defaults.
  11. •Validate chart structure, linting, and render output.
  12. •Verify release safety: upgrade path, rollback approach, and immutable image tag usage.
  13. •Confirm post-deploy verification steps are defined (health/readiness checks and smoke checks).
  14. •Update root README.md deployment instructions when relevant.

Production Readiness Guardrails

  • •Keep liveness/readiness checks aligned with /health.
  • •Ensure sane resource requests/limits and secure defaults.
  • •Avoid hardcoded environment-specific values in templates.
  • •Preserve backward-compatible values where possible.
  • •Evaluate compatibility against the previous release before finalizing deployment readiness.
  • •Prefer immutable image tags for releases and keep rollback path explicit.
  • •Document any required operational steps for safe upgrade/rollback.
  • •Store validation artifacts under output/deployment-readiness/ inside this workspace.

See deployment validation checklist before completion.

Quick Commands

  • •Compare current branch with latest tag: git diff --name-status $(git describe --tags --abbrev=0)..HEAD
  • •Create output directory: mkdir -p output/deployment-readiness
  • •Validate compose config: docker compose config > output/deployment-readiness/compose-config.yaml
  • •Lint chart (if Helm is installed): helm lint ./helm/todo-api
  • •Render templates: helm template todo-api ./helm/todo-api > output/deployment-readiness/helm-render.yaml