labring/sealos-skills12 files

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".

Specification
Skill ID
labring/sealos-skills/cloud-native-readiness
Publisher
labring
Repository
sealos-skills
Installs
0
Files
12
Synced
Sep 23, 2026
How to use it

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-readiness and readiness, containerization, deployment-feasibility, or workload-eligibility requests).
  • Class: read-only-observation with a typed handoff to dockerfile-skill only after eligibility and route evidence pass.
  • Canaries: CNR-ELIGIBILITY-STOP and CNR-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-readiness

Verification

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 action

The 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:

  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, 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):

DimensionWhat to check
StatelessnessDoes the app store state locally (sessions in memory, local file writes)?
Config ExternalizationAre configs hardcoded or driven by env vars / config files?
Horizontal ScalabilityCan multiple instances run without conflicts?
Startup/ShutdownDoes the app start fast and handle SIGTERM gracefully?
ObservabilityDoes it have health checks, structured logging, metrics?
Service BoundariesIs 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
  • .dockerignore
  • DOCKER.md or docker-related documentation
  • Container registry references (ghcr.io, docker.io, ECR, GCR, ACR)
  • Kubernetes manifests (k8s/, kubernetes/, deploy/, helm/, charts/)

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.

Use this skill