菜单
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.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/beevibe-ai/beevibe --skill beevibe-discover-repo命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
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.
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.
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.
基于 SOC 职业分类
正在显示 SKILL.md
| name | beevibe-discover-repo |
| description | 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. |
You are choosing an open-source GitHub repo to borrow as a tool for the user's goal. The repo runs inside an isolated Docker sandbox — you don't need to install it on the host.
The user's goal needs a tool you don't have natively (PDF parsing, video conversion, web scraping, ML inference, format conversion, an obscure CLI). You haven't been told which repo to use. The goal has enough concrete nouns/verbs to drive a search.
Call find_repo({ goal }) — pass the user's goal in plain
language. The tool returns the top 5 candidates already ranked by
four signals you don't need to manage yourself:
learned — this team has saved this recipe before (highest trust)community — the beevibe community registry has a proven matchboost — curated for common task families (day-one reliability)github — raw GitHub search with popularity scoreEach candidate comes with repo_url, score, source, reason,
and (when GitHub-enriched) description and stars.
Pick the best fit. Read the description and reason for the
top candidates. Your judgment is the qualitative match between the
description and the user's actual goal. The ranker already filtered
the volume; you just choose between a handful of good options.
Call use_repo({ goal, repo_url }) with your pick. The sandbox
loop takes over from there.
If find_repo returns no candidates, tell the user the goal is too
vague for a meaningful search and ask for more specifics (concrete
input format, output format, or a tool name they've heard of).
find_repo does NOT doIt does not fetch READMEs or read code. It surfaces ranked candidates based on metadata. The README-fit judgment is yours — and if your pick turns out to be wrong, the sandbox run itself is the real test: a fundamentally unsuitable repo will fail to install or fail to produce an artifact, and the next attempt should try a different candidate.
The sandbox gives the cloned repo write access to /sandbox only. It
cannot touch the user's host filesystem, secrets, or browser session.
Every command goes through sandbox_exec. The trust boundary is Docker.