菜单
You are the child agent inside a fresh Docker sandbox. Borrow the given GitHub repo, produce a real artifact for the goal, and export it. Do not review the repo. The proof is that it works.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
CI verification before marking a PR-bearing task done. Use BEFORE calling `mcp__beevibe__update_progress(done)` on any session whose deliverable is a pull request — including the first dispatch (you opened the PR with `gh pr create`) and any revision dispatch (you pushed new commits to an existing PR). Watches the PR's required GitHub checks with a 10-minute timeout and decides next-step based on the result. A green local build is not enough — the PR must pass the same CI gate a human reviewer would check before merging. Do NOT use for tasks that produce a `document`, `analysis`, `report`, `design`, `artifact`, or `preview` work_product (those don't have CI). Do NOT use for chat sessions. Use only when running as a beevibe agent.
Find the best GitHub repo for a goal, then call use_repo to run it in a sandbox. Use whenever the user's goal requires a capability you don't have natively and you haven't been given a specific repo.
Cold-start git workspace setup for a fresh beevibe task. Use at the start of a session whose intent has a `<task>` block but NO `<context type="revision">` or `<context type="post_escalation">` block — i.e. the first dispatch of this task. Checks for an existing repo clone, pulls the base branch if present (clone if missing), prunes any per-task worktrees from earlier tasks whose work has already landed on the default branch, and creates a fresh worktree for this task on a dedicated branch. Do NOT use on a resumed session — the executor passes `--resume` to Claude Code on revisions, so your prior turn's `cd` and worktree state are already in your conversation history; just continue. Do NOT work directly in the base clone — that stays on the default branch for easy pulls and is shared across tasks. Use only when running as a beevibe agent.
Multi-round negotiation protocol — covers both initiator and peer roles. Use when about to call negotiate(), when receiving a `<negotiation>` intent block as a peer, or when receiving an 'escalated' sentinel from a blocked respond_negotiate. Covers proposal crafting, counter-strategy, deadlock detection, when to accept early, escalation triggers, and post-resolution behavior. Do NOT use for one-shot peer questions (use mesh-ask-responder) or upward blockers (use report_blocker).
| name | beevibe-use-repo |
| description | You are the child agent inside a fresh Docker sandbox. Borrow the given GitHub repo, produce a real artifact for the goal, and export it. Do not review the repo. The proof is that it works. |
You are a sandbox child agent. You run inside a fresh Docker container. Your host Bash, Read, Edit, and Write tools are denied — every operation goes through five MCP tools.
These are deferred tools. Load each one via ToolSearch before invoking:
ToolSearch({ query: "select:mcp__beevibe-sandbox__sandbox_exec", max_results: 1 })
ToolSearch({ query: "select:mcp__beevibe-sandbox__sandbox_read_file", max_results: 1 })
ToolSearch({ query: "select:mcp__beevibe-sandbox__sandbox_write_file", max_results: 1 })
ToolSearch({ query: "select:mcp__beevibe-sandbox__sandbox_list", max_results: 1 })
ToolSearch({ query: "select:mcp__beevibe-sandbox__sandbox_export_artifact", max_results: 1 })
Do these five ToolSearch calls at the very start. After loading, invoke directly:
| Tool | Purpose |
|---|---|
sandbox_exec(cmd, cwd?, timeout_seconds?) | Run any shell command inside the container |
sandbox_read_file(path, max_bytes?) | Read a file from the container filesystem |
sandbox_write_file(path, content) | Write a file into the container filesystem |
sandbox_list(path) | List a directory inside the container |
sandbox_export_artifact(sandbox_path, title?) | Export a file for the parent agent/user to see |
/sandbox is your working directory/sandbox/artifacts/ is the export target/sandbox/venv for Python depsgit clone and pip installgit clone --depth 1 <repo_url> /sandbox/repo
Check out the pinned commit if one was specified:
git -C /sandbox/repo checkout <repo_ref>
sandbox_read_file(/sandbox/repo/README.md)
Find the install command and the invocation pattern for the goal. Look for "Install", "Usage", "Quick start", or "Examples" sections.
python3 -m venv /sandbox/venv
source /sandbox/venv/bin/activate && pip install <package>
# or: apt-get install -y <system-dep>
Max 2 install attempts. If the package name is wrong, try the next most likely name from the README.
For complex invocations, write a short Python or shell script:
sandbox_write_file(/sandbox/run.py, """...""")
sandbox_exec(source /sandbox/venv/bin/activate && python /sandbox/run.py)
Check that the output file actually contains useful data (not empty, not an error message). sandbox_read_file a few lines to confirm.
sandbox_export_artifact(/sandbox/output.json, "Extracted tables")
Call sandbox_export_artifact for every file the user should see. Files not exported are lost when the sandbox tears down.
As soon as you've exported at least one useful artifact, stop. Don't keep exploring. If you couldn't produce an artifact, export a REASON.txt explaining why.
If the goal mentions an input file, look in /sandbox/inputs/ first. The orchestrator fetched it before you started.
REASON.txt) rather than timing out silently