soulmachine

openclaw-diagnose

Diagnose and fix OpenClaw gateway and node host issues. Use when openclaw services have warnings, connection failures, pairing errors, or port conflicts.

deploy-kimi-k26-on-rtx-pro-6000

Deploy and serve Moonshot Kimi-K2.6 (1T MoE, MLA, 256K context, vision) in a user-chosen quantization — official INT4 QAT (moonshotai/Kimi-K2.6, compressed-tensors→Marlin; vLLM or SGLang) or NVFP4 (nvidia/Kimi-K2.6-NVFP4, ModelOpt FP4; vLLM only — SGLang NVFP4 is NaN-broken on sm_120) — on a Linux server (verified Ubuntu 26.04) with 8× NVIDIA RTX PRO 6000 Blackwell Server Edition (96 GB, sm_120) GPUs. The quantization and the engine are both chosen at deploy time with a hardware-based recommendation. Runs an official-image Docker container via nvidia-container-toolkit CDI (--device nvidia.com/gpu=all --ipc=host --network host, bind-mounted weights), exposing an OpenAI-compatible API on :30000 behind one static systemd service `kimi-k26` (quant + engine selected via its EnvironmentFile — only one 595 GB variant fits the 8-GPU pool at a time). Use when deploying or serving Kimi-K2.6 INT4 or NVFP4 on RTX PRO 6000 Blackwell / sm_120 hardware (vLLM-in-Docker, or SGLang-in-Docker for INT4) — or troubleshooting NCCL

2 Updated today

API & Backend Listed

asus-esc8000-firmware-upgrade

Check and upgrade BMC firmware and BIOS on ASUS ESC8000-E12P (and similar ASMB12/AST2600 AMI-BMC ASUS servers) via Redfish and the BMC's HPM wizard API. Use when asked to check firmware/BIOS versions, update BMC or BIOS on ASUS GPU servers, or recover a BMC stuck in firmware-update/flash mode (login blocked, Redfish 503).

Data & Documents Listed

asus-esc8000-gpu-bios-tuning

Apply a low-latency GPU-serving + VM-passthrough BIOS profile to ASUS ESC8000-E12P (ASMB12/AMI-BMC, Xeon 6/GNR) servers over Redfish — diff current settings, stage, reboot, verify. Use when asked to optimize/tune BIOS for GPU inference/serving, set performance power profile, enable Resize BAR / SR-IOV / disable SNC, or replicate one server's BIOS config onto another ESC8000.

deploy-kimi-k26-blackwell

Deploy and serve Moonshot Kimi-K2.6 (1T MoE, INT4/Marlin, 256K context, vision) on an Ubuntu server with 8× NVIDIA RTX PRO 6000 Blackwell (sm_120) GPUs using a uv venv + SGLang, exposing an OpenAI-compatible API. Use when deploying or serving Kimi-K2.6 (or similar INT4 compressed-tensors MoE models) on RTX PRO 6000 Blackwell / sm_120 hardware, installing SGLang in a uv venv, or troubleshooting sm_120 startup crashes — CUDA JIT "rsqrt exception specification" / glibc errors, FlashInfer CuTe-DSL MLIR ICE (llvm.mlir.global_dtors), or a slow/hung MoE weight load.

ghostty-terminfo

Use when SSHing to a remote host from Ghostty terminal and encountering terminfo errors, missing colors, broken key bindings, or "unknown terminal type" warnings

lxd-docker-firewall-conflict

Diagnose and fix the well-known Docker/LXD firewall conflict on a host running both. Docker sets the iptables FORWARD chain policy to DROP and accepts only its own bridges, so forwarded traffic from the LXD bridge (lxdbr0) is silently dropped and LXD containers/VMs get no outbound internet (the host itself is fine). Fix: accept the LXD bridge in the DOCKER-USER chain, then persist it with a systemd unit ordered after docker.service. Use when an LXD container has no internet or cannot reach archive.ubuntu.com, when "apt update"/"apt-get"/"curl" inside an LXD container times out or reports "Network is unreachable" / "connection timed out" / "Failed to fetch" (but the same works on the host), when a packer-lxd image build fails during "apt update", when LXD container networking breaks right after installing Docker, or when iptables shows "policy DROP" on FORWARD with an empty DOCKER-USER chain. The LXD bridge already has ipv4.nat=true and net.ipv4.ip_forward=1 — it is purely a FORWARD-chain drop, not a NAT or DN

