メニュー
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 に表示されている付属ファイルをお読みください。
SOC 職業分類に基づく
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/beevibe-ai/beevibe --skill beevibe-discover-repoコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
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.
| 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.