[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M75HTKSS3KGDK7PT6KAXTPPY":3,"skill-same:01M75HTKSS3KGDK7PT6KAXTPPY":93},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":31,"ownerDescription":6,"updatedAt":32,"install":33,"resources":46},"01M75HTKSS3KGDK7PT6KAXTPPY","docker-sandboxes-env",null,"Use this skill when creating, updating, reviewing, planning, or running a declarative `sbxenv.yaml` file for Docker Sandboxes (`sbx env plan\u002Fcreate\u002Frun\u002Fexec\u002Frm`), even if the user just says \"check in a sandbox config\", \"set up this project for sbx env\", \"which kits should this project's sbxenv use\", \"bump or pin the kits in my sbxenv\", or \"run a setup script before the agent starts\". Covers composing an agent workload and v3 mixin kits chosen from the live Docker Hub catalog with the bundled `scripts\u002Fkits.py` helper, kit and environment `args`, secrets\u002Fregistries\u002Fbindings, workspace and mounts, `entrypoint`\u002F`cmd`, ports, MCP servers, `sandboxOptions` (including `writableEnvFiles`), host `lifecycle` commands and the approval plan, multi-file merge, and the `~\u002F.sbxenv.yaml` user defaults.","stanfish06\u002Fskillquarium","stanfish06","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F93099613?v=4","01M75F1CK4ZW109ZK3T26VN52F","Zhiyuan","01M75F1CM53VH6F79DZ8GXKKES",12,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fdocker-sandboxes-env\u002FSKILL.md",[],[],"2026-11-12 13:55:43",false,"---\nname: docker-sandboxes-env\ndescription: Use this skill when creating, updating, reviewing, planning, or running a declarative `sbxenv.yaml` file for Docker Sandboxes (`sbx env plan\u002Fcreate\u002Frun\u002Fexec\u002Frm`), even if the user just says \"check in a sandbox config\", \"set up this project for sbx env\", \"which kits should this project's sbxenv use\", \"bump or pin the kits in my sbxenv\", or \"run a setup script before the agent starts\". Covers composing an agent workload and v3 mixin kits chosen from the live Docker Hub catalog with the bundled `scripts\u002Fkits.py` helper, kit and environment `args`, secrets\u002Fregistries\u002Fbindings, workspace and mounts, `entrypoint`\u002F`cmd`, ports, MCP servers, `sandboxOptions` (including `writableEnvFiles`), host `lifecycle` commands and the approval plan, multi-file merge, and the `~\u002F.sbxenv.yaml` user defaults.\nlicense: Apache-2.0\ncompatibility: Requires standalone sbx with experimental `sbx env` support and sbxenv.yaml schemaVersion \"1\"; help and docs checked against sbx v0.51.0. scripts\u002Fkits.py needs Python 3.9+ and anonymous HTTPS access to Docker Hub (PyYAML only for older YAML descriptors). Provenance is in references\u002Fsources.md.\n---\n\n# Docker Sandboxes: Declarative sbxenv.yaml Environments\n\n## Overview\n\n`sbxenv.yaml` (schemaVersion `\"1\"`, EXPERIMENTAL) declares one local or cloud\nsandbox environment: the agent, the kits composed onto it, workspace mounts,\nenvironment variables, secrets\u002Fregistries\u002Fbindings to provision, MCP servers,\nports, launch command, and host-side lifecycle commands. `sbx env\nplan|create|run|exec|rm` stand it up and tear it down reproducibly instead of a\nlong flag invocation. This skill owns that file end to end: authoring it from\nthe project's signals, refreshing its kit references, and explaining how it is\napplied and approved. Decoding is strict — an unknown key anywhere is an error\n— so check `references\u002Fenv-schema-fields.md` before writing a field you are\nnot sure about.\n\n## When to use this skill\n\nActivate this skill when:\n- The user wants a checked-in, reproducible sandbox environment instead of a\n  long `sbx create`\u002F`sbx run` command line, or asks to scaffold, create, or\n  review an `sbxenv.yaml` or `~\u002F.sbxenv.yaml`.\n- The user wants kits suggested for a project's `sbxenv.yaml`, or wants the\n  kit references in an existing `sbxenv.yaml` upgraded, bumped, or pinned to\n  digests.\n- The user wants host-side setup or teardown commands (cloning a repo,\n  seeding fixtures, archiving state) tied to the environment's lifecycle.\n- The user wants to parameterize a shared environment file with named\n  arguments (`args:` + `--env-arg`).\n- The user is debugging why `sbx env create`\u002F`run` asks for approval, or why a\n  declared change did not take effect on an existing sandbox.\n\n## Do not use this skill when\n\nDo not use this skill when:\n- The task is the underlying `sbx create`\u002F`run`\u002F`rm` flag-based workflow with\n  no `sbxenv.yaml` involved — use `docker-sandboxes-lifecycle`.\n- The task is choosing network policy or storing a secret\u002Fregistry credential\n  independent of any environment file — use\n  `docker-sandboxes-network-credentials`. This file's `secrets:`\u002F\n  `registries:`\u002F`bindings:` provision into that same store; do not redefine\n  its rules here.\n- The task is authoring, building, publishing, or signing the kit descriptor\n  a `kits:` entry references, or composing kits with `sbx run --kit` flags\n  and no environment file — use `docker-sandboxes-kits`. This skill only\n  selects, configures, and pins kits inside an `sbxenv.yaml`.\n\n## Core guidance\n\n### Ground rules when writing or updating a file\n\n- **Look up kits live, every time.** Kits, tags, and digests change daily.\n  Take every kit name, tag, digest, arg, and credential from\n  `scripts\u002Fkits.py` in the current run — never from memory, an earlier\n  conversation, or the examples in this skill. If Docker Hub is unreachable\n  the helper exits nonzero; say so and stop suggesting kits rather than\n  guessing.\n- **Pick the highest version tag, not the one pushed last.** Hub lists tags by\n  last update, and a republished old release or a moving tag (`latest`,\n  `edge`) can sit on top. Use `newestRelease`\u002F`suggested` from `kits.py\n  update`, which ranks dotted versions numerically. Do not write a bare\n  untagged reference or `:latest` when a release tag exists.\n- **Prefer v3 kits.** Search results are v3-only by default. If a file uses a\n  v2 kit (often a `-kit` suffix) and a v3 sibling exists, offer the move.\n- **Never write secret values.** Use `ref:` or `command:`, even if asked for a\n  literal: the file is meant to be committed. A binding approves a\n  credential; it never contains one.\n- **Guide, don't interrogate.** Recommend a concrete choice with a one-line\n  reason at each step, batch related questions, and skip what the workspace\n  already answers.\n- **When updating, edit in place.** Keep the user's comments, ordering, and\n  formatting; change only what the user agreed to.\n\n### The `scripts\u002Fkits.py` helper\n\n`scripts\u002Fkits.py` ships in this skill's directory; substitute the path this\n`SKILL.md` was loaded from for `\u003Cskill-dir>`. It uses only the standard\nlibrary, prints JSON, reads public repositories anonymously, and must be run\nwith `python3 -I`. A nonzero exit means at least one lookup failed: that entry\ncarries `error`, and the other entries remain valid.\n\n| Command | Use |\n|---|---|\n| `kits.py search [TERM …] [--orgs a,b] [--include-v2]` | v3 kits under `sbx\u002F` and `docker\u002F`, ranked by pulls. Each term is a separate Hub search; no term lists the whole catalog for those orgs. |\n| `kits.py describe REF … [--arg [HANDLE.]NAME=VALUE …] [--platform OS\u002FARCH]` | From the live descriptor: `kind`, `agent`, `handle` (what `agent:` uses), `version`, create-phase `args`, `buildArgs`, `buildSecrets`, `credentials` with a `suggestedBinding`, and `hostGrants`. Pass `--platform` for the machine that runs `sbx` if it differs from this one. |\n| `kits.py update REF … [--pin]` | `suggested` = the highest version release tag (or the same moving tag), with a fresh digest when REF was pinned or `--pin` is given; also `newestRelease` and notes such as major bumps. Local and git sources are skipped. |\n| `kits.py pin REF …` | `TAG@DIGEST` for the tag as written. Never changes the release. Pin a tagged reference: an untagged one comes back digest-only for whatever `latest` points to. |\n| `kits.py tags REF` | Every tag with its digest, in Hub last-updated order. Inspect only; never pick a release from the top of this list. |\n\n```bash\npython3 -I \u003Cskill-dir>\u002Fscripts\u002Fkits.py search go github\npython3 -I \u003Cskill-dir>\u002Fscripts\u002Fkits.py update sbx\u002Fplaywright\n```\n\n### Create or update workflow\n\n1. **Decide the mode.** `.\u002Fsbxenv.yaml` exists → update. A project-level\n   `.\u002F.sbxenv.yaml` is **not read** (that name is only the home-directory\n   defaults file); offer to rename it to `sbxenv.yaml`. `~\u002F.sbxenv.yaml` is\n   the user's personal defaults — usually bindings and `sandboxOptions`, not\n   project kits. Nothing exists → create.\n2. **Create:** read only the file listing, manifests, and git remote; turn\n   signals into search terms; `search` and `describe` candidates to\n   shortlist; resolve each kit's `newestRelease` and `describe` that exact\n   reference before configuring it; propose a composition table (kit, kind,\n   tag, why); set kit and environment args from that descriptor;\n   add bindings\u002Fsecrets per credential; set workspace and options; ask tags\n   vs tag+digest; write the file with a prerequisites header; then run the\n   checks.\n3. **Update:** list every `kits:` source and `agent:`; run `kits.py update`\n   on all OCI references in one call; present current → suggested with\n   notes; for each accepted change, `describe` old and new and reconcile\n   args, credentials, host grants, `kind`, and `handle`; apply only accepted\n   edits in place.\n\nThe step-by-step procedure, the workspace-signal table, credential and host\ngrant handling, and the final checklist are in\n`references\u002Fauthoring-workflow.md`. Follow it rather than improvising.\n\n### Composition: `agent:` and `kits:`\n\n- A composition has **exactly one workload** and any number of mixins.\n  `agent:` is either a built-in agent (`claude`, `codex`, `shell`, …) or the\n  name of the agent workload kit listed under `kits:` — its `handle` as\n  `kits.py describe` reports it. To add tools to a built-in agent, keep the\n  built-in name in `agent:` and list only mixins.\n- When both `X` and `X-mixin` exist, the plain kit is the workload and the\n  `-mixin` layers that agent onto another workload. Use the mixin only when\n  the user wants a different base.\n- A mixin's `requires` can under-declare what it needs from the workload:\n  `sbx\u002Fplaywright` reports `requires: []` but its install step needs Node, so\n  on the bare `shell` agent creation fails (`env: 'node': No such file or\n  directory`). Only a disposable `sbx env create` proves a composition; say\n  so when you hand over a file you could not create.\n- An entry is a bare reference or `{source, args}`. Explicit relative paths\n  (`.\u002F…`, `..\u002F…`, `.`, `..`, or ending in `.zip`) resolve against the\n  **declaring file's directory**; a bare `org\u002Fkit` is always a registry\n  reference. Git sources use `git+https:\u002F\u002F` or `git+ssh:\u002F\u002F`; pin them for\n  reproducibility with `#ref=\u003Ccommit>` (plus `&dir=\u003Csubdir>` when needed).\n- A published (OCI) kit accepts only its **create-phase** args. `buildArgs`\n  (typically `version`) were fixed at publish time — choose another tag\n  instead. `buildSecrets` are build inputs, never runtime credentials.\n- Remote kit sources must match the `kit.allowedSources` setting; Docker Hub\n  is allowed by default. Setting it replaces the whole allowlist.\n- `--kit-arg`\u002F`--kit-args-file` and `--env-arg`\u002F`--env-args-file` are\n  experimental flags; mention that when you rely on them.\n\n### File resolution, merging, and user defaults\n\n- From a directory, `sbx env` reads exactly `sbxenv.yaml`. Each `PATH`\n  argument is a directory (→ `\u003CPATH>\u002Fsbxenv.yaml`) or the file itself.\n- Several paths deep-merge in order, `docker compose -f`-style: mappings merge\n  by key, later scalars win, lists concatenate — **except `entrypoint` and\n  `cmd`, which later files replace**, and `kits` entries naming the same\n  source, which fold into one entry with their `args` merged. Each file must\n  be valid on its own; a later file cannot repair an invalid earlier value.\n  ```bash\n  sbx env run base.sbxenv.yaml local.sbxenv.yaml\n  ```\n- With **no `PATH`**, `~\u002F.sbxenv.yaml` is merged underneath the project file;\n  naming any `PATH` skips it. It may not set `name:`, and its `workspace:`\n  must be `${{ env.projectDir }}` or a subdirectory of it.\n- `${{ env.projectDir }}` (directory of the first `PATH`, or cwd) and\n  `${{ env.fileDir }}` (the declaring file's directory) plus\n  `${{ env.args.NAME }}` are the only expansions. A bare `$` is literal, so\n  `PATH: $PATH:\u002Fopt\u002Fbin` reaches the sandbox unchanged; `$${{ … }}` escapes.\n  References cannot appear in field names or inside the `args:` block.\n\n### Naming and workspace\n\n- Without `name:` or `--name`, the sandbox is named\n  `\u003Cagent>-\u003Cworkspace-basename>`, so any two environments with the same agent\n  and the same workspace directory name collide — even in different parent\n  directories. Give each environment an explicit `name:` when that can\n  happen. If you pass `--name`, pass the same value to every `sbx env`\n  command for that environment.\n- `workspace:` is the primary mount (read\u002Fwrite in bind mode); **omitting it\n  mounts nothing**, so an agent would start without the project. The object\n  form `{path: ., clone: true}` mounts the path read-only and runs the agent\n  on a private clone (`--clone`\u002F`--clone=false` override it per\n  invocation). `additionalWorkspaces:` require a primary `workspace:`.\n\n### Where the environment file lives (write protection)\n\n- **Prefer keeping `sbxenv.yaml` outside every directory you mount** — the\n  primary workspace and each `additionalWorkspaces` entry — for example beside\n  the project directory with `workspace: .\u002Fweb-app`. The file decides which\n  lifecycle, secret, and MCP commands run on the host, so the agent must not\n  be able to change it.\n- If it must live inside a mount, put it **directly at the mount root**.\n  `sbx` mounts env files read-only by default, but a file in a\n  **subdirectory** can still be replaced: the sandbox renames the writable\n  parent directory and recreates the path. `sbx env plan` calls this out;\n  never claim the rename creates no gap. (One sbx v0.51.0 macOS test refused\n  that rename — see `checks\u002Fruntime-results.md` — but the plan and docs\n  still treat the file as unprotected, so do not rely on it.)\n- `sandboxOptions.writableEnvFiles: true` lets the sandbox write its own env\n  files (local only). It is a deliberate security downgrade the plan reports;\n  use it only when the agent is meant to change what future invocations run\n  on the host.\n\n### `args:` — parameterizing a shared file\n\n- Each argument needs exactly one of `default` or `required: true`, plus\n  optional `description` and either `enum` or `pattern` (RE2, whole value).\n- Values come only from `--env-arg NAME=VALUE` or `--env-args-file FILE`; the\n  host environment is never read. An undeclared reference, missing required\n  value, unknown supplied name, or failed `enum`\u002F`pattern` is an error.\n- An unquoted reference is re-read as YAML after substitution (`cpus:\n  ${{ env.args.cpus }}` becomes an integer); quote it to keep a string.\n- Use an environment arg for values callers vary (model, target repo, branch)\n  or one value that feeds several kits; pin a project decision directly in\n  the kit entry's `args:`.\n\n### Secrets, registries, and bindings\n\n- `secrets:` and `registries:` provision into the **same credential store** as\n  `sbx secret set`, at this sandbox's scope, so `sbx env rm` removes them.\n  Each source sets exactly one of `value`\u002F`ref`\u002F`command`; see\n  `docker-sandboxes-network-credentials` for runtime semantics.\n- Secret `command:` sources run on the host from a fresh temporary directory\n  and run whenever the secret is needed, even with `--skip-host-commands`.\n  Use absolute helper paths and keep helpers outside writable mounts.\n- `bindings:` merge into the user's **global** `credentials.yaml` and survive\n  `sbx env rm` unless `--prune-bindings` is passed — which deletes the whole\n  global entry for each declared service, possibly affecting other sandboxes.\n  Bind only the mechanism (`apiKey` or `oauth`) the user will actually use.\n- A literal `value:` appears only as a `sha256:` digest in the plan and state,\n  but the file itself still holds the plaintext. Use `ref:` or `command:`;\n  the plan shows where such a secret comes from, never its resolved value.\n  ```yaml\n  # OPTIONAL fragment — add only if this environment needs the credential.\n  secrets:\n    anthropic:\n      ref: op:\u002F\u002FPrivate\u002FAnthropic\u002Fapi-key   # never a literal `value:`\n      refresh: 55m\n  ```\n\n### `lifecycle:` — host commands\n\n- Commands run **on the host, outside the sandbox, with your privileges**,\n  through the user's shell, from the project directory unless `workdir:` is\n  set. Within a phase they run in order and stop at the first failure. They\n  receive `SBX_LIFECYCLE_PHASE`, `SBX_ENV_FILE(S)`, `SBX_ENV_DIR`,\n  `SBX_SANDBOX_NAME`, `SBX_AGENT`, and `SBX_WORKSPACE`, but **not** the file's\n  `env:` values or resolved secrets.\n  - **`initialize`** — before anything else, on **every** `create` and `run`,\n    including a run that attaches to an existing sandbox. It must be\n    idempotent.\n  - **`postCreate`** — once, after a new sandbox is created and before\n    attachment; not on reattach.\n  - **`preRemove`** — after removal is approved, before deletion. A failure is\n    only a warning. Afterwards `sbx` rebuilds the destroy plan and stops if the\n    commands introduced changes the approval did not cover.\n  ```yaml\n  lifecycle:\n    initialize:\n      - command: test -d app || git clone https:\u002F\u002Fgithub.com\u002Facme\u002Fapp\n    postCreate:\n      - command: .\u002Fscripts\u002Fseed-fixtures.sh\n  ```\n- Kits own what runs inside the sandbox; use `lifecycle` only for host-side\n  preparation and teardown.\n\n### The plan and approval\n\n- `sbx env plan [PATH...]` prints what applying would change outside the\n  sandbox — host commands, credentials, bindings, MCP registrations,\n  directories, kits, ports, options, and variables — compared with what was\n  last applied and approved. **It changes, approves, and records nothing.**\n  It also does not resolve kit references: an invented kit or a missing tag\n  plans cleanly. `describe` every OCI reference at the exact tag you write\n  before trusting a clean plan.\n  Margin symbols: `+` add, `~` change, `-` destroy, `>` run a host command\n  again, `!` stop tracking without deleting.\n- `create`, `run`, and `rm` show their plan and ask for approval. Interactive\n  approval is recorded; a later plan with no host commands applies silently\n  until something changes or a resource is missing.\n- Plans with lifecycle commands, credential command sources, or local MCP\n  commands are asked about on **every** invocation by default, even when\n  unchanged. `sbx settings set env.rememberHostCommands true` asks again only\n  when the commands change — never enable it for commands you have not\n  reviewed.\n- `-f`\u002F`--force` approves one `create`\u002F`run` without recording consent (on\n  `rm` it also deletes a sandbox in use). Use it for reviewed, trusted files\n  in automation only — **never for untrusted pull-request content**, because\n  the plan's host commands run with the runner's privileges.\n- `--skip-host-commands` skips lifecycle commands and disables the\n  environment's local MCP commands until a later `env run` without it;\n  credential command sources still run.\n- If `sbx env run` reports a sandbox that \"agrees with everything this\n  environment declares\" but \"nothing was done\", its environment state was\n  lost. Rerun `sbx env run` interactively with the same paths and name and\n  confirm adoption only for the intended sandbox; `--force` never confirms\n  adoption, so automation needs this done interactively first.\n\n### `env exec` and updating an existing environment\n\n- `sbx env exec [PATH...] -- COMMAND` runs no lifecycle commands for an\n  existing sandbox. If the sandbox is missing, it offers to create it only in\n  an interactive terminal (with the normal approval and lifecycle); with\n  non-interactive stdin or `--no-input` it fails (exit 125) — run\n  `sbx env create` first.\n- On an existing sandbox, `sbx env run` applies changed `env` values and\n  reconciles MCP servers, and `entrypoint`\u002F`cmd` take effect on each run.\n  Changes to workspaces, kits, kit host mounts, ports, secrets, bindings, and\n  `sandboxOptions` apply only on the next creation: `sbx env rm`, then create\n  again.\n\n### `mounts:`, `ports:`, `mcp:`, `entrypoint`\u002F`cmd`, and `sandboxOptions:`\n\nThese map onto kit host mounts, `sbx ports --publish`, MCP gateway\nregistrations, the agent launch argv, and `sbx create` options. Exact field\nshapes, defaults, and what `sbx env rm` leaves behind for each are in\n`references\u002Fenv-schema-fields.md`.\n\n## Related skills\n\n- For the `sbx create`\u002F`run`\u002F`rm` flag-based workflow this file wraps, use\n  `docker-sandboxes-lifecycle`.\n- For what `secrets:`\u002F`registries:`\u002F`bindings:` mean at runtime, and for\n  network policy independent of any environment file, use\n  `docker-sandboxes-network-credentials`.\n- For authoring, building, publishing, or signing the v3 kit descriptor a\n  `kits:` entry references, use `docker-sandboxes-kits`.\n\n## References\n\n- `references\u002Fauthoring-workflow.md` — step-by-step create and update\n  procedure, workspace-signal table, credential and host-grant handling, and\n  the final checklist.\n- `references\u002Fenv-schema-fields.md` — every top-level field, its shape and\n  defaults, with YAML examples.\n- `references\u002Fsources.md` — provenance for the rules above.\n\n## Assets\n\n- `assets\u002Fsbxenv.yaml` — a complete, minimal, safe example: a `shell` agent\n  mounting the declaring file's own directory, one static env var, and no\n  credentials — it validates and plans without onboarding authentication.\n  It sits at its mount root; for real projects prefer a file outside the\n  mounts.\n\n## Scripts\n\n- `scripts\u002Fkits.py` — live Docker Hub kit search, descriptor summary,\n  version-ordered update, and digest pinning for `kits:` entries. Run with\n  `python3 -I`; it only reads public registries.\n\n## Checks\n\n- `checks\u002Fverification.md` — verification runbook for the helper and\n  `sbx env` behavior (run manually with an isolated, uniquely named\n  `--app-name` signed in for the run, never with real secret values or\n  untrusted lifecycle commands force-approved).\n- `checks\u002Fruntime-results.md` — recorded results of that runbook on sbx\n  v0.51.0 (macOS arm64), including what the plan does not check.\n","# Docker Sandboxes: Declarative sbxenv.yaml Environments\n\n## Overview\n\n`sbxenv.yaml` (schemaVersion `\"1\"`, EXPERIMENTAL) declares one local or cloud\nsandbox environment: the agent, the kits composed onto it, workspace mounts,\nenvironment variables, secrets\u002Fregistries\u002Fbindings to provision, MCP servers,\nports, launch command, and host-side lifecycle commands. `sbx env\nplan|create|run|exec|rm` stand it up and tear it down reproducibly instead of a\nlong flag invocation. This skill owns that file end to end: authoring it from\nthe project's signals, refreshing its kit references, and explaining how it is\napplied and approved. Decoding is strict — an unknown key anywhere is an error\n— so check `references\u002Fenv-schema-fields.md` before writing a field you are\nnot sure about.\n\n## When to use this skill\n\nActivate this skill when:\n- The user wants a checked-in, reproducible sandbox environment instead of a\n  long `sbx create`\u002F`sbx run` command line, or asks to scaffold, create, or\n  review an `sbxenv.yaml` or `~\u002F.sbxenv.yaml`.\n- The user wants kits suggested for a project's `sbxenv.yaml`, or wants the\n  kit references in an existing `sbxenv.yaml` upgraded, bumped, or pinned to\n  digests.\n- The user wants host-side setup or teardown commands (cloning a repo,\n  seeding fixtures, archiving state) tied to the environment's lifecycle.\n- The user wants to parameterize a shared environment file with named\n  arguments (`args:` + `--env-arg`).\n- The user is debugging why `sbx env create`\u002F`run` asks for approval, or why a\n  declared change did not take effect on an existing sandbox.\n\n## Do not use this skill when\n\nDo not use this skill when:\n- The task is the underlying `sbx create`\u002F`run`\u002F`rm` flag-based workflow with\n  no `sbxenv.yaml` involved — use `docker-sandboxes-lifecycle`.\n- The task is choosing network policy or storing a secret\u002Fregistry credential\n  independent of any environment file — use\n  `docker-sandboxes-network-credentials`. This file's `secrets:`\u002F\n  `registries:`\u002F`bindings:` provision into that same store; do not redefine\n  its rules here.\n- The task is authoring, building, publishing, or signing the kit descriptor\n  a `kits:` entry references, or composing kits with `sbx run --kit` flags\n  and no environment file — use `docker-sandboxes-kits`. This skill only\n  selects, configures, and pins kits inside an `sbxenv.yaml`.\n\n## Core guidance\n\n### Ground rules when writing or updating a file\n\n- **Look up kits live, every time.** Kits, tags, and digests change daily.\n  Take every kit name, tag, digest, arg, and credential from\n  `scripts\u002Fkits.py` in the current run — never from memory, an earlier\n  conversation, or the examples in this skill. If Docker Hub is unreachable\n  the helper exits nonzero; say so and stop suggesting kits rather than\n  guessing.\n- **Pick the highest version tag, not the one pushed last.** Hub lists tags by\n  last update, and a republished old release or a moving tag (`latest`,\n  `edge`) can sit on top. Use `newestRelease`\u002F`suggested` from `kits.py\n  update`, which ranks dotted versions numerically. Do not write a bare\n  untagged reference or `:latest` when a release tag exists.\n- **Prefer v3 kits.** Search results are v3-only by default. If a file uses a\n  v2 kit (often a `-kit` suffix) and a v3 sibling exists, offer the move.\n- **Never write secret values.** Use `ref:` or `command:`, even if asked for a\n  literal: the file is meant to be committed. A binding approves a\n  credential; it never contains one.\n- **Guide, don't interrogate.** Recommend a concrete choice with a one-line\n  reason at each step, batch related questions, and skip what the workspace\n  already answers.\n- **When updating, edit in place.** Keep the user's comments, ordering, and\n  formatting; change only what the user agreed to.\n\n### The `scripts\u002Fkits.py` helper\n\n`scripts\u002Fkits.py` ships in this skill's directory; substitute the path this\n`SKILL.md` was loaded from for `\u003Cskill-dir>`. It uses only the standard\nlibrary, prints JSON, reads public repositories anonymously, and must be run\nwith `python3 -I`. A nonzero exit means at least one lookup failed: that entry\ncarries `error`, and the other entries remain valid.\n\n| Command | Use |\n|---|---|\n| `kits.py search [TERM …] [--orgs a,b] [--include-v2]` | v3 kits under `sbx\u002F` and `docker\u002F`, ranked by pulls. Each term is a separate Hub search; no term lists the whole catalog for those orgs. |\n| `kits.py describe REF … [--arg [HANDLE.]NAME=VALUE …] [--platform OS\u002FARCH]` | From the live descriptor: `kind`, `agent`, `handle` (what `agent:` uses), `version`, create-phase `args`, `buildArgs`, `buildSecrets`, `credentials` with a `suggestedBinding`, and `hostGrants`. Pass `--platform` for the machine that runs `sbx` if it differs from this one. |\n| `kits.py update REF … [--pin]` | `suggested` = the highest version release tag (or the same moving tag), with a fresh digest when REF was pinned or `--pin` is given; also `newestRelease` and notes such as major bumps. Local and git sources are skipped. |\n| `kits.py pin REF …` | `TAG@DIGEST` for the tag as written. Never changes the release. Pin a tagged reference: an untagged one comes back digest-only for whatever `latest` points to. |\n| `kits.py tags REF` | Every tag with its digest, in Hub last-updated order. Inspect only; never pick a release from the top of this list. |\n\n```bash\npython3 -I \u003Cskill-dir>\u002Fscripts\u002Fkits.py search go github\npython3 -I \u003Cskill-dir>\u002Fscripts\u002Fkits.py update sbx\u002Fplaywright\n```\n\n### Create or update workflow\n\n1. **Decide the mode.** `.\u002Fsbxenv.yaml` exists → update. A project-level\n   `.\u002F.sbxenv.yaml` is **not read** (that name is only the home-directory\n   defaults file); offer to rename it to `sbxenv.yaml`. `~\u002F.sbxenv.yaml` is\n   the user's personal defaults — usually bindings and `sandboxOptions`, not\n   project kits. Nothing exists → create.\n2. **Create:** read only the file listing, manifests, and git remote; turn\n   signals into search terms; `search` and `describe` candidates to\n   shortlist; resolve each kit's `newestRelease` and `describe` that exact\n   reference before configuring it; propose a composition table (kit, kind,\n   tag, why); set kit and environment args from that descriptor;\n   add bindings\u002Fsecrets per credential; set workspace and options; ask tags\n   vs tag+digest; write the file with a prerequisites header; then run the\n   checks.\n3. **Update:** list every `kits:` source and `agent:`; run `kits.py update`\n   on all OCI references in one call; present current → suggested with\n   notes; for each accepted change, `describe` old and new and reconcile\n   args, credentials, host grants, `kind`, and `handle`; apply only accepted\n   edits in place.\n\nThe step-by-step procedure, the workspace-signal table, credential and host\ngrant handling, and the final checklist are in\n`references\u002Fauthoring-workflow.md`. Follow it rather than improvising.\n\n### Composition: `agent:` and `kits:`\n\n- A composition has **exactly one workload** and any number of mixins.\n  `agent:` is either a built-in agent (`claude`, `codex`, `shell`, …) or the\n  name of the agent workload kit listed under `kits:` — its `handle` as\n  `kits.py describe` reports it. To add tools to a built-in agent, keep the\n  built-in name in `agent:` and list only mixins.\n- When both `X` and `X-mixin` exist, the plain kit is the workload and the\n  `-mixin` layers that agent onto another workload. Use the mixin only when\n  the user wants a different base.\n- A mixin's `requires` can under-declare what it needs from the workload:\n  `sbx\u002Fplaywright` reports `requires: []` but its install step needs Node, so\n  on the bare `shell` agent creation fails (`env: 'node': No such file or\n  directory`). Only a disposable `sbx env create` proves a composition; say\n  so when you hand over a file you could not create.\n- An entry is a bare reference or `{source, args}`. Explicit relative paths\n  (`.\u002F…`, `..\u002F…`, `.`, `..`, or ending in `.zip`) resolve against the\n  **declaring file's directory**; a bare `org\u002Fkit` is always a registry\n  reference. Git sources use `git+https:\u002F\u002F` or `git+ssh:\u002F\u002F`; pin them for\n  reproducibility with `#ref=\u003Ccommit>` (plus `&dir=\u003Csubdir>` when needed).\n- A published (OCI) kit accepts only its **create-phase** args. `buildArgs`\n  (typically `version`) were fixed at publish time — choose another tag\n  instead. `buildSecrets` are build inputs, never runtime credentials.\n- Remote kit sources must match the `kit.allowedSources` setting; Docker Hub\n  is allowed by default. Setting it replaces the whole allowlist.\n- `--kit-arg`\u002F`--kit-args-file` and `--env-arg`\u002F`--env-args-file` are\n  experimental flags; mention that when you rely on them.\n\n### File resolution, merging, and user defaults\n\n- From a directory, `sbx env` reads exactly `sbxenv.yaml`. Each `PATH`\n  argument is a directory (→ `\u003CPATH>\u002Fsbxenv.yaml`) or the file itself.\n- Several paths deep-merge in order, `docker compose -f`-style: mappings merge\n  by key, later scalars win, lists concatenate — **except `entrypoint` and\n  `cmd`, which later files replace**, and `kits` entries naming the same\n  source, which fold into one entry with their `args` merged. Each file must\n  be valid on its own; a later file cannot repair an invalid earlier value.\n  ```bash\n  sbx env run base.sbxenv.yaml local.sbxenv.yaml\n  ```\n- With **no `PATH`**, `~\u002F.sbxenv.yaml` is merged underneath the project file;\n  naming any `PATH` skips it. It may not set `name:`, and its `workspace:`\n  must be `${{ env.projectDir }}` or a subdirectory of it.\n- `${{ env.projectDir }}` (directory of the first `PATH`, or cwd) and\n  `${{ env.fileDir }}` (the declaring file's directory) plus\n  `${{ env.args.NAME }}` are the only expansions. A bare `$` is literal, so\n  `PATH: $PATH:\u002Fopt\u002Fbin` reaches the sandbox unchanged; `$${{ … }}` escapes.\n  References cannot appear in field names or inside the `args:` block.\n\n### Naming and workspace\n\n- Without `name:` or `--name`, the sandbox is named\n  `\u003Cagent>-\u003Cworkspace-basename>`, so any two environments with the same agent\n  and the same workspace directory name collide — even in different parent\n  directories. Give each environment an explicit `name:` when that can\n  happen. If you pass `--name`, pass the same value to every `sbx env`\n  command for that environment.\n- `workspace:` is the primary mount (read\u002Fwrite in bind mode); **omitting it\n  mounts nothing**, so an agent would start without the project. The object\n  form `{path: ., clone: true}` mounts the path read-only and runs the agent\n  on a private clone (`--clone`\u002F`--clone=false` override it per\n  invocation). `additionalWorkspaces:` require a primary `workspace:`.\n\n### Where the environment file lives (write protection)\n\n- **Prefer keeping `sbxenv.yaml` outside every directory you mount** — the\n  primary workspace and each `additionalWorkspaces` entry — for example beside\n  the project directory with `workspace: .\u002Fweb-app`. The file decides which\n  lifecycle, secret, and MCP commands run on the host, so the agent must not\n  be able to change it.\n- If it must live inside a mount, put it **directly at the mount root**.\n  `sbx` mounts env files read-only by default, but a file in a\n  **subdirectory** can still be replaced: the sandbox renames the writable\n  parent directory and recreates the path. `sbx env plan` calls this out;\n  never claim the rename creates no gap. (One sbx v0.51.0 macOS test refused\n  that rename — see `checks\u002Fruntime-results.md` — but the plan and docs\n  still treat the file as unprotected, so do not rely on it.)\n- `sandboxOptions.writableEnvFiles: true` lets the sandbox write its own env\n  files (local only). It is a deliberate security downgrade the plan reports;\n  use it only when the agent is meant to change what future invocations run\n  on the host.\n\n### `args:` — parameterizing a shared file\n\n- Each argument needs exactly one of `default` or `required: true`, plus\n  optional `description` and either `enum` or `pattern` (RE2, whole value).\n- Values come only from `--env-arg NAME=VALUE` or `--env-args-file FILE`; the\n  host environment is never read. An undeclared reference, missing required\n  value, unknown supplied name, or failed `enum`\u002F`pattern` is an error.\n- An unquoted reference is re-read as YAML after substitution (`cpus:\n  ${{ env.args.cpus }}` becomes an integer); quote it to keep a string.\n- Use an environment arg for values callers vary (model, target repo, branch)\n  or one value that feeds several kits; pin a project decision directly in\n  the kit entry's `args:`.\n\n### Secrets, registries, and bindings\n\n- `secrets:` and `registries:` provision into the **same credential store** as\n  `sbx secret set`, at this sandbox's scope, so `sbx env rm` removes them.\n  Each source sets exactly one of `value`\u002F`ref`\u002F`command`; see\n  `docker-sandboxes-network-credentials` for runtime semantics.\n- Secret `command:` sources run on the host from a fresh temporary directory\n  and run whenever the secret is needed, even with `--skip-host-commands`.\n  Use absolute helper paths and keep helpers outside writable mounts.\n- `bindings:` merge into the user's **global** `credentials.yaml` and survive\n  `sbx env rm` unless `--prune-bindings` is passed — which deletes the whole\n  global entry for each declared service, possibly affecting other sandboxes.\n  Bind only the mechanism (`apiKey` or `oauth`) the user will actually use.\n- A literal `value:` appears only as a `sha256:` digest in the plan and state,\n  but the file itself still holds the plaintext. Use `ref:` or `command:`;\n  the plan shows where such a secret comes from, never its resolved value.\n  ```yaml\n  # OPTIONAL fragment — add only if this environment needs the credential.\n  secrets:\n    anthropic:\n      ref: op:\u002F\u002FPrivate\u002FAnthropic\u002Fapi-key   # never a literal `value:`\n      refresh: 55m\n  ```\n\n### `lifecycle:` — host commands\n\n- Commands run **on the host, outside the sandbox, with your privileges**,\n  through the user's shell, from the project directory unless `workdir:` is\n  set. Within a phase they run in order and stop at the first failure. They\n  receive `SBX_LIFECYCLE_PHASE`, `SBX_ENV_FILE(S)`, `SBX_ENV_DIR`,\n  `SBX_SANDBOX_NAME`, `SBX_AGENT`, and `SBX_WORKSPACE`, but **not** the file's\n  `env:` values or resolved secrets.\n  - **`initialize`** — before anything else, on **every** `create` and `run`,\n    including a run that attaches to an existing sandbox. It must be\n    idempotent.\n  - **`postCreate`** — once, after a new sandbox is created and before\n    attachment; not on reattach.\n  - **`preRemove`** — after removal is approved, before deletion. A failure is\n    only a warning. Afterwards `sbx` rebuilds the destroy plan and stops if the\n    commands introduced changes the approval did not cover.\n  ```yaml\n  lifecycle:\n    initialize:\n      - command: test -d app || git clone https:\u002F\u002Fgithub.com\u002Facme\u002Fapp\n    postCreate:\n      - command: .\u002Fscripts\u002Fseed-fixtures.sh\n  ```\n- Kits own what runs inside the sandbox; use `lifecycle` only for host-side\n  preparation and teardown.\n\n### The plan and approval\n\n- `sbx env plan [PATH...]` prints what applying would change outside the\n  sandbox — host commands, credentials, bindings, MCP registrations,\n  directories, kits, ports, options, and variables — compared with what was\n  last applied and approved. **It changes, approves, and records nothing.**\n  It also does not resolve kit references: an invented kit or a missing tag\n  plans cleanly. `describe` every OCI reference at the exact tag you write\n  before trusting a clean plan.\n  Margin symbols: `+` add, `~` change, `-` destroy, `>` run a host command\n  again, `!` stop tracking without deleting.\n- `create`, `run`, and `rm` show their plan and ask for approval. Interactive\n  approval is recorded; a later plan with no host commands applies silently\n  until something changes or a resource is missing.\n- Plans with lifecycle commands, credential command sources, or local MCP\n  commands are asked about on **every** invocation by default, even when\n  unchanged. `sbx settings set env.rememberHostCommands true` asks again only\n  when the commands change — never enable it for commands you have not\n  reviewed.\n- `-f`\u002F`--force` approves one `create`\u002F`run` without recording consent (on\n  `rm` it also deletes a sandbox in use). Use it for reviewed, trusted files\n  in automation only — **never for untrusted pull-request content**, because\n  the plan's host commands run with the runner's privileges.\n- `--skip-host-commands` skips lifecycle commands and disables the\n  environment's local MCP commands until a later `env run` without it;\n  credential command sources still run.\n- If `sbx env run` reports a sandbox that \"agrees with everything this\n  environment declares\" but \"nothing was done\", its environment state was\n  lost. Rerun `sbx env run` interactively with the same paths and name and\n  confirm adoption only for the intended sandbox; `--force` never confirms\n  adoption, so automation needs this done interactively first.\n\n### `env exec` and updating an existing environment\n\n- `sbx env exec [PATH...] -- COMMAND` runs no lifecycle commands for an\n  existing sandbox. If the sandbox is missing, it offers to create it only in\n  an interactive terminal (with the normal approval and lifecycle); with\n  non-interactive stdin or `--no-input` it fails (exit 125) — run\n  `sbx env create` first.\n- On an existing sandbox, `sbx env run` applies changed `env` values and\n  reconciles MCP servers, and `entrypoint`\u002F`cmd` take effect on each run.\n  Changes to workspaces, kits, kit host mounts, ports, secrets, bindings, and\n  `sandboxOptions` apply only on the next creation: `sbx env rm`, then create\n  again.\n\n### `mounts:`, `ports:`, `mcp:`, `entrypoint`\u002F`cmd`, and `sandboxOptions:`\n\nThese map onto kit host mounts, `sbx ports --publish`, MCP gateway\nregistrations, the agent launch argv, and `sbx create` options. Exact field\nshapes, defaults, and what `sbx env rm` leaves behind for each are in\n`references\u002Fenv-schema-fields.md`.\n\n## Related skills\n\n- For the `sbx create`\u002F`run`\u002F`rm` flag-based workflow this file wraps, use\n  `docker-sandboxes-lifecycle`.\n- For what `secrets:`\u002F`registries:`\u002F`bindings:` mean at runtime, and for\n  network policy independent of any environment file, use\n  `docker-sandboxes-network-credentials`.\n- For authoring, building, publishing, or signing the v3 kit descriptor a\n  `kits:` entry references, use `docker-sandboxes-kits`.\n\n## References\n\n- `references\u002Fauthoring-workflow.md` — step-by-step create and update\n  procedure, workspace-signal table, credential and host-grant handling, and\n  the final checklist.\n- `references\u002Fenv-schema-fields.md` — every top-level field, its shape and\n  defaults, with YAML examples.\n- `references\u002Fsources.md` — provenance for the rules above.\n\n## Assets\n\n- `assets\u002Fsbxenv.yaml` — a complete, minimal, safe example: a `shell` agent\n  mounting the declaring file's own directory, one static env var, and no\n  credentials — it validates and plans without onboarding authentication.\n  It sits at its mount root; for real projects prefer a file outside the\n  mounts.\n\n## Scripts\n\n- `scripts\u002Fkits.py` — live Docker Hub kit search, descriptor summary,\n  version-ordered update, and digest pinning for `kits:` entries. Run with\n  `python3 -I`; it only reads public registries.\n\n## Checks\n\n- `checks\u002Fverification.md` — verification runbook for the helper and\n  `sbx env` behavior (run manually with an isolated, uniquely named\n  `--app-name` signed in for the run, never with real secret values or\n  untrusted lifecycle commands force-approved).\n- `checks\u002Fruntime-results.md` — recorded results of that runbook on sbx\n  v0.51.0 (macOS arm64), including what the plan does not check.\n",{"name":5,"license":15,"description":7,"compatibility":24},"Requires standalone sbx with experimental `sbx env` support and sbxenv.yaml schemaVersion \"1\"; help and docs checked against sbx v0.51.0. scripts\u002Fkits.py needs Python 3.9+ and anonymous HTTPS access to Docker Hub (PyYAML only for older YAML descriptors). Provenance is in references\u002Fsources.md.","master","ced6c96bd67acccbf0280a5071e59a523c118c66","skills\u002Fdocker-sandboxes-env",5,"https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium","https:\u002F\u002Fgithub.com\u002Fstanfish06","https:\u002F\u002Fwww.stanfish.dev\u002F","2026-11-14 21:31:37",{"source":8,"skillName":5,"commands":34,"prompt":44,"zipAvailable":45},[35,38,41],{"tool":36,"command":37},"npx","npx skills add stanfish06\u002Fskillquarium --skill docker-sandboxes-env",{"tool":39,"command":40},"bunx","bunx skills add stanfish06\u002Fskillquarium --skill docker-sandboxes-env",{"tool":42,"command":43},"pnpm","pnpm dlx skills add stanfish06\u002Fskillquarium --skill docker-sandboxes-env","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fdocker-sandboxes-env\u002FSKILL.md",true,[47,53,59,63,67,71,75,79,83,89],{"path":48,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":51,"sourceHtmlUrl":52},"agents\u002Fopenai.yaml","REFERENCE","参考文档",484,"https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fdocker-sandboxes-env\u002Fagents\u002Fopenai.yaml",{"path":54,"resourceType":55,"resourceTypeDesc":56,"sizeBytes":57,"sourceHtmlUrl":58},"assets\u002Fsbxenv.yaml","ASSET","资产文件",286,"https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fdocker-sandboxes-env\u002Fassets\u002Fsbxenv.yaml",{"path":60,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":61,"sourceHtmlUrl":62},"checks\u002Fruntime-results.md",4794,"https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fdocker-sandboxes-env\u002Fchecks\u002Fruntime-results.md",{"path":64,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":65,"sourceHtmlUrl":66},"checks\u002Fverification.md",6361,"https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fdocker-sandboxes-env\u002Fchecks\u002Fverification.md",{"path":68,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":69,"sourceHtmlUrl":70},"evals\u002Fscaffold-pin-plan.yaml",3659,"https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fdocker-sandboxes-env\u002Fevals\u002Fscaffold-pin-plan.yaml",{"path":72,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":73,"sourceHtmlUrl":74},"references\u002Fauthoring-workflow.md",11500,"https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fdocker-sandboxes-env\u002Freferences\u002Fauthoring-workflow.md",{"path":76,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":77,"sourceHtmlUrl":78},"references\u002Fenv-schema-fields.md",12170,"https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fdocker-sandboxes-env\u002Freferences\u002Fenv-schema-fields.md",{"path":80,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fsources.md",2721,"https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fdocker-sandboxes-env\u002Freferences\u002Fsources.md",{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"scripts\u002Fkits.py","SCRIPT","脚本",30306,"https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fdocker-sandboxes-env\u002Fscripts\u002Fkits.py",{"path":90,"resourceType":49,"resourceTypeDesc":50,"sizeBytes":91,"sourceHtmlUrl":92},"skill.yaml",2136,"https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fdocker-sandboxes-env\u002Fskill.yaml",[94,102,110,117,124,131],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":98,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":19},"01M76ZJTRVA456GD7K8Y3EP82H","zarr-python","Stores and queries chunked N-D scientific arrays with Zarr-Python 3, including codecs, sharding, S3\u002FGCS storage, and NumPy\u002FDask\u002FXarray integration. Use for array layout, bounded I\u002FO, format migration, or scientific metadata preservation.","MIT","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fzarr-python\u002FSKILL.md",[],[],{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":106,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":19},"01M76ZJQZ15Q1HKC5V85NHE325","yeet","Publish local changes to GitHub by confirming scope, committing intentionally, pushing the branch, and opening a draft PR through the GitHub app from this plugin, with `gh` used only as a fallback where connector coverage is insufficient.","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fyeet\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fyeet\u002FSKILL.md",[],[],{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":19},"01M76ZJ8ASZ4QYQ70Y6SBA4Z4S","xarray","N-dimensional labeled arrays and datasets in Python. Built on top of NumPy and Dask. It introduces labels in the form of dimensions, coordinates, and attributes on top of raw NumPy-like arrays, making data analysis in physical sciences more intuitive and less error-prone. Use for working with multi-dimensional scientific data, NetCDF\u002FGRIB\u002FZarr files, climate\u002Fweather\u002Foceanographic datasets, remote sensing, geospatial imaging, large out-of-memory datasets with Dask, and labeled array operations.","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fxarray\u002FSKILL.md",[],[],{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":98,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":19},"01M76ZHFBXD6VXPQ02VCEG202B","writing-mstest-tests","Use when asked to fix, rewrite, update, improve, modernize, show corrected code for, or explain existing MSTest tests or MSTest-specific configuration. Use for \"review\" when corrected code or edits are wanted, even for one pasted assertion or passing tests with bad failure output. Covers expected\u002Factual labels; generic Boolean, collection, string, numeric, null, identity, exception, hard-cast, and object[] checks; TestContext\u002Flifecycle; timeout\u002Fcancellation; OS\u002FCI conditions, retry, cleanup, parallelization, MSTest.Sdk project setup, and MSTESTxxxx. Honor the installed MSTest version. DO NOT USE to design new test cases (code-testing), perform report-only audits, create project files rather than explain MSTest setup, run tests, migrate frameworks, or handle non-MSTest\u002Fnon-.NET code.","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fwriting-mstest-tests\u002FSKILL.md",[],[],{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":98,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":19},"01M76ZDFDF4N88RH6HSYGS7GP2","wgs-prs","End-to-end WGS to polygenic risk score pipeline. Takes paired-end FASTQ files (or a pre-existing VCF) through nf-core\u002Fsarek for variant calling, applies VCF QC (normalisation, hard filtering, Ti\u002FTv and Het\u002FHom checks), then computes polygenic risk scores via the PGS Catalog. Fills the FASTQ to VCF gap upstream of the gwas-prs skill.","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fwgs-prs\u002FSKILL.md",[],[],{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":135,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":19},"01M76ZCC1SC68J42QK4MDC8RCG","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fstanfish06\u002Fskillquarium\u002Fblob\u002Fmaster\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[],[]]