mac-mini-as-headless-server

Use when setting up a Mac (especially Mac Mini) for unattended 24/7 server operation, headless use, or remote-only access. Covers sleep prevention, screen saver, Wake-on-LAN, auto-restart, App Nap, and SSH enablement.

ssh-keychain-unlock

Use when Claude Code auth fails over SSH on macOS, keychain is locked in headless/remote sessions, or setting up Claude Code on a Mac for remote access

swe-workflow

Orchestrates the full five-stage flow from raw idea to shipped PR — grill-with-docs → to-prd → to-issues → triage → worktree+planning-with-files. Each stage answers one question (What do I want? / What does done look like? / What are the units of work? / What's actionable? / Build it). Use when the user has an idea but no spec yet, wants to plan a feature end-to-end, says "let's PRD this," asks "how do I start on this idea?", or grabs a ready-for-agent issue to implement.

to-features

Generate FEATURES.md at the repo root by reading CONTEXT.md and docs/adr/, then enumerating the user-facing features the domain implies. Use after /grill-with-docs has settled the domain language and before /to-prd writes per-feature specs. Bridges the product→engineering gap between domain understanding and feature specification — the missing step that mattpocock's chain doesn't cover natively.

ubuntu-lxd-gpu-server

Install LXD on an Ubuntu server and pass all NVIDIA GPUs into LXD system containers via CDI — install snapd+LXD (snap), run `lxd init` with a ZFS or dir storage pool, set up a host CDI spec at /etc/cdi and wire the nvidia-container-toolkit auto-refresh units so it stays fresh across driver upgrades, and grant every GPU to every instance through the default profile, then verify nvidia-smi inside a container. Use when asked to install or set up LXD/lxc on a GPU host, give LXD containers GPU access, do LXD NVIDIA GPU passthrough, share all GPUs across LXD instances, when `nvidia.runtime=true` fails with "driver rpc error: timed out" (use CDI instead), or when LXD GPU containers break after a host driver upgrade (stale or duplicate CDI spec). Assumes the host NVIDIA driver + nvidia-container-toolkit are already installed (see ubuntu-nvidia-gpu-enablement).

ubuntu-nvidia-gpu-enablement

Enable NVIDIA GPUs on a Ubuntu server for compute/inference serving — install the open-kernel-module driver (required for Blackwell/Hopper), CUDA toolkit, turn on IOMMU (intel_iommu=on iommu=pt), set up nvidia-persistenced, and install/wire a container runtime (Docker + nvidia-container-toolkit, or the minimal CLI), then verify all GPUs, IOMMU groups, P2P, nvcc, and GPU containers. Use when asked to enable or set up NVIDIA GPUs, install the NVIDIA driver + CUDA on Ubuntu, install Docker + nvidia-container-toolkit for GPU containers, configure GPU IOMMU/passthrough, prepare a host for GPU serving (vLLM/PyTorch/TensorRT/NIM), or troubleshoot nouveau, persistence mode, GPU-in-container, or driver/CUDA/glibc problems.

ubuntu-zfs-mirror-install

Install Ubuntu Server onto a 2-disk ZFS mirror root (rpool→/) plus a striped data pool (dpool→/data) via debootstrap + ZFSBootMenu, or fall back to a plain single-disk ext4 install (GRUB-EFI) when there aren't two equal-size disks. Use when asked to install Ubuntu on ZFS, build a ZFS mirror root / rpool+dpool layout, set up root-on-ZFS with ZFSBootMenu, or do a scripted Ubuntu Server install on a UEFI x86 server with one or two SSDs/NVMes.