cloud-native-readiness

云原生就绪度评估技能

概述

此技能通过一个分为 3 个阶段的工作流，评估代码仓库是否已准备好部署为云原生微服务：

1. 评估 - 根据云原生标准分析项目，并生成就绪度报告
2. 检测 - 检查是否已存在 Docker 构件（Dockerfile、docker-compose、容器镜像）
3. 路由 - 如果存在构件，则直接返回结果；如果不存在，则调用 dockerfile-skill 进行容器化

工作流

cloud-native-readiness
  │
  ├─ Phase 1: Cloud-Native Assessment
  │    ├─ NOT suitable → Report reasons, suggest remediation, END
  │    └─ Suitable → Continue
  │
  ├─ Phase 2: Existing Artifacts Detection
  │    ├─ Found Dockerfile/docker-compose/image → Report existing setup, END
  │    └─ Not found → Continue
  │
  └─ Phase 3: Route to dockerfile-skill
       └─ Invoke /dockerfile to generate Docker configuration

用法

/cloud-native-readiness              # Assess current directory
/cloud-native-readiness <path>       # Assess specific path
/cloud-native-readiness <github-url> # Clone and assess

快速开始

调用时，始终按以下顺序执行：

1. 读取并执行 modules/assess.md — 云原生就绪度评估
2. 读取并执行 modules/detect.md — 检测现有 Docker 构件
3. 读取并执行 modules/route.md — 决策路由

阶段 1：云原生就绪度评估

加载并执行：modules/assess.md

评估 6 个维度（每项评分为 0-2）：

维度	检查内容
无状态性	应用是否在本地存储状态（内存中的会话、本地文件写入）？
配置外置	配置是硬编码的，还是由环境变量 / 配置文件驱动？
水平扩展能力	多个实例能否无冲突地运行？
启动/关闭	应用能否快速启动并妥善处理 SIGTERM？
可观测性	是否具备健康检查、结构化日志和指标？
服务边界	它是职责明确的服务，还是紧密耦合的单体？

评分：

• 10-12：优秀 — 已完全满足云原生就绪要求
• 7-9：良好 — 只需稍作调整即可就绪
• 4-6：一般 — 容器化前需要进行一些重构
• 0-3：较差 — 需要进行大量改造，目前不建议容器化

输出：包含评分、发现和建议的结构化就绪度报告。

阶段 2：检测现有构件

加载并执行：modules/detect.md

检查项：

• Dockerfile / Dockerfile.*（多阶段、多服务）
• docker-compose.yml / docker-compose.yaml / compose.yml
• .dockerignore
• DOCKER.md 或 Docker 相关文档
• 容器镜像仓库引用（ghcr.io、docker.io、ECR、GCR、ACR）
• Kubernetes 清单（k8s/、kubernetes/、deploy/、helm/、charts/）
• 包含 Docker 构建步骤的 CI/CD 流水线（.github/workflows/、.gitlab-ci.yml）

输出：现有 Docker/K8s 构件清单及质量评估。

阶段 3：路由决策

加载并执行：modules/route.md

决策矩阵：

就绪度评分	构件是否存在	操作
≥ 7	是，完整	报告现有配置。完成。
≥ 7	是，部分	报告缺项并建议改进。完成。
≥ 7	否	调用 dockerfile-skill 生成。
4-6	任意	报告问题及修复步骤。可选择继续调用 dockerfile-skill。
0-3	任意	报告阻碍因素。不要调用 dockerfile-skill。

就绪度报告格式

最终输出必须使用以下格式：

# Cloud-Native Readiness Report

## Summary
- **Project**: {name}
- **Score**: {score}/12 ({rating})
- **Verdict**: {Ready | Ready with caveats | Needs work | Not recommended}

## Assessment Details

### ✅ Strengths
- {what's already cloud-native friendly}

### ⚠️ Concerns
- {issues that need attention}

### ❌ Blockers (if any)
- {critical issues preventing containerization}

## Dimension Scores

| Dimension | Score | Notes |
|-----------|-------|-------|
| Statelessness | {0-2} | {detail} |
| Config Externalization | {0-2} | {detail} |
| Horizontal Scalability | {0-2} | {detail} |
| Startup/Shutdown | {0-2} | {detail} |
| Observability | {0-2} | {detail} |
| Service Boundaries | {0-2} | {detail} |

## Existing Docker Artifacts
- {inventory or "None found"}

## Recommendation
- {next steps}

支持资源

• 评估标准：knowledge/criteria.md — 详细评分细则
• 反模式：knowledge/anti-patterns.md — 常见云原生反模式
• 示例：examples/ — 就绪度报告示例

与 dockerfile-skill 集成

路由到 dockerfile-skill 时，请传递评估上下文：

1. 就绪情况报告中的发现会影响 Dockerfile 生成决策
2. 检测到的外部服务直接对应 docker-compose.yml 中的服务
3. 识别出的问题会成为 Dockerfile 注释或 DOCKER.md 中的注意事项
4. 评估中关于配置外置的发现会决定 ENV/ARG 设置

交接：调用 dockerfile-skill 时，请附上以下内容的摘要：

• 检测到的语言、框架和包管理器
• 外部服务依赖
• 配置外置状态
• 任何特殊问题（有状态组件、启动时间较长等）