lrstanleylrstanley/skills/skills/kubernetes-upgrade-analysis/SKILL.md

kubernetes-upgrade-analysis

Skill1 starsChanged 14 days agoMITView on GitHub

Analyzes a live Kubernetes cluster and its GitOps sources (Flux, Argo CD) for a cluster minor-version upgrade or a single component upgrade, and writes a standardized, skimmable upgrade report covering API deprecations, per-component compatibility, maximum upgrade headroom, and a batched upgrade plan. Use when planning a Kubernetes upgrade (e.g. 1.34 to 1.35), upgrading a cluster component (CNI, ingress, operators, controllers, CSI), or auditing upgrade readiness.

In this repository27 other files it gives its agents.
- AGENTS.mdAGENTS.md
- golang-tui-update-examplesSkill
- upstream-syncSkill
- apply-worktreeSkill
- babysit-prSkill
- documentation-writerSkill
- file-prSkill
- frontend-designSkill
- golang-packagesSkill
- golangSkill
- golang-tuiSkill
- grill-meSkill
- karpathy-guidelinesSkill
- kubernetes-specialistSkill
- leaving-gh-commentsSkill
- mermaid-diagramsSkill
- modernizeSkill
- nuclear-reviewSkill
- remotion-best-practicesSkill
- reviewSkill
- security-auditSkill
- shadcn-vueSkill
- sharpenSkill
- simplifySkill
- tui-designSkill
- unslopSkill
- writing-for-agentsSkill

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 2 are distinctive, and 9 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Read-only analysis of a cluster (and the Git repos that drive it) ahead of an upgrade.
line 24
Very specific:
Not for performing the upgrade, writing manifests, or live troubleshooting (see kubernetes-specialist).
line 34
Very specific:
Read-only: Only get, list, describe, version, api-resources, auth can-i, --raw GETs, helm list/template, flux get/check, argocd app …
line 39
Very specific:
Explicit context: After confirmation, pass --context <ctx> on every kubectl, helm --kube-context, and flux --context call.
line 43
Very specific:
No guessing: Every status claim needs a source link.
line 45
Very specific:
No secrets: Never fetch Secret objects or print Helm values.
line 49
Very specific:
Confirm target: Run the confirmation probes in references/discovery.md, show the user the context, API host, distro, server version, and …
line 57
Very specific:
Discover: Run the discovery probes as one batch (parallel, output redirected into evidence/).
line 62
Very specific:
Detect deprecations: Run every installed scanner against the cluster and the GitOps repos with the target version set.
line 65
Distinctive:
Keep section order, headings, and status words identical across reports.
line 96
Very specific:
Use non-ASCII punctuation in REPORT.md and INDEX.md.
line 104

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Kubernetes Upgrade Analysis

Read-only analysis of a cluster (and the Git repos that drive it) ahead of an upgrade. The deliverable is one report in a fixed layout, so runs are comparable and later runs can reuse earlier ones as context.

When to Use

"Upgrade the cluster from 1.34 to 1.35" (scope: cluster).
"Upgrade cert-manager / Cilium / Flux / the ingress controller / ..." (scope: component).
"Is this cluster ready for 1.N?" or "How far can we upgrade?"

Not for performing the upgrade, writing manifests, or live troubleshooting (see kubernetes-specialist).

Hard Rules

Read-only. Only get, list, describe, version, api-resources, auth can-i, --raw GETs, helm list/template, flux get/check, argocd app get/list. Never apply, patch, delete, drain, cordon, annotate, flux reconcile/suspend/resume/migrate, argocd app sync. Mutating commands may appear in the plan as recommendations only.
Explicit context. After confirmation, pass --context <ctx> on every kubectl, helm --kube-context, and flux --context call.
No guessing. Every status claim needs a source link. Unverifiable facts are UNKNOWN, with the sources checked listed.
No upstream clones. Clone only the GitOps repos that drive this cluster (shallow). Research components through gh api, release pages, raw file URLs, and Helm repo indexes.
No secrets. Never fetch Secret objects or print Helm values; redact credentials from evidence/ and the report.

Core Workflow

Load history. Find the report root (default upgrade-reports/). Read INDEX.md and the latest REPORT.md for this cluster (and for the same component, if any). Reuse verified facts whose version and source URL have not changed.
Confirm target. Run the confirmation probes in references/discovery.md, show the user the context, API host, distro, server version, and node count, and wait for explicit confirmation (use the client's question tool if it has one). Confirm scope, from-version, and to-version too. If the user already named context and target, record that as the confirmation and still run the probes.
Discover. Run the discovery probes as one batch (parallel, output redirected into evidence/). Find the provider's offered versions on managed clusters, trace GitOps sources into the cluster's repos, and build the component list (references/discovery.md).
Detect deprecations. Run every installed scanner against the cluster and the GitOps repos with the target version set; use the documented fallback for missing tools (references/deprecation-tools.md).
Research compatibility, by tier. Deep research for Tier A components, one lookup for Tier B, none for Tier C. Run lookups in parallel; stop after two failed lookups per fact and record UNKNOWN (references/compatibility-research.md).
Write the report once. Produce REPORT.md and update INDEX.md using the layout, status words, and batched plan format in references/report-format.md. Summarize the verdict, blockers, headroom, and plan batches in chat.

Reference Guide

Topic	Reference	Load When
Confirmation, discovery probes, provider cap, GitOps and repo tracing	`references/discovery.md`	Steps 2-3
Deprecation scanners, API server metric, finding format	`references/deprecation-tools.md`	Step 4
Tiers, no-clone research, ceilings, headroom, skew	`references/compatibility-research.md`	Step 5
Folder layout, status words, report template, batched plan	`references/report-format.md`	Steps 1 and 6

Constraints

MUST DO

Confirm the cluster context with the user before running anything beyond the probes.
Report headroom (how far beyond the target the cluster could go) for the cluster and per component, including the provider's offered versions on managed clusters.
Group the upgrade plan into ordered batches, each with a type (PR, MANUAL, PROVIDER, VERIFY), a phase (before, during, after the control-plane upgrade), its dependencies, and a gate, so each batch is one pull request or one operation.
Link every component row to its release and compatibility source.
Record what could not be checked (missing tools, RBAC denials, private repos) in the report.
Keep section order, headings, and status words identical across reports.

MUST NOT DO

Mutate the cluster or GitOps repos, or trigger reconciliation.
Clone upstream component repositories.
Claim support for a Kubernetes version without a cited source.
Silently skip a missing tool; record it as not installed and use the fallback.
Use non-ASCII punctuation in REPORT.md and INDEX.md. Raw evidence/ files are exempt.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free