Determine whether a repository contains a supported cloud workload, then assess eligible targets for cloud-native readiness with a 0-12 score. Use for containerization readiness, Docker/Kubernetes compatibility, deployment feasibility, workload eligibility, or pre-deployment assessment. Also triggers on \"/cloud-native-readiness\".
Scanned 9/12/2026
Install to Claude Code
npx -y skills add thedixitjain/the-mega-skill-library --skill cloud-native-readiness --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Cloud Native Readiness?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/thedixitjain-cloud-native-readiness)More formats (shields.io, HTML) on the badges page.
---
name: cloud-native-readiness
description: "Determine whether a repository contains a supported cloud workload, then assess eligible targets for cloud-native readiness with a 0-12 score. Use for containerization readiness, Docker/Kubernetes compatibility, deployment feasibility, workload eligibility, or pre-deployment assessment. Also triggers on \"/cloud-native-readiness\"."
category: devops-and-infra
source_repo: hashgraph-online/awesome-codex-plugins
source_path: "plugins/labring/sealos-skills/skills/cloud-native-readiness/SKILL.md"
source_url: https://github.com/hashgraph-online/awesome-codex-plugins/blob/HEAD/plugins/labring/sealos-skills/skills/cloud-native-readiness/SKILL.md
---
# Cloud Native Readiness Assessment Skill
## Overview
This skill evaluates a repository's readiness for cloud-native microservice deployment through a 3-phase workflow:
1. **Assess** - Reject unsupported workload types, then score eligible targets
2. **Detect** - Check if Docker artifacts already exist (Dockerfile, docker-compose, container images)
3. **Route** - If artifacts exist, return the result directly; if not, invoke `dockerfile-skill` to containerize
## Workflow
```
cloud-native-readiness
│
├─ Phase 1: Cloud-Native Assessment
│ ├─ Eligibility fails or needs review → Report evidence, END
│ └─ Eligible → Calculate readiness score
│
├─ 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
```
## Usage
```
/cloud-native-readiness # Assess current directory
/cloud-native-readiness <path> # Assess specific path
/cloud-native-readiness <github-url> # Clone and assess
```
## Quick Start
When invoked, ALWAYS follow this sequence:
1. Read and execute [modules/assess.md](modules/assess.md) — Cloud-native readiness evaluation
2. Read and execute [modules/detect.md](modules/detect.md) — Existing Docker artifacts detection
3. Read and execute [modules/route.md](modules/route.md) — Decision routing
## Phase 1: Cloud-Native Readiness Assessment
Load and execute: [modules/assess.md](modules/assess.md)
Apply [knowledge/deployment-eligibility.md](knowledge/deployment-eligibility.md)
before assigning a readiness score. Continue only when the requested root is
classified `eligible`.
**Evaluates 6 dimensions** (each scored 0-2):
| Dimension | What to check |
|-----------|---------------|
| Statelessness | Does the app store state locally (sessions in memory, local file writes)? |
| Config Externalization | Are configs hardcoded or driven by env vars / config files? |
| Horizontal Scalability | Can multiple instances run without conflicts? |
| Startup/Shutdown | Does the app start fast and handle SIGTERM gracefully? |
| Observability | Does it have health checks, structured logging, metrics? |
| Service Boundaries | Is it a focused service or a tightly-coupled monolith? |
**Scoring**:
- **10-12**: Excellent — fully cloud-native ready
- **7-9**: Good — ready with minor adjustments
- **4-6**: Fair — needs some refactoring before containerization
- **0-3**: Poor — significant rework needed, not recommended for containerization now
**Output**: Structured readiness report with score, findings, and recommendations.
## Phase 2: Existing Artifacts Detection
Load and execute: [modules/detect.md](modules/detect.md)
**Checks for**:
- `Dockerfile` / `Dockerfile.*` (multi-stage, multi-service)
- `docker-compose.yml` / `docker-compose.yaml` / `compose.yml`
- `.dockerignore`
- `DOCKER.md` or docker-related documentation
- Container registry references (ghcr.io, docker.io, ECR, GCR, ACR)
- Kubernetes manifests (`k8s/`, `kubernetes/`, `deploy/`, `helm/`, `charts/`)
- CI/CD pipeline with Docker build steps (`.github/workflows/`, `.gitlab-ci.yml`)
**Output**: Inventory of existing Docker/K8s artifacts with quality assessment.
## Phase 3: Routing Decision
Load and execute: [modules/route.md](modules/route.md)
**Decision Matrix**:
An `ineligible` or unresolved `needs_review` result always stops before artifact
detection or Dockerfile generation. Apply the score matrix only to `eligible` targets.
| Readiness Score | Artifacts Exist | Action |
|-----------------|-----------------|--------|
| ≥ 7 | Yes, complete | Report existing setup. Done. |
| ≥ 7 | Yes, partial | Report gaps, suggest improvements. Done. |
| ≥ 7 | No | Invoke `dockerfile-skill` to generate. |
| 4-6 | Any | Report issues + remediation steps. Optionally proceed with `dockerfile-skill`. |
| 0-3 | Any | Report blockers. Do NOT invoke `dockerfile-skill`. |
## Readiness Report Format
The final output MUST use this format:
For a stopped eligibility result, report its workload type, reason codes, evidence,
and next action without inventing a readiness score.
```markdown
# Cloud-Native Readiness Report
## Summary
- **Project**: {name}
- **Eligibility**: {eligible | ineligible | needs_review} — {workload type}
- **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}
```
## Supporting Resources
- **Deployment Eligibility**: [knowledge/deployment-eligibility.md](knowledge/deployment-eligibility.md) — Supported workload types and fail-closed routing
- **Assessment Criteria**: [knowledge/criteria.md](knowledge/criteria.md) — Detailed scoring rubrics
- **Anti-Patterns**: [knowledge/anti-patterns.md](knowledge/anti-patterns.md) — Common cloud-native anti-patterns
- **Examples**: [examples/](examples/) — Sample readiness reports
## Integration with dockerfile-skill
When routing to `dockerfile-skill`, pass the assessment context:
1. The readiness report findings inform Dockerfile generation decisions
2. Detected external services map directly to `docker-compose.yml` services
3. Identified concerns become Dockerfile comments / `DOCKER.md` caveats
4. The assessment's config externalization findings drive ENV/ARG setup
**Handoff**: When invoking `dockerfile-skill`, include a summary of:
- Detected language/framework/package manager
- External service dependencies
- Config externalization status
- Any special concerns (stateful components, long startup, etc.)
---
**Source:** [`hashgraph-online/awesome-codex-plugins`](https://github.com/hashgraph-online/awesome-codex-plugins) → `plugins/labring/sealos-skills/skills/cloud-native-readiness/SKILL.md`
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!