$npx -y skills add SJTU-IPADS/SkVM --skill skvm-generalDrive the skvm CLI on behalf of a user to profile models, AOT-compile skills, run skill-assisted tasks, run benchmarks, and manage compiled proposals. Trigger when the user asks to "profile", "aot-compile", "bench", "run a single ad-hoc task with a skill", or asks about skvm prop
| 1 | # SkVM General Usage |
| 2 | |
| 3 | You are driving `skvm`, a CLI that AOT-compiles and runs LLM agent skills across heterogeneous models. Use this skill when the user wants to *use* skvm — profile a model, AOT-compile a skill, run a task with a skill, run a benchmark, or manage optimization proposals. Do **not** invent flags — every example below uses the real flag set from the installed `skvm` binary. |
| 4 | |
| 5 | ## Step 1: Prerequisite self-check |
| 6 | |
| 7 | Split the check in two — the binary must always be present, but the API key is only required for commands that call an LLM. |
| 8 | |
| 9 | **Always required** — skvm is on PATH: |
| 10 | |
| 11 | ```bash |
| 12 | skvm --help >/dev/null 2>&1 || { echo "skvm not installed — tell the user to run: curl -fsSL https://skillvm.ai/install.sh | sh"; exit 1; } |
| 13 | ``` |
| 14 | |
| 15 | **Required only before LLM-calling commands** — `profile` (without `--list`), `aot-compile`, `pipeline`, `run`, `bench`, `jit-optimize`. Local filesystem commands (`profile --list`, `proposals list|show|reject`, `logs`, `clean-jit`) do **not** need the API key — run them even if the key is unset. |
| 16 | |
| 17 | ```bash |
| 18 | # Before running profile/aot-compile/run/bench/jit-optimize: |
| 19 | test -n "${OPENROUTER_API_KEY:-}" || { echo "OPENROUTER_API_KEY is not set — ask the user for their key"; exit 1; } |
| 20 | ``` |
| 21 | |
| 22 | If a required prerequisite is missing, **stop** and tell the user what is missing. Do not install anything yourself. |
| 23 | |
| 24 | ## Step 2: Profile a model |
| 25 | |
| 26 | A profile (TCP — Target Capability Profile) records what an LLM can do across 26 primitive capabilities. It is the input for AOT compilation and is cached so subsequent compile calls reuse it. |
| 27 | |
| 28 | ```bash |
| 29 | skvm profile --model=<id> # profile one model |
| 30 | skvm profile --model=<id1>,<id2> --concurrency=4 # profile several in parallel |
| 31 | skvm profile --model=<id> --adapter=opencode # non-default adapter |
| 32 | skvm profile --model=<id> --force # ignore cache, re-run |
| 33 | skvm profile --list # list cached profiles |
| 34 | ``` |
| 35 | |
| 36 | Notes: |
| 37 | - Default adapter is `bare-agent`. Other valid adapters: `opencode`, `openclaw`, `hermes`, `jiuwenclaw`. |
| 38 | - Cache lives at `$SKVM_PROFILES_DIR` (default `.skvm/profiles/`). |
| 39 | - Profiling is expensive — confirm with the user before running on several models, and prefer `--concurrency` over sequential runs. |
| 40 | |
| 41 | ## Step 3: AOT-compile a skill |
| 42 | |
| 43 | AOT compilation rewrites a skill's `SKILL.md` (and optionally bundle files) so it fits a specific target model's capability profile. The three-pass AOT compiler runs by default. |
| 44 | |
| 45 | ```bash |
| 46 | skvm aot-compile --skill=<path> --model=<id> # all three passes |
| 47 | skvm aot-compile --skill=<path> --model=<id> --pass=1,2,3 # explicit |
| 48 | skvm aot-compile --skill=<path> --model=<id> --pass=1 # only pass 1 (SCR + gap analysis) |
| 49 | skvm aot-compile --skill=<path> --model=<id> --dry-run # no write |
| 50 | skvm pipeline --skill=<path> --model=<id> # profile-if-needed → aot-compile |
| 51 | ``` |
| 52 | |
| 53 | Pass semantics: |
| 54 | - `--pass=1` — SCR extraction, gap analysis, capability substitution/compensation |
| 55 | - `--pass=2` — dependency manifest + env-binding script generation |
| 56 | - `--pass=3` — workflow decomposition + DAG parallelism extraction |
| 57 | |
| 58 | Compiled variants land under the proposals tree (`proposals/aot-compile/...`). Multiple passes can be combined in any subset: `--pass=1,3` runs passes 1 and 3, skipping 2. |
| 59 | |
| 60 | ## Step 4: Run a single task with a skill |
| 61 | |
| 62 | For ad-hoc debugging of one skill on one task: |
| 63 | |
| 64 | ```bash |
| 65 | skvm run --task=<path/to/task.json> --model=<id> # no skill |
| 66 | skvm run --task=<path> --model=<id> --skill=<path/to/SKILL.md> # with skill |
| 67 | skvm run --task=<path> --model=<id> --adapter=opencode --verbose # explicit adapter + debug |
| 68 | ``` |
| 69 | |
| 70 | Use this to reproduce a single failing task or validate a skill edit. Do **not** use it for benchmarking — use `skvm bench` instead. |
| 71 | |
| 72 | ## Step 5: Bench a skill |
| 73 | |
| 74 | Benchmarking runs a skill across many tasks and condition variants. It can get expensive fast — always confirm with the user before running across many models or tasks, and use `--concurrency` for parallelism. |
| 75 | |
| 76 | ```bash |
| 77 | skvm bench --model=<id> # all conditions, all tasks |
| 78 | skvm bench --model=<id> --conditions=original,aot-compiled # baseline + compiled |
| 79 | skvm bench --model=<id> --conditions=jit-optimized # use latest jit-optimize best round |
| 80 | skvm bench --model=<id> --conditions=jit-boost --jit-runs=5 # 5 warmup runs for solidification |
| 81 | skvm bench --model=<id1>,<id2> --conc |