[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6MJ8ENJ8GQSAHV4FEAXF2RE":3,"skill-same:01M6MJ8ENJ8GQSAHV4FEAXF2RE":75},{"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":23,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M6MJ8ENJ8GQSAHV4FEAXF2RE","agentbox-info",null,"Spin up isolated sandboxes (\"boxes\") for coding agents, run them in parallel, queue background runs with -i, and push commits safely through the host relay. Use when the user wants to run Claude Code \u002F Codex \u002F OpenCode in a sandbox, start more boxes, attach to a running box, or otherwise operate the `agentbox` CLI on their laptop.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1566,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fmadarco\u002Fagentbox\u002Fskills\u002Fagentbox-info\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"agentbox info","info","running","cli","when","for","operate","sandboxes","relay","host","false","boxes","attach","opencode","up","parallel","coding","commits","start","push","code","run","2026-11-10 10:12:30",false,"---\nname: agentbox-info\ndescription: \"Spin up isolated sandboxes (\\\"boxes\\\") for coding agents, run them in parallel, queue background runs with -i, and push commits safely through the host relay. Use when the user wants to run Claude Code \u002F Codex \u002F OpenCode in a sandbox, start more boxes, attach to a running box, or otherwise operate the `agentbox` CLI on their laptop.\"\nuser-invocable: false\n---\n\u003C!-- agentbox-managed:v1 -->\n\n# AgentBox (host-side)\n\nYou are operating on the **user's host machine** (laptop \u002F dev workstation), not inside a box. Use the `agentbox` CLI to provision isolated sandboxes for coding agents and to attach to them.\n\nIf you find yourself *inside* a box (`\u002Fworkspace` exists and `AGENTBOX_RELAY_URL` is set in the env), this is the wrong skill — use the in-box `\u002Fagentbox-setup` skill instead.\n\n## What AgentBox is, in one paragraph\n\nAgentBox spins up one isolated sandbox per agent run — a local Docker container (default), a Hetzner VPS (`--provider hetzner`), a Vercel Sandbox (`--provider vercel`), or a Daytona cloud sandbox (`--provider daytona`, partial support). Each box has its own `\u002Fworkspace`, but the host's `.git\u002F` is shared, so commits made inside the box land on the host immediately. The agent inside the box has **no host credentials** — `git push`, opening URLs in the host browser, capturing checkpoints, and all other host-side operations flow through a small host process called the **relay** that runs alongside the CLI.\n\n## The two starting commands\n\n### `agentbox create`\n\nProvision a box and stop. The box exists and is ready, but nothing is launched inside it.\n\n```sh\nagentbox create                       # docker, auto-named after the workspace\nagentbox create -n review             # docker, friendly name\nagentbox create --provider hetzner    # cloud VPS (requires `agentbox prepare --provider hetzner` once)\nagentbox create --attach              # drop into a shell inside the box after create\n```\n\nUseful flags: `-n \u003Cname>` (friendly box name), `--provider docker|daytona|hetzner|vercel`, `--attach`, `-w \u003Cpath>` (workspace to mount; defaults to `cwd`), `--snapshot \u003Cref>` (start from a checkpoint).\n\nNon-docker providers require a one-time `agentbox prepare --provider \u003Cname>` to bake the base image \u002F snapshot.\n\n### `agentbox claude`\n\nProvision (same as `create`) and launch **Claude Code** inside the box, in a detachable tmux session. This is the main entry point most users want.\n\n```sh\nagentbox claude                       # docker, attaches your terminal\nagentbox claude -n review             # second box, named\nagentbox claude --provider hetzner    # cloud\nagentbox claude -- --model sonnet     # extra args after `--` go to claude itself\n```\n\nWhile attached: **`Ctrl+a d`** detaches without killing claude. The box keeps running. Reattach with `agentbox claude attach \u003Cname|n>`.\n\nVariants with the same shape for other agents: **`agentbox codex`**, **`agentbox opencode`**.\n\n## `-i` \u002F `--initial-prompt`: background queue\n\nWith `-i \"\u003Cprompt>\"`, `agentbox claude` (and `codex` \u002F `opencode`) does **not** attach. It writes a job manifest to `~\u002F.agentbox\u002Fqueue\u002F\u003Cid>.json` and exits immediately, printing the job id and log path. The host relay's queue loop drains these manifests respecting `queue.maxConcurrent` (global config; override per invocation with `--max-running \u003Cn>`).\n\nUse this to fan out parallel agent runs:\n\n```sh\nagentbox claude -i \"fix the failing test in src\u002Fauth and open a PR\"\nagentbox claude -i \"draft a CHANGELOG entry from the last 20 commits\"\nagentbox claude -i \"audit our dependencies for known CVEs\"\n```\n\nEach call returns instantly. The queue drains them concurrently up to `queue.maxConcurrent`. Inspect \u002F attach later:\n\n```sh\nagentbox dashboard                    # TUI with status + leader-key actions\nagentbox claude attach \u003Cname|n>       # reattach to a specific box\n```\n\n`-i` works on every provider — pass `--provider daytona|hetzner|vercel` (or set `box.provider`) and the queued job creates a cloud box and pre-starts the seeded agent session detached, same as docker. The host must have valid agent credentials. Extra args after `--` are forwarded to the in-box agent (e.g. `agentbox claude -i \"\u003Cprompt>\" --provider vercel -- --permission-mode=plan`).\n\n`-i` honors the project's `carry:` block: the carry gate runs on the host when you submit (it prompts there, since you're at the terminal), and the approved files ride the queued job and land in the box at create time. Auto-approve non-interactively with `--carry-yes` (or `AGENTBOX_CARRY_YES=1`); skip with `--carry skip` (or `AGENTBOX_CARRY=skip`).\n\n## Forking the current session into a box\n\nFrom host Claude, run the **`\u002Fagentbox`** slash command (optional arg: `docker` | `daytona` | `hetzner`) to snapshot the *current* Claude Code session into a brand-new box that resumes it. With tmux or iTerm it opens in a new terminal tab; otherwise it starts in the background. The host session is unaffected — you get two parallel timelines. The underlying CLI is `agentbox fork` (`agentbox fork --help`); `\u002Fagentbox` requires `agentbox install` to have been run once. This is distinct from `-i`, which seeds a *new* prompt rather than resuming the live conversation. Fork **sends** the project's `carry:` block by default (the host is trusted; the box is the untrusted side, so host→box copy is safe) — opt out with `agentbox fork --carry skip`.\n\n## Driving one agent from another (`drive`, `agent`, `queue wait-for`)\n\nWhen *you* are the host-side agent and want to orchestrate other agents running inside boxes — read what they're doing, send them a prompt, wait until they're done or need input — use these three command families. Everything is stateless \u002F one-shot, and the human-text default switches to machine-friendly JSON with `--json`.\n\n### `agentbox drive \u003Cbox>` — terminal driving\n\nTargets the running tmux session inside a box (auto-picks the agent session: `claude` → `codex` → `opencode` → the only running session; override with `--session \u003Cname>`). Provider-uniform — works the same on docker \u002F daytona \u002F hetzner \u002F vercel.\n\n```sh\nagentbox drive snapshot 1                          # print rendered TUI as plain text\nagentbox drive snapshot 1 --with-cursor            # JSON envelope: { session, cols, rows, cursor, screen }\nagentbox drive snapshot 1 --ansi --rows -200:-1    # include color, walk into scrollback\nagentbox drive keypress 1 \"\u003CC-c>\"                  # DSL: \u003CEnter>, \u003CC-x>, \u003CTab>, \u003CF5>, \u003CUp>, etc.\nagentbox drive send-text 1 \"hello\"                 # literal text, no DSL parsing, no trailing Enter\nagentbox drive prompt 1 \"summarize \u002Fworkspace\u002FREADME\" # type + Enter (the convenience action)\nagentbox drive wait 1 --text \"✓\" --timeout 60000   # block until \u003Ctext> appears on screen\nagentbox drive resize 1 200 60\n```\n\n`keypress` uses a small DSL: `\u003CEnter>`, `\u003CTab>`, `\u003CEsc>`, `\u003CSpace>`, `\u003CBS>`, `\u003CDel>`, `\u003CUp>\u002F\u003CDown>\u002F\u003CLeft>\u002F\u003CRight>`, `\u003CHome>\u002F\u003CEnd>\u002F\u003CPageUp>\u002F\u003CPageDown>`, `\u003CF1>`–`\u003CF12>`, `\u003CC-a>`..`\u003CC-z>`. Use `\u003C\u003C` for a literal `\u003C`. Multiple args concatenate with no spaces (`\"ls\" \"\u003CEnter>\"` → `ls\\r`).\n\n### `agentbox agent \u003Cbox>` — agent state introspection (Claude \u002F Codex \u002F OpenCode)\n\nSub-second latency. State source by agent:\n\n- **Claude Code**: lifecycle hooks (`UserPromptSubmit`, `PreToolUse`, `Stop`, `Notification`, `ExitPlanMode`, `AskUserQuestion`, `PreCompact`\u002F`PostCompact`, `StopFailure`, `SubagentStart`\u002F`SubagentStop`).\n- **Codex**: tmux-pane scraper inside the box (codex 0.134.0's own hook firing is unreliable; staged hooks remain for the day that's fixed upstream).\n- **OpenCode**: a plugin (`agentbox-state.js`) seeded into the OpenCode config volume, subscribing to OpenCode's event bus.\n\nAll three feed the same status pipeline; `agent state` \u002F `agent wait-for` work the same regardless of which agent runs inside the box. Reports come from `~\u002F.agentbox\u002Fboxes\u002F\u003Cid>\u002Fstatus.json` and the relay event stream.\n\n```sh\nagentbox agent state 1                # → working | idle | waiting | end-plan | question | prompt | compacting | error\nagentbox agent state 1 --json         # full BoxStatusClaude (state, updatedAt, sessionTitle, plan?, question?)\n\nagentbox agent get-plan-question 1            # print the plan body OR question + options (human)\nagentbox agent get-plan-question 1 --json     # structured payload\n```\n\n**For orchestration, `agent wait-for input-needed` is the tool to reach for.** It is the single sync point that wakes whenever the agent needs *you* — whether the turn **finished and it's ready for the next message**, or it's **blocked** on a question, a plan to approve, a permission prompt, or an error. It matches every state except `working` \u002F `compacting`, and prints the concrete state it matched so you can branch on *why* it woke:\n\n```sh\nagentbox agent wait-for input-needed 1 --timeout 600000   # → prints: prompt | end-plan | question | waiting | error\n```\n\nPrefer it over waiting on one specific transition — a narrow `wait-for end-plan` hangs to its timeout if the agent instead asks a question, hits a permission prompt, finishes, or errors. The granular states are still waitable when you *know* exactly what to expect: `prompt` (ready for next message), `idle` (Stop hook fired), `end-plan`, `question`, `waiting`, `compacting`, `error` — e.g. `agentbox agent wait-for prompt 1`.\n\n### `agentbox queue wait-for \u003Cevent>` — queue + box lifecycle\n\n```sh\nagentbox queue wait-for new-box                          # any new box gets registered\nagentbox queue wait-for empty-queue --timeout 1800000    # all queued\u002Frunning jobs settled\nagentbox queue wait-for box-running --box review\nagentbox queue wait-for box-paused  --box 2\nagentbox queue wait-for box-stopped --box 2\nagentbox queue wait-for job-done --job b45f1603841bd2b5  # terminal status (done\u002Ffailed\u002Fcancelled)\n```\n\nAll wait-for commands exit 0 on match, exit 1 on timeout, and accept `--json` for parseable output.\n\n### Recipe: drive a Claude Code from another Claude Code\n\nQueue a prompt, then loop on `wait-for input-needed` and act on whatever it reports — that one waiter handles every \"the agent needs me\" case, so the loop never hangs on an unexpected state.\n\n```sh\n# 1. Kick off a box with a planning prompt, in background.\nagentbox claude -n design -i \"Plan how to add an OAuth login flow to apps\u002Fweb, then enter plan mode. Don't start coding.\"\n\n# 2. Wait until the agent needs you, and branch on what it reports.\nSTATE=$(agentbox agent wait-for input-needed design --timeout 1200000)\ncase \"$STATE\" in\n  end-plan|question) agentbox agent get-plan-question design   # read the plan \u002F question\n                     agentbox drive keypress design \"\u003CEnter>\" ;;  # approve \u002F answer (option 1 pre-highlighted)\n  waiting)           agentbox drive keypress design \"\u003CEnter>\" ;;  # approve the tool\u002Fpermission\n  prompt|idle)       agentbox claude -i \"Write the OAuth provider unit tests in apps\u002Fweb\u002Ftest\u002Fauth\u002F\" ;; # turn done — fan out more\n  error)             echo \"agent errored — inspect with: agentbox drive snapshot design\" ;;\nesac\n\n# 3. Block until the whole batch settles before reporting back.\nagentbox queue wait-for empty-queue --timeout 3600000\n```\n\nWrap step 2 in a loop to babysit a box across many turns. Use the narrow `wait-for \u003Cstate>` forms only when a step must gate on one specific transition.\n\n### Quick mental model\n\n- `agent wait-for input-needed` = the orchestration sync point — \"wake me when the agent needs me\" (done OR blocked). Reach for this first.\n- `agent` (`state` \u002F `get-plan-question` \u002F narrow `wait-for`) = \"what is the agent currently doing\" — hook-driven, race-free, machine-readable.\n- `drive` = \"send keystrokes \u002F read screen\" — provider-uniform tmux capture-pane \u002F send-keys; how you act once `wait-for` returns.\n- `queue wait-for` = \"block on queue or box lifecycle transitions\" (`empty-queue`, `box-running`, `job-done`, …) — settle a whole batch.\n- All commands are **stateless** — safe to invoke from any script, any agent, in parallel.\n- `--json` everywhere. Default human text is for the operator; an agent should pass `--json`.\n\n## Git through the host relay\n\n**The box has no SSH keys, GPG keys, or git remote credentials.** Don't ask the user to add any. When an in-box agent (or a script you run inside the box) does `git push` or `git pull`, the AgentBox-provided `agentbox-ctl git` wrapper POSTs a JSON-RPC call to the host relay (`POST \u002Frpc`, bearer-auth, loopback-only). The relay runs the **real** `git push origin …` on the host, using the user's `SSH_AUTH_SOCK`, `~\u002F.gitconfig`, and identity — and streams stdout\u002Fstderr back into the box's terminal. The box's exit code matches the host's.\n\nImplications for you, the host-side agent:\n\n- Inside the box you can `git commit … && git push` exactly as normal. No setup needed.\n- Pushes are gated host-side: the relay can require a confirm prompt for destructive operations (the user sees it in the dashboard footer, ~25 s TTL). If a push appears to hang, it's waiting on this approval — see \"Answering host-action approvals\" below.\n- The relay process is started lazily by the first `agentbox create` \u002F `agentbox claude` and persists across runs (PID at `~\u002F.agentbox\u002Frelay.pid`, log at `~\u002F.agentbox\u002Frelay.log`). You normally don't need to manage it.\n- For HTTPS origins (`https:\u002F\u002Fgithub.com\u002F...`), pushing usually needs a credential — recommend the user run `gh auth login` and `gh auth setup-git` once on the host. After that, host `git push` uses gh's OAuth token automatically. SSH origins (`git@github.com:...`) keep using the host's SSH agent as before.\n\n## Answering approvals (orchestrator path)\n\nWhen you are **orchestrating boxes unattended** (no human watching the dashboard footer), a box blocks on two kinds of approval and `agent approvals` \u002F `agent approve` cover **both**:\n\n- **Relay host-action approvals** — `git push` \u002F `cp` \u002F `gh pr` write \u002F checkpoint. You answer them yourself; you're a host process that already holds the user's git\u002Ffile credentials, so approving grants nothing you don't already have.\n- **In-TUI agent prompts** — Claude plan-mode approval, `AskUserQuestion`, a tool-permission dialog. Previously you had to craft `drive keypress` sends by hand; now `approve` enacts the right keystrokes for you.\n\n```bash\nagentbox agent approvals 1 --json          # list everything box 1 is blocked on: each row has an id + kind\nagentbox agent approve \u003Cid>                # answer that exact prompt (default = approve \u002F first option)\nagentbox agent approve \u003Cid> --option 2     # in-TUI question\u002Fplan: pick option 2 (or --option \"Risk first\")\nagentbox agent approve \u003Cid> --deny         # reject (relay: deny; in-TUI: Escape)\nagentbox agent approvals 1 --wait 600000   # block until something is pending, then act\n```\n\n`kind` is `host-action` (relay), or `plan` \u002F `question` \u002F `permission` (in-TUI). Relay rows carry `command`\u002F`argv`; `question` rows carry the option labels; `plan` rows the plan body.\n\n**The id is a safety token — inspect, then approve that exact id.** `approve \u003Cid>` answers the specific prompt you listed; if a *different* prompt has since taken its place, the recomputed id won't match and the approve is **refused** (it never answers the wrong thing). So always `approvals` → read the `command`\u002F`argv`\u002Foptions → `approve \u003Cid>`, one at a time. Do not blanket-approve whatever a box asks (that defeats the gate against a prompt-injected box laundering a malicious push), and never hand-`curl` `\u002Fadmin\u002Fprompts\u002Fanswer` — these commands are the supported surface. In-TUI keystroke mapping is best-effort and TUI-version-sensitive; if an approve doesn't take, fall back to `drive snapshot` + `drive keypress`.\n\n## PRs through the host relay (`agentbox-ctl git pr …`)\n\nIn-box agents can drive GitHub PRs from inside a box via the host's `gh` CLI. Same model as `git push`: the box has no GitHub token; the relay shells out to `gh` on the host with the user's authenticated gh identity. Requires `gh` installed on the host and `gh auth login` run once.\n\nThe wrapper is `agentbox-ctl git pr \u003Cop> [args...]`. Available ops:\n\n| Op | Prompt? | Notes |\n| --- | --- | --- |\n| `view \u003Cnum>` | no | Read-only. |\n| `list` | no | Read-only. |\n| `create` | yes | Pass-through args (e.g. `--title T --body B --draft`). |\n| `comment \u003Cnum>` | yes | Visible to others. |\n| `review \u003Cnum>` | yes | Visible to others. |\n| `close \u003Cnum>`, `reopen \u003Cnum>` | yes | |\n| `merge \u003Cnum>` | yes (+ bypass guard) | `AGENTBOX_PROMPT=off` auto-`y` is refused here unless `AGENTBOX_GH_FORCE=1` is also set. |\n| `checkout \u003Cnum>` | yes (+ opt-in) | Off by default — switches the host main repo's branch (visible to the box). Enable with `AGENTBOX_GH_PR_CHECKOUT=allow`; a dirty host tree is refused, and a host HEAD on a registered box branch is refused. |\n\nIf a PR op appears to hang, tell the user to check the dashboard footer for the host confirmation prompt. If `gh` is missing or unauthenticated, the in-box command exits 127 \u002F 4 with a clear stderr.\n\n## Other commands worth knowing\n\n| Command | What it does |\n| --- | --- |\n| `agentbox dashboard` | TUI status + switcher across all boxes. The leader is **`Ctrl+a`** (e.g. `Ctrl+a u` opens the box's web URL; `Ctrl+a s` opens the in-box browser; `Ctrl+a q` quits). |\n| `agentbox shell [n\\|name]` | Interactive `bash -l` inside the box (also wrapped in tmux by default — detach with `Ctrl+a d`). |\n| `agentbox url [n\\|name]` | Open the box's web app URL (`\u003Cbox-name>.localhost` via Portless) in the host browser. |\n| `agentbox screen [n\\|name]` | Open the box's **own** Chromium via VNC — useful for OAuth flows the agent inside the box initiates. |\n| `agentbox code [n\\|name]` | Open VS Code \u002F Cursor pointed at the box. |\n| `agentbox prepare --provider \u003Cname>` | One-time base image \u002F snapshot build for `daytona` or `hetzner` or `vercel`. With no `--provider`, prints status across all providers. |\n| `agentbox prune --provider \u003Cname>` | Clean up orphan boxes \u002F images \u002F snapshots for a provider (docker + daytona supported; hetzner pending). |\n| `agentbox cp \u003Csrc> \u003Cdst>` | Copy a file\u002Fdir host↔box (`box:\u002Fpath` prefix picks direction). Heavy dirs (`.git`, `node_modules`, build output) are dropped by default; add `--exclude=\u003Cglob\\|name>` or `--no-default-excludes`. Uploads over `box.cpMaxBytes` (100 MB, post-exclude) are **blocked** with a size breakdown — trim with `--exclude`, copy heavy folders one at a time, or pass `--yes`. |\n\nPer-project numeric index (`1`, `2`, …) and friendly name (`review`, `smoke`) both work wherever `\u003Cbox>` is accepted. Index `1` is the first box created in the current workspace.\n\n## Operating principles\n\n1. **Never assume the host needs SSH keys forwarded into a box** — git is handled by the relay, by design.\n2. **Use `-i` whenever the user asks for parallel agent work** rather than spawning multiple foreground sessions. Then point them at `agentbox dashboard` to watch progress.\n3. **Pick the provider deliberately.** `docker` is the fast default. `--provider hetzner` gives a real VPS (heavier, isolated, requires `agentbox prepare --provider hetzner` once). `--provider vercel` is the managed cloud option.\n4. **Cross-check before recommending a command.** If a flag isn't listed here, run `agentbox \u003Ccommand> --help` (it's safe and read-only) before suggesting it to the user.\n5. **`\u002Fagentbox-setup` is a different skill.** It runs *inside* a box to generate `\u002Fworkspace\u002Fagentbox.yaml`. Don't conflate it with `\u002Fagentbox` (host-side fork) or this reference skill.\n\n## Reference\n\n- Full docs live in the repo at `docs\u002F` — start with `docs\u002Farchitecture.md` and `docs\u002Fcreate-and-checkpoints.md` for the model, `docs\u002Fhost-relay.md` for the relay, `docs\u002Fcloud-providers.md` for the cloud paths.\n- npm package: `@madarco\u002Fagentbox` — `npm -g install @madarco\u002Fagentbox` (or `npx @madarco\u002Fagentbox \u003Ccommand>`).\n","\u003C!-- agentbox-managed:v1 -->\n\n# AgentBox (host-side)\n\nYou are operating on the **user's host machine** (laptop \u002F dev workstation), not inside a box. Use the `agentbox` CLI to provision isolated sandboxes for coding agents and to attach to them.\n\nIf you find yourself *inside* a box (`\u002Fworkspace` exists and `AGENTBOX_RELAY_URL` is set in the env), this is the wrong skill — use the in-box `\u002Fagentbox-setup` skill instead.\n\n## What AgentBox is, in one paragraph\n\nAgentBox spins up one isolated sandbox per agent run — a local Docker container (default), a Hetzner VPS (`--provider hetzner`), a Vercel Sandbox (`--provider vercel`), or a Daytona cloud sandbox (`--provider daytona`, partial support). Each box has its own `\u002Fworkspace`, but the host's `.git\u002F` is shared, so commits made inside the box land on the host immediately. The agent inside the box has **no host credentials** — `git push`, opening URLs in the host browser, capturing checkpoints, and all other host-side operations flow through a small host process called the **relay** that runs alongside the CLI.\n\n## The two starting commands\n\n### `agentbox create`\n\nProvision a box and stop. The box exists and is ready, but nothing is launched inside it.\n\n```sh\nagentbox create                       # docker, auto-named after the workspace\nagentbox create -n review             # docker, friendly name\nagentbox create --provider hetzner    # cloud VPS (requires `agentbox prepare --provider hetzner` once)\nagentbox create --attach              # drop into a shell inside the box after create\n```\n\nUseful flags: `-n \u003Cname>` (friendly box name), `--provider docker|daytona|hetzner|vercel`, `--attach`, `-w \u003Cpath>` (workspace to mount; defaults to `cwd`), `--snapshot \u003Cref>` (start from a checkpoint).\n\nNon-docker providers require a one-time `agentbox prepare --provider \u003Cname>` to bake the base image \u002F snapshot.\n\n### `agentbox claude`\n\nProvision (same as `create`) and launch **Claude Code** inside the box, in a detachable tmux session. This is the main entry point most users want.\n\n```sh\nagentbox claude                       # docker, attaches your terminal\nagentbox claude -n review             # second box, named\nagentbox claude --provider hetzner    # cloud\nagentbox claude -- --model sonnet     # extra args after `--` go to claude itself\n```\n\nWhile attached: **`Ctrl+a d`** detaches without killing claude. The box keeps running. Reattach with `agentbox claude attach \u003Cname|n>`.\n\nVariants with the same shape for other agents: **`agentbox codex`**, **`agentbox opencode`**.\n\n## `-i` \u002F `--initial-prompt`: background queue\n\nWith `-i \"\u003Cprompt>\"`, `agentbox claude` (and `codex` \u002F `opencode`) does **not** attach. It writes a job manifest to `~\u002F.agentbox\u002Fqueue\u002F\u003Cid>.json` and exits immediately, printing the job id and log path. The host relay's queue loop drains these manifests respecting `queue.maxConcurrent` (global config; override per invocation with `--max-running \u003Cn>`).\n\nUse this to fan out parallel agent runs:\n\n```sh\nagentbox claude -i \"fix the failing test in src\u002Fauth and open a PR\"\nagentbox claude -i \"draft a CHANGELOG entry from the last 20 commits\"\nagentbox claude -i \"audit our dependencies for known CVEs\"\n```\n\nEach call returns instantly. The queue drains them concurrently up to `queue.maxConcurrent`. Inspect \u002F attach later:\n\n```sh\nagentbox dashboard                    # TUI with status + leader-key actions\nagentbox claude attach \u003Cname|n>       # reattach to a specific box\n```\n\n`-i` works on every provider — pass `--provider daytona|hetzner|vercel` (or set `box.provider`) and the queued job creates a cloud box and pre-starts the seeded agent session detached, same as docker. The host must have valid agent credentials. Extra args after `--` are forwarded to the in-box agent (e.g. `agentbox claude -i \"\u003Cprompt>\" --provider vercel -- --permission-mode=plan`).\n\n`-i` honors the project's `carry:` block: the carry gate runs on the host when you submit (it prompts there, since you're at the terminal), and the approved files ride the queued job and land in the box at create time. Auto-approve non-interactively with `--carry-yes` (or `AGENTBOX_CARRY_YES=1`); skip with `--carry skip` (or `AGENTBOX_CARRY=skip`).\n\n## Forking the current session into a box\n\nFrom host Claude, run the **`\u002Fagentbox`** slash command (optional arg: `docker` | `daytona` | `hetzner`) to snapshot the *current* Claude Code session into a brand-new box that resumes it. With tmux or iTerm it opens in a new terminal tab; otherwise it starts in the background. The host session is unaffected — you get two parallel timelines. The underlying CLI is `agentbox fork` (`agentbox fork --help`); `\u002Fagentbox` requires `agentbox install` to have been run once. This is distinct from `-i`, which seeds a *new* prompt rather than resuming the live conversation. Fork **sends** the project's `carry:` block by default (the host is trusted; the box is the untrusted side, so host→box copy is safe) — opt out with `agentbox fork --carry skip`.\n\n## Driving one agent from another (`drive`, `agent`, `queue wait-for`)\n\nWhen *you* are the host-side agent and want to orchestrate other agents running inside boxes — read what they're doing, send them a prompt, wait until they're done or need input — use these three command families. Everything is stateless \u002F one-shot, and the human-text default switches to machine-friendly JSON with `--json`.\n\n### `agentbox drive \u003Cbox>` — terminal driving\n\nTargets the running tmux session inside a box (auto-picks the agent session: `claude` → `codex` → `opencode` → the only running session; override with `--session \u003Cname>`). Provider-uniform — works the same on docker \u002F daytona \u002F hetzner \u002F vercel.\n\n```sh\nagentbox drive snapshot 1                          # print rendered TUI as plain text\nagentbox drive snapshot 1 --with-cursor            # JSON envelope: { session, cols, rows, cursor, screen }\nagentbox drive snapshot 1 --ansi --rows -200:-1    # include color, walk into scrollback\nagentbox drive keypress 1 \"\u003CC-c>\"                  # DSL: \u003CEnter>, \u003CC-x>, \u003CTab>, \u003CF5>, \u003CUp>, etc.\nagentbox drive send-text 1 \"hello\"                 # literal text, no DSL parsing, no trailing Enter\nagentbox drive prompt 1 \"summarize \u002Fworkspace\u002FREADME\" # type + Enter (the convenience action)\nagentbox drive wait 1 --text \"✓\" --timeout 60000   # block until \u003Ctext> appears on screen\nagentbox drive resize 1 200 60\n```\n\n`keypress` uses a small DSL: `\u003CEnter>`, `\u003CTab>`, `\u003CEsc>`, `\u003CSpace>`, `\u003CBS>`, `\u003CDel>`, `\u003CUp>\u002F\u003CDown>\u002F\u003CLeft>\u002F\u003CRight>`, `\u003CHome>\u002F\u003CEnd>\u002F\u003CPageUp>\u002F\u003CPageDown>`, `\u003CF1>`–`\u003CF12>`, `\u003CC-a>`..`\u003CC-z>`. Use `\u003C\u003C` for a literal `\u003C`. Multiple args concatenate with no spaces (`\"ls\" \"\u003CEnter>\"` → `ls\\r`).\n\n### `agentbox agent \u003Cbox>` — agent state introspection (Claude \u002F Codex \u002F OpenCode)\n\nSub-second latency. State source by agent:\n\n- **Claude Code**: lifecycle hooks (`UserPromptSubmit`, `PreToolUse`, `Stop`, `Notification`, `ExitPlanMode`, `AskUserQuestion`, `PreCompact`\u002F`PostCompact`, `StopFailure`, `SubagentStart`\u002F`SubagentStop`).\n- **Codex**: tmux-pane scraper inside the box (codex 0.134.0's own hook firing is unreliable; staged hooks remain for the day that's fixed upstream).\n- **OpenCode**: a plugin (`agentbox-state.js`) seeded into the OpenCode config volume, subscribing to OpenCode's event bus.\n\nAll three feed the same status pipeline; `agent state` \u002F `agent wait-for` work the same regardless of which agent runs inside the box. Reports come from `~\u002F.agentbox\u002Fboxes\u002F\u003Cid>\u002Fstatus.json` and the relay event stream.\n\n```sh\nagentbox agent state 1                # → working | idle | waiting | end-plan | question | prompt | compacting | error\nagentbox agent state 1 --json         # full BoxStatusClaude (state, updatedAt, sessionTitle, plan?, question?)\n\nagentbox agent get-plan-question 1            # print the plan body OR question + options (human)\nagentbox agent get-plan-question 1 --json     # structured payload\n```\n\n**For orchestration, `agent wait-for input-needed` is the tool to reach for.** It is the single sync point that wakes whenever the agent needs *you* — whether the turn **finished and it's ready for the next message**, or it's **blocked** on a question, a plan to approve, a permission prompt, or an error. It matches every state except `working` \u002F `compacting`, and prints the concrete state it matched so you can branch on *why* it woke:\n\n```sh\nagentbox agent wait-for input-needed 1 --timeout 600000   # → prints: prompt | end-plan | question | waiting | error\n```\n\nPrefer it over waiting on one specific transition — a narrow `wait-for end-plan` hangs to its timeout if the agent instead asks a question, hits a permission prompt, finishes, or errors. The granular states are still waitable when you *know* exactly what to expect: `prompt` (ready for next message), `idle` (Stop hook fired), `end-plan`, `question`, `waiting`, `compacting`, `error` — e.g. `agentbox agent wait-for prompt 1`.\n\n### `agentbox queue wait-for \u003Cevent>` — queue + box lifecycle\n\n```sh\nagentbox queue wait-for new-box                          # any new box gets registered\nagentbox queue wait-for empty-queue --timeout 1800000    # all queued\u002Frunning jobs settled\nagentbox queue wait-for box-running --box review\nagentbox queue wait-for box-paused  --box 2\nagentbox queue wait-for box-stopped --box 2\nagentbox queue wait-for job-done --job b45f1603841bd2b5  # terminal status (done\u002Ffailed\u002Fcancelled)\n```\n\nAll wait-for commands exit 0 on match, exit 1 on timeout, and accept `--json` for parseable output.\n\n### Recipe: drive a Claude Code from another Claude Code\n\nQueue a prompt, then loop on `wait-for input-needed` and act on whatever it reports — that one waiter handles every \"the agent needs me\" case, so the loop never hangs on an unexpected state.\n\n```sh\n# 1. Kick off a box with a planning prompt, in background.\nagentbox claude -n design -i \"Plan how to add an OAuth login flow to apps\u002Fweb, then enter plan mode. Don't start coding.\"\n\n# 2. Wait until the agent needs you, and branch on what it reports.\nSTATE=$(agentbox agent wait-for input-needed design --timeout 1200000)\ncase \"$STATE\" in\n  end-plan|question) agentbox agent get-plan-question design   # read the plan \u002F question\n                     agentbox drive keypress design \"\u003CEnter>\" ;;  # approve \u002F answer (option 1 pre-highlighted)\n  waiting)           agentbox drive keypress design \"\u003CEnter>\" ;;  # approve the tool\u002Fpermission\n  prompt|idle)       agentbox claude -i \"Write the OAuth provider unit tests in apps\u002Fweb\u002Ftest\u002Fauth\u002F\" ;; # turn done — fan out more\n  error)             echo \"agent errored — inspect with: agentbox drive snapshot design\" ;;\nesac\n\n# 3. Block until the whole batch settles before reporting back.\nagentbox queue wait-for empty-queue --timeout 3600000\n```\n\nWrap step 2 in a loop to babysit a box across many turns. Use the narrow `wait-for \u003Cstate>` forms only when a step must gate on one specific transition.\n\n### Quick mental model\n\n- `agent wait-for input-needed` = the orchestration sync point — \"wake me when the agent needs me\" (done OR blocked). Reach for this first.\n- `agent` (`state` \u002F `get-plan-question` \u002F narrow `wait-for`) = \"what is the agent currently doing\" — hook-driven, race-free, machine-readable.\n- `drive` = \"send keystrokes \u002F read screen\" — provider-uniform tmux capture-pane \u002F send-keys; how you act once `wait-for` returns.\n- `queue wait-for` = \"block on queue or box lifecycle transitions\" (`empty-queue`, `box-running`, `job-done`, …) — settle a whole batch.\n- All commands are **stateless** — safe to invoke from any script, any agent, in parallel.\n- `--json` everywhere. Default human text is for the operator; an agent should pass `--json`.\n\n## Git through the host relay\n\n**The box has no SSH keys, GPG keys, or git remote credentials.** Don't ask the user to add any. When an in-box agent (or a script you run inside the box) does `git push` or `git pull`, the AgentBox-provided `agentbox-ctl git` wrapper POSTs a JSON-RPC call to the host relay (`POST \u002Frpc`, bearer-auth, loopback-only). The relay runs the **real** `git push origin …` on the host, using the user's `SSH_AUTH_SOCK`, `~\u002F.gitconfig`, and identity — and streams stdout\u002Fstderr back into the box's terminal. The box's exit code matches the host's.\n\nImplications for you, the host-side agent:\n\n- Inside the box you can `git commit … && git push` exactly as normal. No setup needed.\n- Pushes are gated host-side: the relay can require a confirm prompt for destructive operations (the user sees it in the dashboard footer, ~25 s TTL). If a push appears to hang, it's waiting on this approval — see \"Answering host-action approvals\" below.\n- The relay process is started lazily by the first `agentbox create` \u002F `agentbox claude` and persists across runs (PID at `~\u002F.agentbox\u002Frelay.pid`, log at `~\u002F.agentbox\u002Frelay.log`). You normally don't need to manage it.\n- For HTTPS origins (`https:\u002F\u002Fgithub.com\u002F...`), pushing usually needs a credential — recommend the user run `gh auth login` and `gh auth setup-git` once on the host. After that, host `git push` uses gh's OAuth token automatically. SSH origins (`git@github.com:...`) keep using the host's SSH agent as before.\n\n## Answering approvals (orchestrator path)\n\nWhen you are **orchestrating boxes unattended** (no human watching the dashboard footer), a box blocks on two kinds of approval and `agent approvals` \u002F `agent approve` cover **both**:\n\n- **Relay host-action approvals** — `git push` \u002F `cp` \u002F `gh pr` write \u002F checkpoint. You answer them yourself; you're a host process that already holds the user's git\u002Ffile credentials, so approving grants nothing you don't already have.\n- **In-TUI agent prompts** — Claude plan-mode approval, `AskUserQuestion`, a tool-permission dialog. Previously you had to craft `drive keypress` sends by hand; now `approve` enacts the right keystrokes for you.\n\n```bash\nagentbox agent approvals 1 --json          # list everything box 1 is blocked on: each row has an id + kind\nagentbox agent approve \u003Cid>                # answer that exact prompt (default = approve \u002F first option)\nagentbox agent approve \u003Cid> --option 2     # in-TUI question\u002Fplan: pick option 2 (or --option \"Risk first\")\nagentbox agent approve \u003Cid> --deny         # reject (relay: deny; in-TUI: Escape)\nagentbox agent approvals 1 --wait 600000   # block until something is pending, then act\n```\n\n`kind` is `host-action` (relay), or `plan` \u002F `question` \u002F `permission` (in-TUI). Relay rows carry `command`\u002F`argv`; `question` rows carry the option labels; `plan` rows the plan body.\n\n**The id is a safety token — inspect, then approve that exact id.** `approve \u003Cid>` answers the specific prompt you listed; if a *different* prompt has since taken its place, the recomputed id won't match and the approve is **refused** (it never answers the wrong thing). So always `approvals` → read the `command`\u002F`argv`\u002Foptions → `approve \u003Cid>`, one at a time. Do not blanket-approve whatever a box asks (that defeats the gate against a prompt-injected box laundering a malicious push), and never hand-`curl` `\u002Fadmin\u002Fprompts\u002Fanswer` — these commands are the supported surface. In-TUI keystroke mapping is best-effort and TUI-version-sensitive; if an approve doesn't take, fall back to `drive snapshot` + `drive keypress`.\n\n## PRs through the host relay (`agentbox-ctl git pr …`)\n\nIn-box agents can drive GitHub PRs from inside a box via the host's `gh` CLI. Same model as `git push`: the box has no GitHub token; the relay shells out to `gh` on the host with the user's authenticated gh identity. Requires `gh` installed on the host and `gh auth login` run once.\n\nThe wrapper is `agentbox-ctl git pr \u003Cop> [args...]`. Available ops:\n\n| Op | Prompt? | Notes |\n| --- | --- | --- |\n| `view \u003Cnum>` | no | Read-only. |\n| `list` | no | Read-only. |\n| `create` | yes | Pass-through args (e.g. `--title T --body B --draft`). |\n| `comment \u003Cnum>` | yes | Visible to others. |\n| `review \u003Cnum>` | yes | Visible to others. |\n| `close \u003Cnum>`, `reopen \u003Cnum>` | yes | |\n| `merge \u003Cnum>` | yes (+ bypass guard) | `AGENTBOX_PROMPT=off` auto-`y` is refused here unless `AGENTBOX_GH_FORCE=1` is also set. |\n| `checkout \u003Cnum>` | yes (+ opt-in) | Off by default — switches the host main repo's branch (visible to the box). Enable with `AGENTBOX_GH_PR_CHECKOUT=allow`; a dirty host tree is refused, and a host HEAD on a registered box branch is refused. |\n\nIf a PR op appears to hang, tell the user to check the dashboard footer for the host confirmation prompt. If `gh` is missing or unauthenticated, the in-box command exits 127 \u002F 4 with a clear stderr.\n\n## Other commands worth knowing\n\n| Command | What it does |\n| --- | --- |\n| `agentbox dashboard` | TUI status + switcher across all boxes. The leader is **`Ctrl+a`** (e.g. `Ctrl+a u` opens the box's web URL; `Ctrl+a s` opens the in-box browser; `Ctrl+a q` quits). |\n| `agentbox shell [n\\|name]` | Interactive `bash -l` inside the box (also wrapped in tmux by default — detach with `Ctrl+a d`). |\n| `agentbox url [n\\|name]` | Open the box's web app URL (`\u003Cbox-name>.localhost` via Portless) in the host browser. |\n| `agentbox screen [n\\|name]` | Open the box's **own** Chromium via VNC — useful for OAuth flows the agent inside the box initiates. |\n| `agentbox code [n\\|name]` | Open VS Code \u002F Cursor pointed at the box. |\n| `agentbox prepare --provider \u003Cname>` | One-time base image \u002F snapshot build for `daytona` or `hetzner` or `vercel`. With no `--provider`, prints status across all providers. |\n| `agentbox prune --provider \u003Cname>` | Clean up orphan boxes \u002F images \u002F snapshots for a provider (docker + daytona supported; hetzner pending). |\n| `agentbox cp \u003Csrc> \u003Cdst>` | Copy a file\u002Fdir host↔box (`box:\u002Fpath` prefix picks direction). Heavy dirs (`.git`, `node_modules`, build output) are dropped by default; add `--exclude=\u003Cglob\\|name>` or `--no-default-excludes`. Uploads over `box.cpMaxBytes` (100 MB, post-exclude) are **blocked** with a size breakdown — trim with `--exclude`, copy heavy folders one at a time, or pass `--yes`. |\n\nPer-project numeric index (`1`, `2`, …) and friendly name (`review`, `smoke`) both work wherever `\u003Cbox>` is accepted. Index `1` is the first box created in the current workspace.\n\n## Operating principles\n\n1. **Never assume the host needs SSH keys forwarded into a box** — git is handled by the relay, by design.\n2. **Use `-i` whenever the user asks for parallel agent work** rather than spawning multiple foreground sessions. Then point them at `agentbox dashboard` to watch progress.\n3. **Pick the provider deliberately.** `docker` is the fast default. `--provider hetzner` gives a real VPS (heavier, isolated, requires `agentbox prepare --provider hetzner` once). `--provider vercel` is the managed cloud option.\n4. **Cross-check before recommending a command.** If a flag isn't listed here, run `agentbox \u003Ccommand> --help` (it's safe and read-only) before suggesting it to the user.\n5. **`\u002Fagentbox-setup` is a different skill.** It runs *inside* a box to generate `\u002Fworkspace\u002Fagentbox.yaml`. Don't conflate it with `\u002Fagentbox` (host-side fork) or this reference skill.\n\n## Reference\n\n- Full docs live in the repo at `docs\u002F` — start with `docs\u002Farchitecture.md` and `docs\u002Fcreate-and-checkpoints.md` for the model, `docs\u002Fhost-relay.md` for the relay, `docs\u002Fcloud-providers.md` for the cloud paths.\n- npm package: `@madarco\u002Fagentbox` — `npm -g install @madarco\u002Fagentbox` (or `npx @madarco\u002Fagentbox \u003Ccommand>`).\n",{"name":5,"description":7,"user-invocable":47},"main","2b63f856ce19c2a797929cacabd9e0fc936812fa","plugins\u002Fmadarco\u002Fagentbox\u002Fskills\u002Fagentbox-info",483,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-13 02:16:32",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill agentbox-info",{"tool":67,"command":68},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill agentbox-info",{"tool":70,"command":71},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill agentbox-info","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fmadarco\u002Fagentbox\u002Fskills\u002Fagentbox-info\u002FSKILL.md",true,[],[76,84,91,98,123,148],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":83},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":83},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":83},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":46},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[105,106,107,108,109,110,111,112,113,114,115,28,116,117,118,119,120,27,121,122],"search","deja search","never","error","ready","memory","re","decide","fix","design","debugging","you","done","reviewer","io","change","merge","past",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":46},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[130,131,132,119,133,134,135,136,137,138,139,140,141,142,110,143,144,145,146,147],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":161,"publishedAt":46},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[154,157,158],{"categoryNo":155,"categoryName":156,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":159,"categoryName":160,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[150,162,163,164,165,166,167,144,168,111,169,170,171,172,28,173,174,175,176,177],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]