[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71CGVW37MR6N92M0WVNP314":3,"skill-same:01M71CGVW37MR6N92M0WVNP314":65},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M71CGVW37MR6N92M0WVNP314","cogbox-packages",null,"Get a missing tool or language library, keep tools across restarts, or change services, environment variables or other NixOS configuration through a plugin module, and find out who installs it.","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-packages\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"cogbox packages","packages","it","language","Tools","Variables","keep","configuration","nixos","environment variables","library","module","missing","tool","environment","find","get","services","change","plugin","2026-11-10 10:12:30",false,"---\nname: cogbox-packages\ndescription: Get a missing tool or language library, keep tools across restarts, or change services, environment variables or other NixOS configuration through a plugin module, and find out who installs it.\n---\n\nCheck first with `command -v \u003Ctool>`, using the command name and not the package name. The base image already gives you `git`, `curl`, `jq`, `rg` (ripgrep), `fd`, `bat`, `sd`, `yq` (yq-go), `duckdb`, `mlr` (miller), `dasel`, `gron`, `datamash`, `jo`, `xh`, `websocat`, `dig` (dnsutils), `htmlq`, `pup`, the moreutils commands (`sponge`, `ts`, `chronic`, `ifne`, `vipe`), `tmux`, `vim`, `htop` and `ncdu`, plus the harness launchers and `herdr`. Installed plugins add tools of their own, and on the container backend a shell that is neither a login shell nor started by a harness launcher can miss them, so `command -v` in the shell you are actually using is the check, not this list.\n\nFor one-off use, run it straight from nixpkgs. Flakes and `nix-command` are enabled in the guest, and `cache.nixos.org` is configured as a binary cache:\n\n- `nix run nixpkgs#\u003Cpkg> -- \u003Cargs>` for a single invocation.\n- `nix shell nixpkgs#\u003Cpkg> -c \u003Ccmd>` to run one command with it on PATH.\n- `nix shell nixpkgs#a nixpkgs#b` for an interactive subshell.\n\nSay what that costs, and do not overstate it. The writable nix store layer is\nnot storage, but how long it lasts depends on the backend: a VM-backed sandbox\nre-creates that filesystem before each launch, so anything fetched this way is\ndownloaded again after a restart, while on the container backend the\nper-instance overlay upper is node-local and usually survives a restart until a\nreschedule onto another node loses it. `nix profile install` writes to that same\nlayer and changes none of it. Egress applies either way: in `none` network mode\nthe fetch fails outright, and in `rules` mode it depends on the host's policy.\nRead the actual error instead of guessing which applies. If the tool has to be\nthere reliably, extend the sandbox rather than re-running `nix shell`.\n\nIf `command -v cogbox-env` finds the helper, this sandbox can also keep tools across restarts without a plugin or a restart, as the `cogbox-runtime` skill describes.\n\nTo make a tool permanent and reproducible, extend the sandbox. Read\n`\u002Frun\u002Fcogbox\u002Fenvironment.json` first, as `cogbox-environment` describes, and\nchoose the route for the reported mode:\n\n- `cogworx`: a plugin is installed by the sandbox's owner or an admin. Ask the user to arrange it; do not try it from inside the sandbox, and never run `cogbox` here even where it is on PATH.\n  - The installer uses the sandbox's Plugins tab (a flake or archive URL, or an uploaded archive) or, where enabled, the cogworx API or the Ask Cogworx chat. When the installer is not an admin, the plugin's network rules can wait for an admin's approval.\n  - Its module loads at the sandbox's next restart (or next start, if it is stopped), and a restart ends every session in the sandbox, this one included, so leave the timing to the user. Where the deployment has turned live plugin apply on for this sandbox (some VM-backed sandboxes only), a plugin change to a running sandbox is loaded into it without a restart when that is safe, which leaves sessions open; a change the sandbox proves broken is rolled back automatically, and any other change waits for the restart, though where the deployment allows it the owner or an admin can apply some of those anyway, which can end sessions.\n  - A plugin you wrote must be fetchable by whoever installs it: push it, with every file it uses committed, to a git repository the user chooses and the installer can fetch, or give them an archive of its directory (`.tar.gz` or `.zip`) to upload. Give the user the exact URL to install, with `?dir=\u003Csubdir>` when the flake is not at the repository root.\n- `local`: tell the user to run `cogbox plugin add \u003Cflake-url>` on their host (with `-n \u003Cname>` unless the instance is `default`), or to edit the per-instance flake at `~\u002F.config\u002Fcogbox\u002Finstances\u002F\u003Cname>\u002Fflake\u002Fflake.nix` there. An edit to that flake loads at the instance's next start, or after `cogbox restart` (add `-n \u003Cname>` unless the instance is `default`) if it is running, which ends every session in it, this one included. A plugin added to a stopped instance also loads at its next start; `cogbox plugin add` run in a terminal on the host while the instance runs loads the plugin into it live, without a restart, when it can do so safely (a plugin the sandbox proves broken is rolled back automatically), and otherwise says to restart. Never run a host-side `cogbox` command inside this guest.\n\n## Writing a plugin\n\nA plugin is a flake exposing two outputs: `nixosModules.\u003Cattr>`, the guest NixOS\nmodule, and `cogboxPlugins.\u003Cattr>`, a thin `{ module; networkRules; l7Rules;\ninject; }` registration. `cogbox plugin add URL#attr` resolves the\n`cogboxPlugins` attr and imports its `.module`, so a flake carrying only\n`nixosModules.default` does not install; `module` itself is optional for a\npure-policy plugin that ships only network or credential policy.\n\nA plugin module is an ordinary NixOS module and gets this sandbox's own `pkgs`, so it needs no nixpkgs input. For example, `flake.nix` at the root of the plugin's directory:\n\n```nix\n{\n  outputs = { self }: {\n    nixosModules.default = { pkgs, ... }: {\n      cogbox.packages = [ pkgs.hyperfine ];    # CLI tools\n      cogbox.contents = .\u002Fcontents;            # skills in contents\u002Fskills\u002F\u003Cname>\u002FSKILL.md\n      environment.variables.NOTES_DIR = \"\u002Froot\u002Fwork\u002Fnotes\";\n      systemd.services.notes-server = {\n        wantedBy = [ \"multi-user.target\" ];\n        after = [ \"cogbox-brain-materialize.service\" ];  # ~\u002Fwork is in place\n        script = ''\n          mkdir -p \u002Froot\u002Fwork\u002Fnotes\n          exec ${pkgs.python3}\u002Fbin\u002Fpython3 -m http.server 3090 --bind 127.0.0.1 --directory \u002Froot\u002Fwork\u002Fnotes\n        '';\n      };\n    };\n    cogboxPlugins.default = {\n      module = self.nixosModules.default;\n      l7Rules = [ { allow = \"api.example.com\"; } ];   # egress it needs (optional)\n    };\n  };\n}\n```\n\nShip a plugin's CLI tools through `cogbox.packages`: they reach PATH on every backend, and on the container they arrive with the plugin's skills, so they can be there on a boot that lacks the rest of the module. An interpreter with the libraries a project imports ships the same way, for example `cogbox.packages = [ (pkgs.python3.withPackages (ps: [ ps.requests ])) ];`. Everything else the module sets (`environment.systemPackages`, `systemd.services`, `environment.variables`, any other NixOS option) is built into a VM-backed sandbox at its next start. A container sandbox has it only while it boots its own per-instance system, which cogworx normally builds when the plugin is installed, so it can be missing for a boot after an image change or a failed build; a rebuild in the background then normally restores it at the following restart (`journalctl -u cogbox-toplevel-reconcile` shows that rebuild).\n\n- Keep the module small, with packages you know build: on a VM-backed sandbox a newly added module that fails to evaluate or build keeps the sandbox from starting until the plugin is removed or fixed. A container sandbox still starts, without that module, and when the module does not evaluate or a `cogbox.packages` entry does not build, also without any plugin's skills and without some or all of their `cogbox.packages` tools (`journalctl -u cogbox-brain-materialize` says why).\n- Leave sshd and the sandbox's own `cogbox-*` units as they are; ordering your own service after one of them, as below, is fine. On a VM-backed sandbox, a module that starts sshd only on demand (`services.openssh.startWhenNeeded`) or disables `cogbox-boot-stamp.service` can keep the sandbox from ever becoming ready, and a restart does not help until the plugin is removed or fixed.\n- On a VM-backed sandbox, a download that one of the module's derivations makes while it builds (`pkgs.fetchurl`, `pkgs.fetchgit` and the like) runs outside the sandbox, on the machine that builds its system. This sandbox's network allows, the plugin's own `networkRules` and `l7Rules`, and the credentials the host adds to this sandbox's requests do not apply to it, and that machine may be barred from internal addresses. So a source this sandbox can reach, such as a private repository or an internal server, can still fail to download there, and a failed download is a failed build (above). Use public sources, or commit the file into the plugin itself.\n- Keep anything a service has to keep under `\u002Froot\u002Fwork`, and order the service after `cogbox-brain-materialize.service`, which puts `~\u002Fwork` in place. `\u002Froot` is private (mode 0700), so that works for a service that runs as root, like the example; one that runs as its own user, as most NixOS `services.*` modules do (PostgreSQL among them), cannot reach it, so tell the user that such a service's state will not survive a restart and let them decide; never loosen `\u002Froot`. Do not keep service state elsewhere, such as `\u002Fvar\u002Flib\u002F\u003Cname>`: most of the guest does not survive a restart (`cogbox-filesystem`).\n- `environment.variables` sets a variable for login shells and for commands run as `ssh \u003Csandbox> cmd`, VS Code Remote-SSH included; a systemd service needs its own `systemd.services.\u003Cname>.environment`. `cogbox.env` sets one only for a harness started through its launcher and the commands that harness runs.\n- `cogbox.contents` installs each `contents\u002Fskills\u002F\u003Cname>\u002FSKILL.md` as the skill `\u003Cname>`, whose `name:` frontmatter must match, or as `\u003Cplugin>-\u003Cname>` when another plugin ships the same name. Give it a name of its own: `cogbox-plugins` is reserved, and a skill named like one this sandbox already ships is replaced by that one.\n- `networkRules` (CIDR ranges) and `l7Rules` (hostnames) declare the egress the plugin needs, and `inject` a host-side credential; all three are optional. Never put a token or password in the module (`cogbox.env` and `environment.variables` included) or in the plugin's URL: the module ends up in the world-readable Nix store and in the plugin's source. A credential goes through `inject`, which only names a secret. Nothing is added until the user binds that secret's value outside the sandbox (in `cogworx` mode on the sandbox's Plugins tab, which marks the unbound ones; in `local` mode with `cogbox secret add` on the host), and the host side then adds it to matching requests, so never ask for the value inside the sandbox.\n- `docs\u002Fplugins.md` in the cogbox source documents the rest, including `cogbox.mcp`, `cogbox.hooks` and the rule formats; if you need it, ask the user for it rather than guessing where it is.\n\n`environment.systemPackages` also works in a per-instance extension flake in `local` mode, paired with `system.extraDependencies` when build-time dependencies must be realized locally too.\n","Check first with `command -v \u003Ctool>`, using the command name and not the package name. The base image already gives you `git`, `curl`, `jq`, `rg` (ripgrep), `fd`, `bat`, `sd`, `yq` (yq-go), `duckdb`, `mlr` (miller), `dasel`, `gron`, `datamash`, `jo`, `xh`, `websocat`, `dig` (dnsutils), `htmlq`, `pup`, the moreutils commands (`sponge`, `ts`, `chronic`, `ifne`, `vipe`), `tmux`, `vim`, `htop` and `ncdu`, plus the harness launchers and `herdr`. Installed plugins add tools of their own, and on the container backend a shell that is neither a login shell nor started by a harness launcher can miss them, so `command -v` in the shell you are actually using is the check, not this list.\n\nFor one-off use, run it straight from nixpkgs. Flakes and `nix-command` are enabled in the guest, and `cache.nixos.org` is configured as a binary cache:\n\n- `nix run nixpkgs#\u003Cpkg> -- \u003Cargs>` for a single invocation.\n- `nix shell nixpkgs#\u003Cpkg> -c \u003Ccmd>` to run one command with it on PATH.\n- `nix shell nixpkgs#a nixpkgs#b` for an interactive subshell.\n\nSay what that costs, and do not overstate it. The writable nix store layer is\nnot storage, but how long it lasts depends on the backend: a VM-backed sandbox\nre-creates that filesystem before each launch, so anything fetched this way is\ndownloaded again after a restart, while on the container backend the\nper-instance overlay upper is node-local and usually survives a restart until a\nreschedule onto another node loses it. `nix profile install` writes to that same\nlayer and changes none of it. Egress applies either way: in `none` network mode\nthe fetch fails outright, and in `rules` mode it depends on the host's policy.\nRead the actual error instead of guessing which applies. If the tool has to be\nthere reliably, extend the sandbox rather than re-running `nix shell`.\n\nIf `command -v cogbox-env` finds the helper, this sandbox can also keep tools across restarts without a plugin or a restart, as the `cogbox-runtime` skill describes.\n\nTo make a tool permanent and reproducible, extend the sandbox. Read\n`\u002Frun\u002Fcogbox\u002Fenvironment.json` first, as `cogbox-environment` describes, and\nchoose the route for the reported mode:\n\n- `cogworx`: a plugin is installed by the sandbox's owner or an admin. Ask the user to arrange it; do not try it from inside the sandbox, and never run `cogbox` here even where it is on PATH.\n  - The installer uses the sandbox's Plugins tab (a flake or archive URL, or an uploaded archive) or, where enabled, the cogworx API or the Ask Cogworx chat. When the installer is not an admin, the plugin's network rules can wait for an admin's approval.\n  - Its module loads at the sandbox's next restart (or next start, if it is stopped), and a restart ends every session in the sandbox, this one included, so leave the timing to the user. Where the deployment has turned live plugin apply on for this sandbox (some VM-backed sandboxes only), a plugin change to a running sandbox is loaded into it without a restart when that is safe, which leaves sessions open; a change the sandbox proves broken is rolled back automatically, and any other change waits for the restart, though where the deployment allows it the owner or an admin can apply some of those anyway, which can end sessions.\n  - A plugin you wrote must be fetchable by whoever installs it: push it, with every file it uses committed, to a git repository the user chooses and the installer can fetch, or give them an archive of its directory (`.tar.gz` or `.zip`) to upload. Give the user the exact URL to install, with `?dir=\u003Csubdir>` when the flake is not at the repository root.\n- `local`: tell the user to run `cogbox plugin add \u003Cflake-url>` on their host (with `-n \u003Cname>` unless the instance is `default`), or to edit the per-instance flake at `~\u002F.config\u002Fcogbox\u002Finstances\u002F\u003Cname>\u002Fflake\u002Fflake.nix` there. An edit to that flake loads at the instance's next start, or after `cogbox restart` (add `-n \u003Cname>` unless the instance is `default`) if it is running, which ends every session in it, this one included. A plugin added to a stopped instance also loads at its next start; `cogbox plugin add` run in a terminal on the host while the instance runs loads the plugin into it live, without a restart, when it can do so safely (a plugin the sandbox proves broken is rolled back automatically), and otherwise says to restart. Never run a host-side `cogbox` command inside this guest.\n\n## Writing a plugin\n\nA plugin is a flake exposing two outputs: `nixosModules.\u003Cattr>`, the guest NixOS\nmodule, and `cogboxPlugins.\u003Cattr>`, a thin `{ module; networkRules; l7Rules;\ninject; }` registration. `cogbox plugin add URL#attr` resolves the\n`cogboxPlugins` attr and imports its `.module`, so a flake carrying only\n`nixosModules.default` does not install; `module` itself is optional for a\npure-policy plugin that ships only network or credential policy.\n\nA plugin module is an ordinary NixOS module and gets this sandbox's own `pkgs`, so it needs no nixpkgs input. For example, `flake.nix` at the root of the plugin's directory:\n\n```nix\n{\n  outputs = { self }: {\n    nixosModules.default = { pkgs, ... }: {\n      cogbox.packages = [ pkgs.hyperfine ];    # CLI tools\n      cogbox.contents = .\u002Fcontents;            # skills in contents\u002Fskills\u002F\u003Cname>\u002FSKILL.md\n      environment.variables.NOTES_DIR = \"\u002Froot\u002Fwork\u002Fnotes\";\n      systemd.services.notes-server = {\n        wantedBy = [ \"multi-user.target\" ];\n        after = [ \"cogbox-brain-materialize.service\" ];  # ~\u002Fwork is in place\n        script = ''\n          mkdir -p \u002Froot\u002Fwork\u002Fnotes\n          exec ${pkgs.python3}\u002Fbin\u002Fpython3 -m http.server 3090 --bind 127.0.0.1 --directory \u002Froot\u002Fwork\u002Fnotes\n        '';\n      };\n    };\n    cogboxPlugins.default = {\n      module = self.nixosModules.default;\n      l7Rules = [ { allow = \"api.example.com\"; } ];   # egress it needs (optional)\n    };\n  };\n}\n```\n\nShip a plugin's CLI tools through `cogbox.packages`: they reach PATH on every backend, and on the container they arrive with the plugin's skills, so they can be there on a boot that lacks the rest of the module. An interpreter with the libraries a project imports ships the same way, for example `cogbox.packages = [ (pkgs.python3.withPackages (ps: [ ps.requests ])) ];`. Everything else the module sets (`environment.systemPackages`, `systemd.services`, `environment.variables`, any other NixOS option) is built into a VM-backed sandbox at its next start. A container sandbox has it only while it boots its own per-instance system, which cogworx normally builds when the plugin is installed, so it can be missing for a boot after an image change or a failed build; a rebuild in the background then normally restores it at the following restart (`journalctl -u cogbox-toplevel-reconcile` shows that rebuild).\n\n- Keep the module small, with packages you know build: on a VM-backed sandbox a newly added module that fails to evaluate or build keeps the sandbox from starting until the plugin is removed or fixed. A container sandbox still starts, without that module, and when the module does not evaluate or a `cogbox.packages` entry does not build, also without any plugin's skills and without some or all of their `cogbox.packages` tools (`journalctl -u cogbox-brain-materialize` says why).\n- Leave sshd and the sandbox's own `cogbox-*` units as they are; ordering your own service after one of them, as below, is fine. On a VM-backed sandbox, a module that starts sshd only on demand (`services.openssh.startWhenNeeded`) or disables `cogbox-boot-stamp.service` can keep the sandbox from ever becoming ready, and a restart does not help until the plugin is removed or fixed.\n- On a VM-backed sandbox, a download that one of the module's derivations makes while it builds (`pkgs.fetchurl`, `pkgs.fetchgit` and the like) runs outside the sandbox, on the machine that builds its system. This sandbox's network allows, the plugin's own `networkRules` and `l7Rules`, and the credentials the host adds to this sandbox's requests do not apply to it, and that machine may be barred from internal addresses. So a source this sandbox can reach, such as a private repository or an internal server, can still fail to download there, and a failed download is a failed build (above). Use public sources, or commit the file into the plugin itself.\n- Keep anything a service has to keep under `\u002Froot\u002Fwork`, and order the service after `cogbox-brain-materialize.service`, which puts `~\u002Fwork` in place. `\u002Froot` is private (mode 0700), so that works for a service that runs as root, like the example; one that runs as its own user, as most NixOS `services.*` modules do (PostgreSQL among them), cannot reach it, so tell the user that such a service's state will not survive a restart and let them decide; never loosen `\u002Froot`. Do not keep service state elsewhere, such as `\u002Fvar\u002Flib\u002F\u003Cname>`: most of the guest does not survive a restart (`cogbox-filesystem`).\n- `environment.variables` sets a variable for login shells and for commands run as `ssh \u003Csandbox> cmd`, VS Code Remote-SSH included; a systemd service needs its own `systemd.services.\u003Cname>.environment`. `cogbox.env` sets one only for a harness started through its launcher and the commands that harness runs.\n- `cogbox.contents` installs each `contents\u002Fskills\u002F\u003Cname>\u002FSKILL.md` as the skill `\u003Cname>`, whose `name:` frontmatter must match, or as `\u003Cplugin>-\u003Cname>` when another plugin ships the same name. Give it a name of its own: `cogbox-plugins` is reserved, and a skill named like one this sandbox already ships is replaced by that one.\n- `networkRules` (CIDR ranges) and `l7Rules` (hostnames) declare the egress the plugin needs, and `inject` a host-side credential; all three are optional. Never put a token or password in the module (`cogbox.env` and `environment.variables` included) or in the plugin's URL: the module ends up in the world-readable Nix store and in the plugin's source. A credential goes through `inject`, which only names a secret. Nothing is added until the user binds that secret's value outside the sandbox (in `cogworx` mode on the sandbox's Plugins tab, which marks the unbound ones; in `local` mode with `cogbox secret add` on the host), and the host side then adds it to matching requests, so never ask for the value inside the sandbox.\n- `docs\u002Fplugins.md` in the cogbox source documents the rest, including `cogbox.mcp`, `cogbox.hooks` and the rule formats; if you need it, ask the user for it rather than guessing where it is.\n\n`environment.systemPackages` also works in a per-instance extension flake in `local` mode, paired with `system.extraDependencies` when build-time dependencies must be realized locally too.\n",{"name":5,"description":7},"master","9054adffa53fa7af94439dff72b432e11499a008","skills\u002Fcogbox-packages",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":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add illustris\u002Fcogbox --skill cogbox-packages",{"tool":57,"command":58},"bunx","bunx skills add illustris\u002Fcogbox --skill cogbox-packages",{"tool":60,"command":61},"pnpm","pnpm dlx skills add illustris\u002Fcogbox --skill cogbox-packages","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fillustris\u002Fcogbox\u002Fblob\u002Fmaster\u002Fskills\u002Fcogbox-packages\u002FSKILL.md",true,[],[66,81,94,108,121,129],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":38},"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",[],[73,74,75,76,77,37,78,79,80],"app","app relay","relay","guidance","migration","Legacy","for","testing",{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":38},"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",[],[88,89,90,91,92,93],"overview","demo overview","demo","questions","backend","start",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":38},"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",[],[90,101,102,103,104,105,106,107],"es","demo es","search","query","cat","cluster","elasticsearch",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":38},"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",[],[115,116,117,118,79,119,120],"cogbox plugins","plugins","fixture","index","name","fixture skill",{"skillNo":122,"name":116,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":126,"publishedAt":38},"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",[],[116,120,117,37,127,128],"unrelated","second",{"skillNo":130,"name":116,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":38},"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",[],[116,117,135,37,120],"as"]