Each skill is a runbook written so an agent can follow it: the checks, the commands, and the
failure modes already spelled out. Start with the health check if you are new to the lab,
otherwise skip to whatever is blocking you today. The prompt is a starting point, not the
finished skill.
v1.4Jun 2026
VCF Health Check
Walks a VMware Cloud Foundation instance end to end and reports what is actually wrong, in the order it needs fixing. It reads the same whether a person or an agent is following it: every check names the command it runs, the value that counts as healthy, and what to do when it is not.
Why build it
The information you need after a bad night is spread across four consoles, and the order you check them in is the difference between twenty minutes and two hours. Writing the order down once means it survives being tired, and an agent can run the first pass before you have finished making coffee.
What you need
Read access to SDDC Manager, vCenter and NSX Manager, and a known-good config export to diff against.
The runbook
01Confirm SDDC Manager, vCenter and NSX Manager are reachable and on the versions you expect.
02Pull certificate expiry for every management endpoint and flag anything inside 30 days.
03Check cluster capacity against the host-failure reserve you actually need, not the default.
04Diff NSX transport zone and segment config against the last known-good export.
05Summarise findings highest-risk first, with the command that fixes each one.
<job>
Assess the health of a VMware Cloud Foundation instance and report findings
ordered by risk, highest first.
</job>
<inputs_to_collect>
<input>SDDC Manager FQDN and the read-only credential to use.</input>
<input>Path to the last known-good NSX config export.</input>
<input>The host-failure reserve this environment is sized for.</input>
</inputs_to_collect>
<requirements>
<requirement>Never write to the environment. Read-only calls only.</requirement>
<requirement>Report the command run and the observed value for every check.</requirement>
<requirement>State explicitly when a check could not be completed.</requirement>
</requirements>
Audits segments, edges and routing against a declared intent file and reports the drift. The intent file is the point: once the overlay is described in one place, every subsequent change is either in the file or it is drift.
Why build it
Overlay config accumulates one urgent fix at a time, and none of them get written down. After a year nobody can say what the design is, only what it currently does. An audit that compares running state to a declared design turns that back into a question with an answer.
What you need
An intent file describing the intended overlay, and read access to NSX Manager.
The runbook
01Load the intent file and validate it parses before touching the environment.
02Enumerate transport zones, segments, tier-0 and tier-1 gateways from the running config.
03Diff each object against intent and classify every difference.
04Check advertised routes actually match what the gateways are configured to advertise.
05Report drift grouped by object, with the intent line number that it violates.
<job>
Compare the running NSX overlay to the declared intent file and report drift.
</job>
<inputs_to_collect>
<input>Path to the intent file.</input>
<input>NSX Manager endpoint and read-only credential.</input>
</inputs_to_collect>
<requirements>
<requirement>Classify each difference as drift, intentional, or unknown.</requirement>
<requirement>Do not propose remediation for anything marked unknown.</requirement>
</requirements>
Sweeps every management endpoint for expiring certificates and drafts the rotation plan, in dependency order. Rotating in the wrong order is how a maintenance window turns into an outage, so the plan is the output, not the rotation itself.
Why build it
Every outage in the lab last quarter traced back to a certificate, and each one was visible weeks in advance. The problem was never detection, it was that nobody owned the list. A skill that produces the list on demand removes the excuse.
What you need
Network reach to each endpoint and a documented rotation order for the estate.
The runbook
01Build the endpoint list, either from the inventory file or by discovery.
02Read the presented certificate chain from each endpoint and record expiry and issuer.
03Flag anything inside the warning threshold, plus anything self-signed.
04Sort the flagged set into dependency order and draft the rotation plan.
05Note which steps require a service restart and which do not.
<job>
Inventory certificates across management endpoints and draft a rotation plan
in dependency order.
</job>
<inputs_to_collect>
<input>Endpoint list, or the discovery method to build one.</input>
<input>Warning threshold in days. Default 30.</input>
</inputs_to_collect>
<requirements>
<requirement>Never rotate anything. Produce a plan only.</requirement>
<requirement>Order steps so no endpoint is rotated before its dependencies.</requirement>
</requirements>
cp -r skills/cert-expiry-sweep ~/.skills/
v0.9Apr 2026
Lab Rebuild
Rebuilds the homelab management domain from bare metal in the order that works. Less a script than a sequence with the prerequisites made explicit, because the failures are almost always ordering failures rather than configuration ones.
Why build it
I rebuild the lab often enough to keep hitting the same three ordering mistakes and rarely enough to forget them in between. Writing the sequence down as a runbook is the cheapest possible fix, and it doubles as the disaster recovery document I would otherwise never write.
What you need
Hardware inventory, DNS and NTP reachable, and the deployment bundle staged locally.
The runbook
01Verify DNS forward and reverse records exist for every host and appliance.
02Confirm NTP is reachable and hosts agree on time to within a second.
03Stage the deployment bundle and validate its checksum before starting.
04Run the management domain deployment and watch for the two steps that usually stall.
05Replace the generated certificates before onboarding anything else.
06Capture a known-good config export and store it outside the lab.
<job>
Guide a full rebuild of the lab management domain from bare metal, verifying
each prerequisite before moving on.
</job>
<inputs_to_collect>
<input>Host inventory with BMC addresses.</input>
<input>DNS zone and the records that must already exist.</input>
</inputs_to_collect>
<requirements>
<requirement>Stop and report rather than continuing past a failed prerequisite.</requirement>
<requirement>Confirm DNS forward and reverse records before any deployment step.</requirement>
</requirements>
cp -r skills/lab-rebuild ~/.skills/
v1.2May 2026
Change Record Writer
Turns a set of config diffs into a change record a reviewer can actually approve: what changes, what the blast radius is, how it gets backed out, and how you will know it worked.
Why build it
Most rejected changes are not risky, they are badly described. The information the reviewer wants already exists in the diff and in your head, and assembling it by hand is tedious enough that people write two sentences and hope. This does the assembly.
What you need
The config diff, and the change template your process expects.
The runbook
01Parse the diff and group changes by the system they affect.
02For each group, state what changes and what stays the same.
03Derive the blast radius, naming the services in scope and out of scope.
04Write a rollback step and a verification step for every group.
05Fill the template and mark every inferred field for review.
<job>
Convert a set of configuration diffs into a change record using the supplied
template.
</job>
<inputs_to_collect>
<input>The diff, or the paths to before and after config.</input>
<input>The change template to fill in.</input>
</inputs_to_collect>
<requirements>
<requirement>State the blast radius explicitly, including what is unaffected.</requirement>
<requirement>Every change needs a rollback step and a verification step.</requirement>
<requirement>Mark anything you inferred rather than read from the diff.</requirement>
</requirements>