[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71CH0VK3086N4QF07J73E2F":3,"skill-same:01M71CH0VK3086N4QF07J73E2F":63},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":6,"updatedAt":48,"install":49,"resources":62},"01M71CH0VK3086N4QF07J73E2F","cogbox-runtime",null,"Keep command-line tools, or an interpreter with a project's libraries, in this sandbox across restarts with cogbox-env, switch between tool sets, roll back, and recover the tools after a restart.","illustris\u002Fcogbox","illustris","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F3948275?v=4","01M71CGEWJV83CKXRREGQKXXQH","01M71CGEXJJK2726RZ2EJDC1PM",3,"MIT","https:\u002F\u002Fgithub.com\u002Fillustris\u002Fcogbox\u002Fblob\u002Fmaster\u002Fskills\u002Fcogbox-runtime\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"cogbox runtime","runtime","restart","Tools","line","command","libraries","with","across","env","keep","sandbox","command-line","tool","project","switch","interpreter","back","2026-11-10 10:12:30",false,"---\nname: cogbox-runtime\ndescription: Keep command-line tools, or an interpreter with a project's libraries, in this sandbox across restarts with cogbox-env, switch between tool sets, roll back, and recover the tools after a restart.\n---\n\n`cogbox-env` puts one Nix-built bundle of executables first on PATH and keeps an archive of its full closure in `~\u002Fwork`, so the same tools come back after a restart without network access. Choose the route that fits:\n\n- One-off use: `nix shell nixpkgs#\u003Cpkg> -c \u003Ccmd>`, as `cogbox-packages` describes. Nothing to clean up, but it is fetched again after a restart.\n- Tools this sandbox should keep across restarts: a `cogbox-env` bundle, below. Takes effect without a restart.\n- A shared, reviewed extension that also carries services, skills or network policy: a plugin, as `cogbox-packages` describes. A plugin loads at the sandbox's next restart, or, where live plugin apply is available, into the running sandbox when that is safe.\n\nA bundle only provides executables. It sets no environment variables, starts no services, supplies no libraries to other programs and changes no network policy. For a language library, bundle an interpreter that already contains it, such as `(pkgs.python3.withPackages (ps: [ ps.requests ]))` in `paths`, or keep a virtualenv or `node_modules` under `~\u002Fwork`, made with an interpreter from the bundle, and keep that interpreter in the selected bundle so it still works after a restart.\n\n## Build a bundle\n\nGive the bundle its own directory, for example `~\u002Fwork\u002Ftools\u002Fflake.nix`:\n\n```nix\n{\n  inputs.nixpkgs.url = \"nixpkgs\";\n  outputs = { self, nixpkgs }: let\n    pkgs = nixpkgs.legacyPackages.x86_64-linux;\n  in {\n    packages.x86_64-linux.default = pkgs.buildEnv {\n      name = \"project-tools\";\n      paths = [ pkgs.jq pkgs.ripgrep ];\n      pathsToLink = [ \"\u002Fbin\" ];\n    };\n  };\n}\n```\n\nLock the flake against the nixpkgs this sandbox's image was built from, which is already in the store, then prepare it:\n\n```sh\nnix flake lock --flake-registry \u002Fetc\u002Fnix\u002Fregistry.json \"path:$(realpath ~\u002Fwork\u002Ftools)\"\ncogbox-env prepare --flake \"path:$(realpath ~\u002Fwork\u002Ftools)\" --attribute packages.x86_64-linux.default\n```\n\nKeep `--flake-registry \u002Fetc\u002Fnix\u002Fregistry.json` on every `nix flake lock` and `nix flake update` of a bundle. Nix resolves a flake input named `\"nixpkgs\"` through the global registry only, which by default is downloaded and names the latest nixpkgs-unstable: without the flag, locking needs the network (it fails in `none` network mode) and the bundle is built from a different nixpkgs than the image. With it, `nixpkgs` locks offline to the image's nixpkgs. That file names only `nixpkgs` and the flag makes it the only registry for inputs, so give every other input a direct reference, such as `github:numtide\u002Fflake-utils` rather than `flake-utils`. If an existing `flake.lock` locks `nixpkgs` to anything but a `\"type\": \"path\"` entry under `\u002Fnix\u002Fstore` (it was locked without the flag, or copied from elsewhere), `nix flake lock` keeps it: the bundle builds from another nixpkgs, and its next prepare after a stop and start needs the network to fetch that nixpkgs again. Unless the user chose that nixpkgs on purpose, run the `nix flake update nixpkgs` command below once.\n\n`prepare` never creates or updates `flake.lock` and does not consult registries. An input that would need a registry, such as `nixpkgs` with no lock entry, fails. An input you added with a direct URL, or whose URL you edited, without locking again is locked in memory for that one prepare and fetched (stderr shows `not writing modified lock file`), so the bundle is built from inputs `flake.lock` does not record. `nix flake lock` locks new inputs and inputs whose URL you edited and leaves every other entry as it is, so run it again after changing inputs. When a prepare cannot find the locked nixpkgs (after an image upgrade, or with a `flake.lock` written in another sandbox), `nix flake lock` changes nothing: re-resolve it with `nix flake update nixpkgs --flake-registry \u002Fetc\u002Fnix\u002Fregistry.json --flake \"path:$(realpath ~\u002Fwork\u002Ftools)\"`. Without the flag, `nix flake update nixpkgs` fetches the global nixpkgs-unstable instead. Always pass the `path:` and `realpath` form: `~\u002Fwork` is a symlink, a `path:` source must not go through one, and inside a git checkout a bare `nix flake lock` refuses a `flake.nix` that git does not track. The bundle must contain a `bin` directory and must not ship its own `cogbox-env`.\n\n`prepare` builds the bundle and archives it but changes nothing on PATH. Let `prepare` do the building: do not run your own `nix build`, `nix eval` or `nix flake check` of a bundle, neither to check it first nor afterwards. Each of those reads the image's whole nixpkgs source again and can take 2 to 4 minutes here, while `prepare` avoids that. Every command except `exec` prints one JSON envelope (`ok`, `error.code`, `error.message`, `status`) and exits 0 only when `ok` is true; a successful prepare reports the new id in `generation`.\n\n## Select, roll back, clear\n\nEvery change to the selection is a compare-and-swap against the current selection token, which `cogbox-env status` reports as `selection` (`null` when nothing is selected):\n\n```sh\ncogbox-env status\ncogbox-env apply --generation GENERATION --expected-selection none    # first selection\ncogbox-env apply --generation GENERATION --expected-selection TOKEN   # later ones\ncogbox-env rollback --expected-selection TOKEN\ncogbox-env clear --expected-selection TOKEN\n```\n\n- `stale_selection` means the selection changed since you read it. Run `status` again and decide again.\n- The selected bundle is the complete set of bundle tools. A tool left out of the new bundle disappears from it (the base image or a plugin may still provide that name).\n- `rollback` switches to the generation that was selected before the current one. It is one level: a second rollback returns to where you started.\n- `clear` removes the selection, so only base and plugin tools remain. Prepared generations stay, and `apply` can select one again.\n- `apply` and `rollback` restore a generation from its archive by themselves, offline, when its closure is missing.\n\n## Where the tools resolve\n\n`\u002Froot\u002Fwork\u002F.cogbox\u002Fruntime\u002Fcurrent\u002Fbin` comes first on PATH, ahead of plugin and base tools, in login shells, new tmux panes and the harness launchers. A command run as `ssh \u003Csandbox> cmd` gets it too, because the bash that sshd starts reads `\u002Fetc\u002Fbashrc`, which loads the login profile. In a shell that already looked a name up, run `hash -r`. Wrap any command that does not see the bundle's tools as `cogbox-env exec -- CMD ARGS`. A program that is already running keeps the version it started with.\n\n## After a restart\n\n`cogbox-runtime-restore.service` restores the selected bundle offline, in the background, after the sandbox has booted. It never delays login. Until it finishes, bundle tools can be missing, and after a stop and start a login shell warns that the selected tools are not active. Check:\n\n- `cogbox-env status`: the tools are usable when `active_generation` equals `selected_generation`. `boot_restore` records the last boot restore: `outcome` is `active`, `restored` or `failed`, with an error `code` when it failed. It describes this boot only when its `boot_id` equals `status.boot_id`; otherwise this boot's restore was skipped, killed, or could not write its record (see `systemctl status cogbox-runtime-restore`). A manual `cogbox-env restore` after a failed boot restore makes the tools active again, but `boot_restore` and the failed unit keep showing that boot's failure until the next boot.\n- `systemctl status cogbox-runtime-restore` and `journalctl -u cogbox-runtime-restore`. A failed restore leaves a line `cogbox-runtime-restore: error: CODE: MESSAGE` there; the journal is the only place that keeps the message.\n\nJust after a reboot from inside the sandbox, the bundle files are still on disk but are rewritten in place while the restore runs. For that time a bundle tool can briefly fail with a missing file, and `status` can answer `timed_out` because the restore holds the state lock. How long depends on how much of the bundle is not already in the base image: a bundle adding under a megabyte showed no failures, while one adding a 250 MB toolchain took about 18 seconds to restore, with its tools missing for 1 to 2 seconds at a time. Wait until `systemctl list-jobs cogbox-runtime-restore.service` shows no job (the restore has finished, failed or been skipped), then read `status.boot_restore`. Do not run `prepare` or `apply` in the meantime.\n\nIf the boot restore failed with `invalid_archive`, run the same `prepare` command again, which repairs the archive from the closure, then `cogbox-env restore`. A `--flake` prepare builds the closure again by itself. An `--import-store-path` prepare needs that output registered in the store, and after any restart it no longer is (after a stop and start its files are gone too), so the repeat answers `unavailable_closure` even when `ls` still shows the output: build or copy the output into the store again first, then repeat the prepare. For any other code, report the code and the message from that journal line to the user. Only if the user asks to stop automatic restores, `touch ~\u002Fwork\u002F.cogbox\u002Fruntime\u002Fdisable-boot-restore`; removing that file turns them back on.\n\n## Disk limits\n\nArchives share `~\u002Fwork`, the filesystem that holds the user's work, so they are bounded. `status.limits` reports the values for this sandbox:\n\n- At most 4 generations are kept. The oldest ones beyond that, never the selected or the previous one, are dropped automatically after `apply`, `rollback` or `clear`, and `prepare` drops them too when it needs room.\n- All archives together stay within 8 GiB or a quarter of that filesystem, whichever is smaller.\n- `prepare` leaves at least 2 GiB or a tenth of that filesystem free, whichever is larger.\n- A single store path larger than 1 GiB is refused.\n\n`insufficient_space` from `prepare` means nothing was dropped. Free room with `cogbox-env prune --generation GENERATION` for a generation that is no longer needed (never the selected one; `clear` first if it is), or make the bundle smaller. `cogbox-env prune` with no generation drops generations whose manifest is damaged (never the selected one), enforces the limit and removes leftovers of interrupted operations. It removes nothing else, and never drops a generation because its archive alone is damaged: run that generation's `prepare` again, which repairs it.\n\n## Network and credentials\n\n`prepare` is the only step that may fetch from the network. In `none` network mode it can use only what is already in the store, so it fails unless everything the bundle needs to build is there. A bundle that needed a download failed quickly, with `prepare_failed` in about 15 seconds and nothing published, and Nix's stderr shows that download failing under an `error:` line. The `warning: unable to download` lines about the binary cache do not tell you that by themselves: they can also appear when a prepare succeeds or fails for another reason. Retrying will not help a bundle that needs a download; tell the user it needs network access. A small bundle that could be built from what the store already held prepared in 20 to 30 seconds; one that has to compile something takes as long as that build. `apply`, `rollback`, `restore`, `clear` and `prune` work offline. For a private input, use a `git+http:\u002F\u002F` or `git+https:\u002F\u002F` URL, whichever scheme the git host serves (`cogbox-git`), that the sandbox's git access can already fetch. Never put a token in a flake reference, `flake.nix`, `flake.lock` or `nix.conf`. `cogbox-env` refuses a `--flake` reference that carries credentials, meaning anything with `user@` after `:\u002F\u002F`, including `git+ssh:\u002F\u002Fgit@...`.\n\n## Rules\n\n- Never edit, move or delete anything under `~\u002Fwork\u002F.cogbox\u002Fruntime` by hand. The only file you may create there is the kill switch above, and only when the user asks.\n- After any error, a timeout or `status_unavailable` (the selection change happened but could not be confirmed), run `cogbox-env status` before retrying anything.\n- On `corrupt_state`, stop and report it to the user. Do not delete state to make the error go away.\n- Never delete, recreate or re-provision the sandbox to fix a tool problem.\n","`cogbox-env` puts one Nix-built bundle of executables first on PATH and keeps an archive of its full closure in `~\u002Fwork`, so the same tools come back after a restart without network access. Choose the route that fits:\n\n- One-off use: `nix shell nixpkgs#\u003Cpkg> -c \u003Ccmd>`, as `cogbox-packages` describes. Nothing to clean up, but it is fetched again after a restart.\n- Tools this sandbox should keep across restarts: a `cogbox-env` bundle, below. Takes effect without a restart.\n- A shared, reviewed extension that also carries services, skills or network policy: a plugin, as `cogbox-packages` describes. A plugin loads at the sandbox's next restart, or, where live plugin apply is available, into the running sandbox when that is safe.\n\nA bundle only provides executables. It sets no environment variables, starts no services, supplies no libraries to other programs and changes no network policy. For a language library, bundle an interpreter that already contains it, such as `(pkgs.python3.withPackages (ps: [ ps.requests ]))` in `paths`, or keep a virtualenv or `node_modules` under `~\u002Fwork`, made with an interpreter from the bundle, and keep that interpreter in the selected bundle so it still works after a restart.\n\n## Build a bundle\n\nGive the bundle its own directory, for example `~\u002Fwork\u002Ftools\u002Fflake.nix`:\n\n```nix\n{\n  inputs.nixpkgs.url = \"nixpkgs\";\n  outputs = { self, nixpkgs }: let\n    pkgs = nixpkgs.legacyPackages.x86_64-linux;\n  in {\n    packages.x86_64-linux.default = pkgs.buildEnv {\n      name = \"project-tools\";\n      paths = [ pkgs.jq pkgs.ripgrep ];\n      pathsToLink = [ \"\u002Fbin\" ];\n    };\n  };\n}\n```\n\nLock the flake against the nixpkgs this sandbox's image was built from, which is already in the store, then prepare it:\n\n```sh\nnix flake lock --flake-registry \u002Fetc\u002Fnix\u002Fregistry.json \"path:$(realpath ~\u002Fwork\u002Ftools)\"\ncogbox-env prepare --flake \"path:$(realpath ~\u002Fwork\u002Ftools)\" --attribute packages.x86_64-linux.default\n```\n\nKeep `--flake-registry \u002Fetc\u002Fnix\u002Fregistry.json` on every `nix flake lock` and `nix flake update` of a bundle. Nix resolves a flake input named `\"nixpkgs\"` through the global registry only, which by default is downloaded and names the latest nixpkgs-unstable: without the flag, locking needs the network (it fails in `none` network mode) and the bundle is built from a different nixpkgs than the image. With it, `nixpkgs` locks offline to the image's nixpkgs. That file names only `nixpkgs` and the flag makes it the only registry for inputs, so give every other input a direct reference, such as `github:numtide\u002Fflake-utils` rather than `flake-utils`. If an existing `flake.lock` locks `nixpkgs` to anything but a `\"type\": \"path\"` entry under `\u002Fnix\u002Fstore` (it was locked without the flag, or copied from elsewhere), `nix flake lock` keeps it: the bundle builds from another nixpkgs, and its next prepare after a stop and start needs the network to fetch that nixpkgs again. Unless the user chose that nixpkgs on purpose, run the `nix flake update nixpkgs` command below once.\n\n`prepare` never creates or updates `flake.lock` and does not consult registries. An input that would need a registry, such as `nixpkgs` with no lock entry, fails. An input you added with a direct URL, or whose URL you edited, without locking again is locked in memory for that one prepare and fetched (stderr shows `not writing modified lock file`), so the bundle is built from inputs `flake.lock` does not record. `nix flake lock` locks new inputs and inputs whose URL you edited and leaves every other entry as it is, so run it again after changing inputs. When a prepare cannot find the locked nixpkgs (after an image upgrade, or with a `flake.lock` written in another sandbox), `nix flake lock` changes nothing: re-resolve it with `nix flake update nixpkgs --flake-registry \u002Fetc\u002Fnix\u002Fregistry.json --flake \"path:$(realpath ~\u002Fwork\u002Ftools)\"`. Without the flag, `nix flake update nixpkgs` fetches the global nixpkgs-unstable instead. Always pass the `path:` and `realpath` form: `~\u002Fwork` is a symlink, a `path:` source must not go through one, and inside a git checkout a bare `nix flake lock` refuses a `flake.nix` that git does not track. The bundle must contain a `bin` directory and must not ship its own `cogbox-env`.\n\n`prepare` builds the bundle and archives it but changes nothing on PATH. Let `prepare` do the building: do not run your own `nix build`, `nix eval` or `nix flake check` of a bundle, neither to check it first nor afterwards. Each of those reads the image's whole nixpkgs source again and can take 2 to 4 minutes here, while `prepare` avoids that. Every command except `exec` prints one JSON envelope (`ok`, `error.code`, `error.message`, `status`) and exits 0 only when `ok` is true; a successful prepare reports the new id in `generation`.\n\n## Select, roll back, clear\n\nEvery change to the selection is a compare-and-swap against the current selection token, which `cogbox-env status` reports as `selection` (`null` when nothing is selected):\n\n```sh\ncogbox-env status\ncogbox-env apply --generation GENERATION --expected-selection none    # first selection\ncogbox-env apply --generation GENERATION --expected-selection TOKEN   # later ones\ncogbox-env rollback --expected-selection TOKEN\ncogbox-env clear --expected-selection TOKEN\n```\n\n- `stale_selection` means the selection changed since you read it. Run `status` again and decide again.\n- The selected bundle is the complete set of bundle tools. A tool left out of the new bundle disappears from it (the base image or a plugin may still provide that name).\n- `rollback` switches to the generation that was selected before the current one. It is one level: a second rollback returns to where you started.\n- `clear` removes the selection, so only base and plugin tools remain. Prepared generations stay, and `apply` can select one again.\n- `apply` and `rollback` restore a generation from its archive by themselves, offline, when its closure is missing.\n\n## Where the tools resolve\n\n`\u002Froot\u002Fwork\u002F.cogbox\u002Fruntime\u002Fcurrent\u002Fbin` comes first on PATH, ahead of plugin and base tools, in login shells, new tmux panes and the harness launchers. A command run as `ssh \u003Csandbox> cmd` gets it too, because the bash that sshd starts reads `\u002Fetc\u002Fbashrc`, which loads the login profile. In a shell that already looked a name up, run `hash -r`. Wrap any command that does not see the bundle's tools as `cogbox-env exec -- CMD ARGS`. A program that is already running keeps the version it started with.\n\n## After a restart\n\n`cogbox-runtime-restore.service` restores the selected bundle offline, in the background, after the sandbox has booted. It never delays login. Until it finishes, bundle tools can be missing, and after a stop and start a login shell warns that the selected tools are not active. Check:\n\n- `cogbox-env status`: the tools are usable when `active_generation` equals `selected_generation`. `boot_restore` records the last boot restore: `outcome` is `active`, `restored` or `failed`, with an error `code` when it failed. It describes this boot only when its `boot_id` equals `status.boot_id`; otherwise this boot's restore was skipped, killed, or could not write its record (see `systemctl status cogbox-runtime-restore`). A manual `cogbox-env restore` after a failed boot restore makes the tools active again, but `boot_restore` and the failed unit keep showing that boot's failure until the next boot.\n- `systemctl status cogbox-runtime-restore` and `journalctl -u cogbox-runtime-restore`. A failed restore leaves a line `cogbox-runtime-restore: error: CODE: MESSAGE` there; the journal is the only place that keeps the message.\n\nJust after a reboot from inside the sandbox, the bundle files are still on disk but are rewritten in place while the restore runs. For that time a bundle tool can briefly fail with a missing file, and `status` can answer `timed_out` because the restore holds the state lock. How long depends on how much of the bundle is not already in the base image: a bundle adding under a megabyte showed no failures, while one adding a 250 MB toolchain took about 18 seconds to restore, with its tools missing for 1 to 2 seconds at a time. Wait until `systemctl list-jobs cogbox-runtime-restore.service` shows no job (the restore has finished, failed or been skipped), then read `status.boot_restore`. Do not run `prepare` or `apply` in the meantime.\n\nIf the boot restore failed with `invalid_archive`, run the same `prepare` command again, which repairs the archive from the closure, then `cogbox-env restore`. A `--flake` prepare builds the closure again by itself. An `--import-store-path` prepare needs that output registered in the store, and after any restart it no longer is (after a stop and start its files are gone too), so the repeat answers `unavailable_closure` even when `ls` still shows the output: build or copy the output into the store again first, then repeat the prepare. For any other code, report the code and the message from that journal line to the user. Only if the user asks to stop automatic restores, `touch ~\u002Fwork\u002F.cogbox\u002Fruntime\u002Fdisable-boot-restore`; removing that file turns them back on.\n\n## Disk limits\n\nArchives share `~\u002Fwork`, the filesystem that holds the user's work, so they are bounded. `status.limits` reports the values for this sandbox:\n\n- At most 4 generations are kept. The oldest ones beyond that, never the selected or the previous one, are dropped automatically after `apply`, `rollback` or `clear`, and `prepare` drops them too when it needs room.\n- All archives together stay within 8 GiB or a quarter of that filesystem, whichever is smaller.\n- `prepare` leaves at least 2 GiB or a tenth of that filesystem free, whichever is larger.\n- A single store path larger than 1 GiB is refused.\n\n`insufficient_space` from `prepare` means nothing was dropped. Free room with `cogbox-env prune --generation GENERATION` for a generation that is no longer needed (never the selected one; `clear` first if it is), or make the bundle smaller. `cogbox-env prune` with no generation drops generations whose manifest is damaged (never the selected one), enforces the limit and removes leftovers of interrupted operations. It removes nothing else, and never drops a generation because its archive alone is damaged: run that generation's `prepare` again, which repairs it.\n\n## Network and credentials\n\n`prepare` is the only step that may fetch from the network. In `none` network mode it can use only what is already in the store, so it fails unless everything the bundle needs to build is there. A bundle that needed a download failed quickly, with `prepare_failed` in about 15 seconds and nothing published, and Nix's stderr shows that download failing under an `error:` line. The `warning: unable to download` lines about the binary cache do not tell you that by themselves: they can also appear when a prepare succeeds or fails for another reason. Retrying will not help a bundle that needs a download; tell the user it needs network access. A small bundle that could be built from what the store already held prepared in 20 to 30 seconds; one that has to compile something takes as long as that build. `apply`, `rollback`, `restore`, `clear` and `prune` work offline. For a private input, use a `git+http:\u002F\u002F` or `git+https:\u002F\u002F` URL, whichever scheme the git host serves (`cogbox-git`), that the sandbox's git access can already fetch. Never put a token in a flake reference, `flake.nix`, `flake.lock` or `nix.conf`. `cogbox-env` refuses a `--flake` reference that carries credentials, meaning anything with `user@` after `:\u002F\u002F`, including `git+ssh:\u002F\u002Fgit@...`.\n\n## Rules\n\n- Never edit, move or delete anything under `~\u002Fwork\u002F.cogbox\u002Fruntime` by hand. The only file you may create there is the kill switch above, and only when the user asks.\n- After any error, a timeout or `status_unavailable` (the selection change happened but could not be confirmed), run `cogbox-env status` before retrying anything.\n- On `corrupt_state`, stop and report it to the user. Do not delete state to make the error go away.\n- Never delete, recreate or re-provision the sandbox to fix a tool problem.\n",{"name":5,"description":7},"master","9054adffa53fa7af94439dff72b432e11499a008","skills\u002Fcogbox-runtime",1,"https:\u002F\u002Fgithub.com\u002Fillustris\u002Fcogbox","https:\u002F\u002Fgithub.com\u002Fillustris","https:\u002F\u002Fillustris.tech","2026-11-10 00:38:16",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add illustris\u002Fcogbox --skill cogbox-runtime",{"tool":55,"command":56},"bunx","bunx skills add illustris\u002Fcogbox --skill cogbox-runtime",{"tool":58,"command":59},"pnpm","pnpm dlx skills add illustris\u002Fcogbox --skill cogbox-runtime","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fillustris\u002Fcogbox\u002Fblob\u002Fmaster\u002Fskills\u002Fcogbox-runtime\u002FSKILL.md",true,[],[64,80,93,107,120,128],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":36},"01M71CHP4B6XX9PAZ5JRQV8E58","app-relay","Legacy plugin guidance for migration testing.","https:\u002F\u002Fgithub.com\u002Fillustris\u002Fcogbox\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fnative-app\u002Flegacy-contents\u002Fskills\u002Fapp-relay\u002FSKILL.md",[],[71,72,73,74,75,76,77,78,79],"app","app relay","relay","guidance","migration","plugin","Legacy","for","testing",{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":36},"01M71CHM675ZZTJ9HRGHPWVVZS","demo-overview","Overview of the demo backend; start here before answering demo questions.","https:\u002F\u002Fgithub.com\u002Fillustris\u002Fcogbox\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fbrain-plugin\u002Fcontents\u002Fskills\u002Fdemo-overview\u002FSKILL.md",[],[87,88,89,90,91,92],"overview","demo overview","demo","questions","backend","start",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":36},"01M71CHJNH0AX8E74WBGJH1JMR","demo-es","Query the demo Elasticsearch cluster: es-search, es-cat.","https:\u002F\u002Fgithub.com\u002Fillustris\u002Fcogbox\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fbrain-plugin\u002Fcontents\u002Fskills\u002Fdemo-es\u002FSKILL.md",[],[89,100,101,102,103,104,105,106],"es","demo es","search","query","cat","cluster","elasticsearch",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":36},"01M71CHGPNHSBFJHCQRSMNHS3E","cogbox-plugins","Fixture skill squatting on the name cogbox reserves for its index.","https:\u002F\u002Fgithub.com\u002Fillustris\u002Fcogbox\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fbrain-collide\u002Freserved\u002Fskills\u002Fcogbox-plugins\u002FSKILL.md",[],[114,115,116,117,78,118,119],"cogbox plugins","plugins","fixture","index","name","fixture skill",{"skillNo":121,"name":115,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":36},"01M71CHERNF4GWZ1C34MHKKN19","Fixture skill named `plugins`, shipped by a second, unrelated plugin.","https:\u002F\u002Fgithub.com\u002Fillustris\u002Fcogbox\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fbrain-collide\u002Freserved-qual-b\u002Fskills\u002Fplugins\u002FSKILL.md",[],[115,119,116,76,126,127],"unrelated","second",{"skillNo":129,"name":115,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":36},"01M71CHDPMR9KDE5QP6H3W66CW","Fixture skill named `plugins`, shipped by a plugin installed as `cogbox`.","https:\u002F\u002Fgithub.com\u002Fillustris\u002Fcogbox\u002Fblob\u002Fmaster\u002Ftests\u002Ffixtures\u002Fbrain-collide\u002Freserved-qual-a\u002Fskills\u002Fplugins\u002FSKILL.md",[],[115,116,134,76,119],"as"]