Skill · before you deploy it there

Deployment Compatibility Engineer

Assess a project against a specific target server, identify the incompatibilities and deployment risks, remediate what can safely be fixed, and verify readiness with evidence — without ever claiming a deployment will work.

Soumya Rauth · Creator & maintainer

npx skills add soumyaRauth/skills-hub --skill deployment-compatibility

Two operands

target environment + project → deployment contract → compatibility matrix → readiness

Every other skill here takes one operand — the change, the project, the symptom. This one takes two, and the second is a machine.

Deployment failures are rarely code failures. They are mismatches, and both halves are usually available before anyone deploys:

the runtime is a major version behind what the lockfile was built for
the queue library is installed and no Redis is running
uploads are written to a local path on an ephemeral filesystem
the worker process has no supervisor, so it runs once and never again
a variable lives in .env.example and nowhere on the box

When it activates

No slash command needed. Installed, it is loaded when a request needs it and stays out of the way otherwise — and when it does shape the work, one ⚡ line says so. How the skills work together →

Engages	A concrete deployment target is in view — deploy this to my VPS, will this run on my server, here are my server details — or a deployment already exists and misbehaves.
Stays quiet	Generic Docker, Linux, Kubernetes and cloud questions, local development setup, CI that ships nothing, and ordinary application work. The word deploy in a sentence is not a target environment.
Depth	Shapes the work. It gates only when you asked for the readiness decision itself.
Works with	Production Guard, Impact Map, ProofBuild, Standards Compass, Engineering Investigator

What it produces

DEPLOYMENT COMPATIBILITY
TARGET   Ubuntu 24.04 · 4 vCPU · 7.8 GB · Docker 27.1      tier READ-ONLY
PROJECT  Next.js 15 · Node 22 · PostgreSQL · Redis · 1 worker
STATE    🔴 BLOCKED

Requirement        Project needs    Target provides           Result
──────────────────────────────────────────────────────────────────────
Node               >= 22            20.11.1        MEASURED   BLOCKED
PostgreSQL         >= 16            16.2           MEASURED   FIT
Redis              required         not installed  MEASURED   BLOCKED
Worker process     required         no supervisor  MEASURED   BLOCKED
uploads/ persists  required         container fs   INFERRED   RISK
RAM                UNKNOWN          7.8 GB         MEASURED   UNVERIFIED

Each row names what the project requires and the file that establishes it, what the target provides and how that was found out. A row with only one side is a server audit or a wish list, not a compatibility assessment.

Why it cannot tell you it will be fine

Ask a capable agent whether an app will run on a server and you get a confident yes, assembled from a plausible mental model of Ubuntu. This skill is built so that answer cannot be produced. Every target fact carries its provenance, and the verdict is computed from those grades rather than written by hand.

MEASURED	A command ran against the target and its output was read.
SUPPLIED	You or a document said so. Plausible, and unverified here.
INFERRED	Derived from another observation, which is named.
UNKNOWN	Nothing establishes it, and the check that would is named.

Two rules follow, and they are the whole design. A FIT resting on a fact you supplied cannot produce ready — it becomes a numbered condition for someone to confirm. And a row whose project side is UNKNOWN is never a fit, because not knowing what an application requires is not evidence that the target satisfies it.

So ready is reachable only when the server was actually inspected, ready with conditions is the normal good outcome and its conditions are the deliverable, and not assessed is a real result rather than a failure: with no access and no specification, saying so is the correct report.

Access tiers

The tier is established before anything else, stated in the report header, and caps every claim the report can make. Nothing here assumes a tier, and nothing pretends to a capability it does not have.

NONE	No access, no specification — the project contract, and an honest not assessed.
DECLARED	A spec or your own description. Every fact is supplied, so the ceiling is ready with conditions.
READ-ONLY	Commands can run; nothing may change. Full assessment, no server changes.
AUTHORIZED	Named changes permitted — a list, never a blanket.

Safe by construction

Discovery is read-only. Project changes and server changes are kept in separate lists, so approving the first cannot be read as approving the second. Server changes are classified by impact and applied only on authorization for that specific action, with the previous state captured first so rollback is real.

One rule overrides convenience: never weaken a control to make a deployment work. No exposed database, no disabled TLS, no loosened authentication, no development mode on a server. A blocked deployment is a finding; a deployed insecure one is an incident. Secrets are reported as present, missing or redacted, and never written to disk.

Where it fits

Production Guard asks whether the change is safe to ship. This asks whether the environment can run it. Different questions, and neither verdict substitutes for the other. Environment exposure and personal data go to Standards Compass; a fix that reaches shared storage goes to Impact Map first; a deployment failure whose cause is genuinely unclear goes to Engineering Investigator, with this skill supplying the environment evidence.