Migrate a Claude Cowork session from one Windows machine to another with full history, working file links, and no truncated-transcript rendering bug. Use this whenever the user mentions moving, importing, copying, or migrating a Cowork session/conversation/project between machines, or troubleshoots symptoms of a broken import like "session shows blank", "only the latest messages show", "scratchpad files don't open", "can't scroll past the last compaction", or "Loaded N messages (truncated via tail/compaction)" in the Cowork log. Covers orphan sessions on Windows to Windows under the same Cowork account. Handles the undocumented two-layer compact_boundary truncation filter in app.asar that silently clips imported transcripts. Does not handle Cowork Spaces/Projects, Linux/macOS, or cross-account migration.
Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, update or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy.
Onboard a macOS host (Tahoe / macOS 26 and later) as a Tailscale client of a self-hosted headscale control plane. Covers Tailscale.app installation via Homebrew Cask, the NetworkExtension permission grants required for the daemon to start, the conflict that arises if the brew formula `tailscale` is also installed alongside the cask, how to use `tailscale up --login-server` with a headscale preauth key, the deep-link fallback flow when the CLI cannot reach the daemon, the headscale-specific gotcha that `headscale preauthkeys create --user <N>` expects a numeric user ID rather than a username on recent builds, and bidirectional reach verification once joined. Use when adding a macOS host to a headscale-controlled mesh, troubleshooting symptoms like "failed to connect to local tailscale service", Tailscale.app stuck on "Starting...", `tailscale up` hanging on "joining <coordinator>", a blank menu-bar icon after a fresh install, deciding between the Homebrew cask and formula distributions, or recovering from a st
Comprehensive reference for the GL-iNet Slate 7 travel router (model GL-BE3600, Wi-Fi 7). Covers hardware specs, 2.5G ports, touchscreen interface, full admin panel menu structure, VPN client setup (WireGuard/OpenVPN; NordVPN, Mullvad, Surfshark, and 30+ providers), WireGuard/OpenVPN server setup, AdGuard Home, Tor, Tailscale, DDNS, network modes (Router/AP/Extender/WDS/Drop-in Gateway), SSH/CLI access with command reference, factory reset, firmware update, and U-Boot bricked-device recovery. Also covers the JSON-RPC admin API at /rpc (challenge/response auth, module/method discovery, reusable bash helper), programmatic WireGuard server provisioning via the wg-server module (add_peer, generate_peer, settings, leak verification, local-only Endpoint pattern), and Linux client-side WG with overlay-VPN stacking — including the two leak modes that appear when running Tailscale on top of a full-tunnel WG client (fwmark 0x80000 bypass and wg-quick catch-all shadowing the tailnet routes) plus the wg-quick PostUp/PreD
This skill should be used when the user asks about "MLX serving", "mlx_lm.server", "oMLX", "Apple Silicon LLM serving", or "local LLM on Mac" — and when troubleshooting symptoms like model fails to load, OOM during load or inference, server hangs or crashes at batch>1, tool calls returning as plaintext content, throughput regression, or choosing between mlx-lm and oMLX. Also applies to oMLX feature-flag tuning ("turboquant_kv", "dflash", "MTP", "specprefill", "thinking_budget", "max-concurrent-requests", "force_sampling"), OptiQ proxy for models exceeding RAM, Llama-4 ChunkedKVCache batch handling, Llama-3 tool-call JSON format ("name"/"parameters"), and bench-driven validation of serving configs. For Apple Silicon (M-series) only — not for cloud LLM hosting (Bedrock, OpenAI API, Anthropic API), not for non-MLX backends (llama.cpp, Ollama, vLLM), not for model training.
This skill should be used when the user asks about "Lima", "limactl", "lima.yaml", "lima start", "lima shell", "creating a Linux VM on Mac", "running Linux on Apple Silicon", "macOS Linux VM", "Apple Silicon VM", or wants to "install Lima", "configure a Lima VM", "edit lima config", "spin up an Ubuntu VM on my Mac", or "use Lima to run Docker on macOS". Also applies for "lima vmType vz", "lima vz vs qemu", "host.lima.internal", "socket_vmnet", "lima networking", "lima shared network", "lima bridged network", "virtiofs mount", "9p mount", "lima port forward", "lima mount writable", "limactl edit", "limactl validate", "limactl template", "lima Rosetta", "running x86 in lima", "lima debug startup", or any task involving spinning up, configuring, troubleshooting, or shelling into a Lima VM on an Apple Silicon Mac. Use this skill whenever Lima is mentioned even if the user doesn't explicitly ask for "help" — the right configuration choices (vz vs qemu, mount type, network mode) are non-obvious and easy to get wron
Produce architecture documentation for technical audiences using established frameworks — the C4 model for system structure (Context / Container / Component / Code), Architectural Decision Records (ADRs) for capturing the why behind significant design choices, OpenAPI for HTTP API specifications, and system / component design documents for engineers who need to build against or reason about the architecture. Use when someone asks to document system architecture, write an ADR, capture an architectural decision, generate C4 diagrams (context / container / component), produce an OpenAPI spec, draft a component design doc, or document how services integrate. Trigger phrases include "create a C4 diagram", "write an ADR for X", "document the architecture", "specify the API", "OpenAPI spec for", "system design doc", "decision record", "architecture overview". Not for: end-user-facing docs (use the `aeo-docs:diataxis` skill instead — tutorials, how-tos, references, explanations live there), README content, or code-le
Author user-facing technical documentation following the Diataxis framework — tutorials, how-to guides, reference material, and conceptual explanations. Picks the right of the four documentation modes for the request, applies that mode's structural template, and avoids cross-mode bleed (no comprehensive API listings inside a tutorial, no learning exercises inside reference docs, no step-by-step procedures inside an explanation). Use whenever someone asks to document something for users, write a getting-started guide, generate an API or config or CLI reference, write a deployment / migration / troubleshooting guide, explain a design decision, or produce any docs that will live in `docs/`. Trigger phrases include "write a tutorial", "create a how-to", "document the API", "explain why we chose", "generate config docs", "build a reference", "write user docs for X", and any open-ended request to produce user-facing documentation. Not for: README content, code comments, architecture / C4 / ADR / OpenAPI work (use `