Cloud Native Readiness
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".
- Skill ID
- labring/sealos-skills/cloud-native-readiness
- Publisher
- labring
- Repository
- sealos-skills
- Installs
- 0
- Files
- 12
- Synced
- Sep 23, 2026
Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.
labring/sealos-skills/cloud-native-readinessInstalls these files- SKILL.md
- agents/openai.yaml
- evals/evals.json
- examples/sample-report.md
- knowledge/anti-patterns.md
- knowledge/criteria.md
- knowledge/deployment-eligibility.md
- knowledge/scoring-model.md
- knowledge/sealos-patterns.md
- modules/assess.md
- modules/detect.md
- modules/route.md
What this skill tells the agent
Cloud Native Readiness Assessment Skill
Identity and Discovery
- Owner:
cloud-native-readiness(/cloud-native-readinessand readiness, containerization, deployment-feasibility, or workload-eligibility requests). - Class:
read-only-observationwith a typed handoff todockerfile-skillonly after eligibility and route evidence pass. - Canaries:
CNR-ELIGIBILITY-STOPandCNR-ROUTE-HANDOFF.
Scope and Boundaries
Accept a local path or GitHub URL and inspect repository evidence. This entry assesses eligibility, readiness, and existing artifacts; it does not write project files or score an unsupported target. A standalone readiness request keeps its report in the request result and does not create .sealos/analysis.json; composed deploy orchestration may persist a sanitized handoff snapshot under its own contract. A Dockerfile handoff carries the readiness report as its input artifact and leaves packaging mutations to the receiving owner.
Risk and Confirmation
Load knowledge/deployment-eligibility.md before scoring. An unsupported or unresolved workload stops before artifact detection, scoring, Dockerfile generation, or deployment. Keep source paths, environment values, and any credentials redacted in the report; preserve the current fail-closed eligibility boundary.
Lifecycle Workflow
For each request, select the repository, run eligibility, assess eligible targets, detect Docker artifacts, and route only when the decision matrix allows it. The request ends with success, stopped, or error; each result carries the selected source, workload type, redaction status, and the strongest evidence reached. The existing three-phase Assess → Detect → Route workflow remains the domain extension below.
Progressive Disclosure
Load modules/assess.md, modules/detect.md, and modules/route.md one level deep when their phase is reached. Load the deployment-eligibility knowledge before the first score. Do not load Dockerfile detail or invoke the handoff after an eligibility stop.
Output, Stop, and Error States
success: selected source, eligible workload type, score dimensions, artifact inventory, concerns, recommendation, verification evidence, and any typed handoff are present.stopped: selected source, workload type, eligibility or confirmation reason codes, observed evidence, redaction result, and safe next action are present; no downstream artifact is claimed.error: selected source, failed phase/helper or artifact, sanitized diagnostic, redaction result, and recovery action are present.
Handoffs
When eligible and the route requires packaging, send the complete typed handoff below for an assessment-only request. The receiving skill re-checks its own scope and canaries.
target: dockerfile-skill
inputArtifact: readiness report with source, project language/framework/package manager, dependencies/configuration, workload, score, dimensions, concerns, and artifact inventory
allowedAction: generate Docker packaging within the receiving skill's owned file scope
failureReturn: readiness findings and the failed route condition
responseOwner: cloud-native-readinessVerification
Use workload-eligibility.mjs, score-model.mjs, the current readiness eval evidence, and the baseline traces readiness-positive-eligible and readiness-violating-ineligible. Verify eligibility before score/build, preserve report fields, and redact credential-shaped values.
Readiness Report Contract
Keep this payload request-scoped and repository-relative. A downstream handoff may reuse it without repeating discovery.
source:
kind: local-path | github-url
display: redacted repository identifier
project:
language: detected language
framework: detected framework or null
package_manager: detected package manager or null
dependencies: redacted external dependency types and versions
configuration: redacted configuration and environment-key observations
workload:
type: server | static-web | worker | scheduled-job | reviewed-remote-desktop | unresolved
eligibility: eligible | ineligible | needs_review
assessment:
score: 0-12 or null when stopped
dimensions: six named scores when eligible
concerns: redacted findings
artifacts:
status: complete | partial | none
inventory: repository-relative paths and quality observations
recommendation: report-only | package | remediate | stop
verification:
helper: eligibility and/or scoring helper invoked
evidence: observed result and redaction status
handoff: typed tuple or none
terminal_state: success | stopped | error
safe_next_action: request-scoped next actionThe payload never contains passwords, tokens, kubeconfig contents, environment values, or complete connection strings.
Overview
This skill evaluates a repository's readiness for cloud-native microservice deployment through a 3-phase workflow:
- Assess - Reject unsupported workload types, then score eligible targets
- Detect - Check if Docker artifacts already exist (Dockerfile, docker-compose, container images)
- Route - If artifacts exist, return the result directly; if not, invoke
dockerfile-skillto 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 configurationUsage
/cloud-native-readiness # Assess current directory
/cloud-native-readiness <path> # Assess specific path
/cloud-native-readiness <github-url> # Clone and assessQuick Start
When invoked, read and execute modules/assess.md first. Continue to modules/detect.md and modules/route.md only when the assessment report resolves the requested root as eligible. An ineligible, unresolved needs_review, or error result ends the request with its evidence and safe next action before artifact detection or downstream routing.
Phase 1: Cloud-Native Readiness Assessment
Load and execute: modules/assess.md
Apply 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
Checks for:
Dockerfile/Dockerfile.*(multi-stage, multi-service)docker-compose.yml/docker-compose.yaml/compose.yml.dockerignoreDOCKER.mdor docker-related documentation- Container registry references (ghcr.io, docker.io, ECR, GCR, ACR)
- Kubernetes manifests (
k8s/,kubernetes/,deploy/,helm/,charts/)
More from labring
Use this skill in a project
Open any RiverX project, search the Skills panel for labring/sealos-skills/cloud-native-readiness, and install it in one click.
