Helios Migration Skills

Before

Deploying onto our internal Kubernetes platform kept failing in a way that was hard to see. The repository is not the source of truth for the build. A centralized job pulls a shared Docker template and ignores the one in your repo, so you push a fix, the pipeline goes green, and it redeploys the same stale image you were trying to replace. Nothing errors. Nothing tells you.

Underneath that were the same failures every time. Platform documentation described a configuration schema the cluster no longer accepted. Default memory limits paired with a single-replica recreate strategy meant any crash was a total outage rather than a degraded one. Container vulnerability scans at staging flagged hundreds of findings from packages nobody had deliberately included.

My first deployment attempt lost four days to one of these. A memory leak drove the pod to its ceiling, the event loop stalled, health probes failed, and the scheduler killed it. I got it stable enough to demo. It crashed again afterward and we shelved it.

What I did instead

I stopped debugging the platform in the abstract and got a second, simpler application deployed end to end inside the same infrastructure. A Streamlit dashboard, fully working, all the way through the pipeline.

That gave me something the documentation could not: a configuration verified to deploy on this platform. I worked backwards from it and turned it into a Claude Code skill pack.

The key design decision

The failure was never that the model wrote a bad Dockerfile. Claude Code writes a correct one. The problem is that a correct config gets silently overridden by an upstream step the tool cannot see, and the platform's own documentation describes behavior the platform no longer has. Both are context problems, not model problems.

So the skills carry the environment's real constraints rather than general Docker and Kubernetes knowledge. They generate the Docker and cluster config matched to a deployment known to work here. They lint the project and strip dead code and stale modules, which matters because unused imports pull in packages that fail the vulnerability scan at staging, the gate that stalls deployments right before production. They raise library incompatibilities up front rather than at build time.

What happened next

I submitted the skeleton to the internal directory and the platform engineering team took it further than I had, adding security checks, automated resource sizing for the cluster config, and a shared Python base image so Python services had a supported path.

The expansion made it worse to use. The extended version was slow, consumed a heavy number of tokens per run, and was sometimes wrong. I found that by running it against two live projects rather than by reading it, filed the bugs I hit, then fixed them and submitted merge requests. They were accepted.

Known limits

The known-good path generalizes from one working deployment, a Python service with a Streamlit interface. It is a proven route for that shape of application, not a universal one. Anything meaningfully different needs the same treatment: get one deployment working, then encode it.

Stack