cloud-native-readiness

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.