메뉴
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.
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.
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.
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-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.