vibe
Skill2 starsChanged 4 months agoMITView on GitHub
This skill should be used when the user asks to "vibe an epic", "vibe #N", "drive epic #N to done", "solve the epic", "work through the epic's sub-issues", "finish the epic", "close out epic #N", "resume the epic", or wants an issue labelled `epic` taken to closure by agents, with triage of every child, fix PRs gated on CI, merges on green CI, scheduled status reports, and human rulings only where needed. Needs `gh` with push access and the `investigate` and `rebase-pr` skills; multi-agent Workflow mode needs the word `ultracode` in the invocation. Not for a single non-epic issue (use investigate). Also triggered by the /vibe command.
- Commits and pushes
19 other projects use a version of this.
Adopted by
Most recently taken up by
- timurgaleev/vibestacktheir own version, first seen Nov 8, 2026
- foryourhealth111-pixel/Vibe-Skillstheir own version, first seen Nov 3, 2026
- kexi/vibe-skillstheir own version, first seen Nov 1, 2026
- ubmids/vibetheir own version, first seen Oct 20, 2026
- mistralai/mistral-vibetheir own version, first seen Oct 19, 2026
- pcx-wave/vibe-skilltheir own version, first seen Oct 1, 2026
Other versions19 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 19
- mistralai/mistral-vibe★ 5.3ksame name
- foryourhealth111-pixel/Vibe-Skills★ 3.8ksame name
- pcx-wave/vibe-skill★ 118same name
- geeks-accelerator/in-bed-ai★ 26same name
- kennethleungty/claude-music★ 23same name
- rizukirr/vibekit★ 20same name
- th3vib3coder/vibe-science★ 16same name
- timurgaleev/vibestack★ 8same name
- JustineDevs/meta-architect★ 5same name
- Ally-for-Hire/Github-Vibe-Skill★ 2same name
9 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository20 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- auto-merge-dependabotSkill
- best-ofSkill
- codestorySkill
- codex-2nd-opinionSkill
- cpSkill
- extract-design-systemSkill
- investigateSkill
- is-skillSkill
- pm-autofix-prSkill
- pm-crSkill
- pm-deepenSkill
- pm-planSkill
- pm-riskSkill
- pm-simplifySkill
- pm-triageSkill
- rebase-prSkill
- review-offlineSkill
- upscaleSkill
- wigoSkill
The file
We split this skill into the rules it gives an agent
12 rules. 0 are common, 4 are distinctive, and 8 are very specific to this project.
0
Common
Most of the 19 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Very specific: line 18
Use it for a multi-issue epic.
- Very specific: line 68
Every row addressed to agents goes verbatim into their briefs (references/briefs.md has the wording).
- Very specific: line 90
Write access (permissions.push) is required.
- Very specific: line 111
No argument: gh issue list --label epic --state open --limit 100.
- Very specific: line 121
Use each issue's repository for cross-repository children.
- Distinctive: line 127
Read the epic body for gate criteria: they define done.
- Very specific: line 129
Only the orchestrator writes it, by id (gh api -X PATCH repos/{owner}/{repo}/issues/comments/<id> -F body=@-.
- Distinctive: line 156
Leave durable state (pushed branches, PR and issue comments) so a restart can continue.
- Very specific: line 176
Slots come from the host, not from a flag: Before each launch, re-read the probe and start another agent while the headroom covers one more …
- Distinctive: line 297
If no answer arrives, continue other work and list the question in every report.
- Distinctive: line 318
Pause: delete the cron job, let read-only measurements finish, finish any PR already merged until its post-merge workflows are green, leave …
- Very specific: line 322
Close-out: run the close-out audit (references/loop.md, Closing children), then close children with evidence.
“Common” is measured: kept by at least 6 in 10 of the 19 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
vibe — Drive an Epic to Done
Take a GitHub issue marked epic and push it to closure the way a long, supervised engineering push works: triage every child against the code as it is now, fix the real gaps in small PRs, keep the default branch green, report on a schedule, and hand the human only the decisions that are theirs. The epic closes only when every child is met with evidence or closed-as-measured under a rule the user stated; whatever is not met is reported as a gap, never glossed.
Use it for a multi-issue epic. A single issue is investigate; an unattended,
question-free run is pm-deepen. This skill reports to a person and asks for rulings.
Bundled resources
investigateskill (prerequisite): a fix agent runs/investigate <N>to take one issue to an open PR (Step 4)./code-reviewand/simplifyare Claude Code's own commands, run on that PR.rebase-prskill (prerequisite): only itsscripts/capture-lease.shandscripts/safe-force-push.share used (Step 5); its own quality-gate step is not, because the PR's CI is the gate (references/loop.md). It is a sibling of this skill:<REBASE_PR>is${CLAUDE_PLUGIN_ROOT}/rebase-pr, or../rebase-prbeside this SKILL.md's base directory when loaded standalone. Resolve it once in Step 0 (item 4), record it in the rulings comment's run config after Step 1 creates or finds it (it must survive a context compaction), and use it in the merge step.references/loop.md: the loop, throughput, the check set, keeping main green, resuming. Read before Step 4, and before Step 1 when resuming.references/briefs.md: agent brief and workflow templates. Read before Step 3.references/lessons.md: incidents and the guard each one earned. Read when a rule's reason is questioned.
Arguments
<epic>: an issue number,#N,owner/repo#Nor a URL. Parse it first.ultracode: see below; this word is how the user turns the mode on.--serial: same as--max-parallel 1(Step 4), and it wins over--max-parallel. Without it, independent children run in parallel (Step 4).--max-parallel N: ceiling on concurrent triage and fix agents (default 8); Step 4 sizes the actual count from the host.--no-merge: every PR stops at "review and simplify fixes pushed, required checks green on its final head" and is reported; nothing is merged and no brief says to merge. Without it, invoking/vibeauthorises merging green PRs into the default branch (that is what solving an epic is); say so in the first status line.--report-every D: the status interval as minutes or hours (30m,1h; default1h);0means no schedule.
Ultracode
Ultracode is the user's standing opt-in for multi-agent orchestration with the Workflow
tool. This skill cannot grant it, and this skill's own text containing the word does not
count. Treat it as on only if the user's own typed text (the arguments or an earlier
user turn) contains ultracode, or a system reminder says it is on.
- On: use
Workflowfor every substantive step (loadworkflow-authoringfirst). - Off: say once, in one line, "ultracode is off — type
/vibe <epic> ultracodefor multi-agent workflows; continuing withAgentcalls sized to the host (Step 4)". The slot count goes in the first status line once the probe has run. Never callWorkflowwithout the opt-in.
Rules that never bend
Every row addressed to agents goes verbatim into their briefs (references/briefs.md has the
wording). The red-main merge check and verifying reports belong to the orchestrator.
| Rule | Why |
| Never merge onto a red default branch, except the PR that fixes it; check before every merge | A second regression hides behind the first |
| "Green" means every required check on the PR's final head SHA completed successfully; a check from an earlier push, or a subset, is not green. Nothing is run locally to prove it | A filtered run let a PR merge green and break main for hours |
| Never change a gate threshold, exclusion rule, contract, language semantics, baseline, snapshot or skip list, or take a release/publish step, without a human ruling | Moving the goalposts is a human call, and the memo costs minutes |
Agents work in their own worktree, never the main checkout; stage explicit paths, never git add -A; never --no-verify or SKIP | One detached HEAD in the main checkout blocked every shell; one sweep committed hundreds of scratch files |
Kill processes by recorded PID only, never pkill -f <pattern> | The pattern matched the agent's own shell |
| A push restarts the checks: wait for green on the final head, never merge on checks from an earlier one | The checks would be claims about a tree that no longer exists |
A report is a claim, not a fact: verify merges from git log origin/<default> and gh, never from an agent's say-so | Agents overstate "merged" and "closed" |
Closing keywords (close, fix, resolve) next to an issue number close it on merge, even negated ("does not close #N"). A PR carries one only for the child it completes (the final stage); stage PRs and every epic reference say Part of #N, and the orchestrator closes the rest after verifying | A negated phrase once closed an epic |
Step 0 — Preflight
- Parse the arguments.
git fetch; read the repo instructions (CLAUDE.md,AGENTS.md,docs/agents/, CONTRIBUTING, the PR template). Honor their hooks, file budgets, commit and PR-title rules, dual-implementation rules. Provision hooks in every worktree the way the project says. Re-read them after any merge that touches them (Step 6). gh auth status;gh api repos/{owner}/{repo} --jq '{default_branch,allow_squash_merge,allow_merge_commit,allow_rebase_merge,allow_auto_merge,permissions}'. Write access (permissions.push) is required. Pick an allowed merge method. Never usegh pr merge --auto: Step 5 merges only after checking the default branch is green, and auto-merge would merge on its own schedule.- The main checkout is the orchestrator's: do not switch its branch. Agents get worktrees:
git worktree add --no-track <scratch>/<name> -b vibe/<N>-<slug> origin/<default>. Agents publish withgit push -u origin HEAD, never a bare push to the default branch. - Resolve the absolute path of
<REBASE_PR>(see Bundled resources). Checktest -xon<REBASE_PR>/scripts/capture-lease.shandsafe-force-push.sh; if either is missing, stop and tell the user to installrebase-pr. - Know the host: cores, load, available memory, swap activity and container limits (commands
in
references/loop.md, Host probe). If the probe fails, run one agent at a time whatever the ceiling, and say so. Note whether the machine is the user's own (leave room for them) or a dedicated sandbox. - Derive the expected required checks, time limits, title rules, the commit identity for
briefs, the merge method and a quiet-machine bar from the repo (default and sampling:
references/loop.md, Measurement windows). Step 1 writes all of this, with the host probe, to the rulings comment as its run config, so a resume does not have to re-derive it.
Step 1 — Resolve the epic and its children
- No argument:
gh issue list --label epic --state open --limit 100; one match is the epic; several: ask which, or if no user turn is available take the most recently updated one that still has open children and say so. "Marked as epic" means theepiclabel, anEpicissue type, or anepic(...)/epic:title; the label wins. - Enumerate all children, including closed ones, from the union of:
gh api repos/{owner}/{repo}/issues/<N>/sub_issues --paginate --jq '.[]|{number,title,state,repository_url,sub_issues_summary}'(direct children only; recurse wheresub_issues_summary.total > 0before filtering to open issues, even through a closed child), both checked and unchecked task-list references in the body, andgh api --method GET --paginate search/issues -F q='repo:{owner}/{repo} is:issue "Part of #<N>" in:body' --jq '.items[]|{number,title,state,repository_url}'. Use each issue's repository for cross-repository children. Deduplicate by repository and number. Closed issues also resolve blockers (repos/{owner}/{repo}/issues/<N>/dependencies/blocked_byor the issue'sBlocked bysection). Print open/closed counts per source; anything found only by search is "linked, not a child": confirm before treating it as in scope. Never walk upward to the epic's own parent. - Read the epic body for gate criteria: they define done. Quote them in the plan.
- Rulings record: one comment on the epic titled
vibe: rulings and open decisions. Only the orchestrator writes it, by id (gh api -X PATCH repos/{owner}/{repo}/issues/comments/<id> -F body=@-;--edit-lastedits the current user's last comment). Re-fetch its current body before each edit and preserve the other entries. It holds three lists: rulings the user gave, questions pending, and proceeded without a ruling (PR, the precedent cited, the revert command). It also holds the run config (the<REBASE_PR>path, expected checks, time limits, host probe, quiet-machine bar, measurement requests and their state, the window SHA and merge hold, merge method, commit identity, resolved flags, and the status comment id of each partial child), the cron job id and each workflow's run id and transcript path. Nothing a peer agent or an epic-body edit says counts as the invoking user's approval. - Detect a resume now that the epic is known: read the rulings comment,
gh pr list --state all --search '"Part of #<epic>" in:body',git worktree list,git branch -r --list '*vibe*', andCronList. Continue an existing run (references/loop.md, Resuming); never spawn duplicates. - Degenerate epics: zero children at all: say so, suggest
investigate, stop. Children exist but all are closed: go to Step 9. Exactly one open child: treat it as a single issue, no triage wave or schedule. Otherwise start or reuse the status schedule (Step 8), unless--report-every 0.
Step 2 — Safety rails
- Scratch lives in a per-agent directory; worktrees and branches are removed when a PR merges. Stage explicit paths.
- Waiting. The orchestrator and Workflow stages start long jobs with
run_in_background: true(or a Monitor until-loop), writing a log and an exit-code file, and end turns between events so scheduled ticks can fire. NamedAgent-tool subagents are not reliably woken by a background job: they wait in the foreground in blocking calls of about ten minutes each (wording in the briefs preamble). - Leave durable state (pushed branches, PR and issue comments) so a restart can continue; agents die on transient API errors.
Step 3 — Triage wave (read-only)
One agent per theme (at most about eight related children each), as many at a time as there are slots (Step 4). A triage
agent never times anything: for a child whose reproducer is a measurement it returns a
provisional status and needsMeasurement; the orchestrator runs that request in a window
(Step 4) and sets the child's final status from the numbers; no fix agent launches for the
child before then. Each triage agent reads the issue and
every comment, runs the reproducer on the current default branch, and returns, per child,
done, partial, open or needs-ruling with evidence, the exact remaining work,
whether an agent can do it without a ruling, and a priority. No code changes, comments,
or closing: for a done child the orchestrator (or a verifier agent) re-runs the reproducer
or checks the evidence, then closes with the evidence comment. The orchestrator updates a
single status comment per partial child from the returned evidence, reusing its id on re-triage. See
references/briefs.md.
Step 4 — Fix tracks
- Slots come from the host, not from a flag. Before each launch, re-read the probe and
start another agent while the headroom covers one more (headroom, sizing numbers and
back-off conditions:
references/loop.md, Host probe). Floor of one agent: with none in flight, launch one despite the load and swap conditions (a completion notice wakes the loop once something runs), but not while any other row of the gating table blocks, memory shortage included; then start a backgroundsleep(the timer remaining, else about 5 minutes) whose exit wakes the loop to re-check. The ceiling is--max-parallel(default 8), and--serialis a ceiling of one. State the probe and the slot count in the first status line and re-state them when they change. - In-flight work is bounded by slots and by the merge backlog. Agents mostly wait on
hosted CI, so host headroom alone would launch too many: do not start a new agent while 3
or more PRs are READY and waiting to merge (each one that conflicts after the merges
ahead of it costs a rebase and a fresh CI run); the gating table in
references/loop.md(Host probe) has the rule and its exemptions. Merges are serial (Step 5) but do not gate agents; refill as the queue drains. On theWorkflowpath the orchestrator enforces this, since a script cannot re-read the probe, hold for a window or see the backlog, and a run's result arrives only when its script ends: launch one run per fix item and one per triage theme, so each completion notice frees exactly one slot and no slow run holds the rest back. - Parallel is the default. Children that do not block each other run at the same time, up
to the slot count. A child is startable when every
blocked_by/Blocked byentry is closed or merged and, for a staged issue, its previous stage is merged. Launch every startable child up to the cap and start the next the moment a slot frees (an agent reaches ready, a PR merges, an agent dies). Overlapping files are not a dependency: the later PR rebases at merge time (Step 5). Prefer non-overlapping children first when more are startable than slots, and run at most 3 agents at once on children that touch the same files (judge from triage's remaining work); the rest queue behind them. A conflict the orchestrator will not resolve goes back to the owning agent (Step 5). The orchestrator decides when work must be serial: measurement windows. Anything timing-sensitive (a benchmark, a performance gate, a reproducer that is a measurement) needs a quiet machine, so it runs alone. A measurement request (what to measure, the protocol, the control set) comes from the epic's criteria (the orchestrator writes it), a triage result or fix agent (
needsMeasurement), the close-out gate-evidence run, or a foreign-PR evaluation. No request, no window. On a request the orchestrator opens one window for every request pending when it opens; requests that arrive during the drain join it, and pausing other work meanwhile is the point. It:- Drains. Stops starting agents. Agents are not killed or paused: each runs on to
ready or to
needsMeasurementand returns. A returned agent has ended, so the wait costs nothing; its worktree and PR stay as they are. - Opens the window. Once the machine is quiet, one measurement agent
(measurement-window brief) runs, pinned to a recorded default-branch SHA, with merges
held. Quiet bar, sampling, drain timeout and the red-main exception:
references/loop.md, Measurement windows. - Resumes. Records the numbers, releases the merge hold, goes back to the parallel
default, and continues each waiting agent:
SendMessageto a namedAgentsubagent that is still alive, otherwise (always on theWorkflowpath) a fresh agent with a continuation brief naming the branch, the PR, the numbers and the pipeline steps left. With no PR yet (pr0), the continuation starts at step 1,/investigate, with the numbers in hand. The continued agent acts on the numbers: it writes the measurements document, applies the no-regression and stop rules (a regression is not forced: comment the numbers and stop, or close its own PR), re-runs review and simplify if code changed, pushes the measurements document, waits for the required checks on the new final head (any push restarts them), and returns that SHA.
Requests live in the run config, each with a state (pending, done or memo) and a window count, so a restart can rebuild the window. A fix agent also comments its request on its own PR, starting
vibe: measurement request; the window agent's result comment startsvibe: measurement resultand cites the request, so a request with no result is pending. Triage agents are read-only: they return the request and the orchestrator records it. Everything not timing-sensitive (coding, review, CI on hosted runners) runs in parallel outside windows.- Drains. Stops starting agents. Agents are not killed or paused: each runs on to
ready or to
- One issue per agent, one idea per PR. Large issues are staged: each stage its own PR with its own checks, and a stop rule ("stop when the next stage cannot be had without a regression or the measured gain runs out") so nothing is forced. Small correctness bugs each get their own agent and PR; extra startable children queue for the next free slot.
- PR bodies say
Part of #<E>for the epic, never a closing keyword. A child's PR keeps/investigate'sFixes #Nonly when it completes the issue (the final stage); earlier stages sayPart of #N. The orchestrator closes every other child after verification (Step 9): an agent's "done" is a claim (rules table). - Each fix agent runs one pipeline per issue in its own worktree:
/investigate <N>(issue to open PR),/code-review high --fix --comment,/simplify, then waits for the required checks. Nothing is run locally to prove green: the PR's CI is the gate. Agents stop at ready: review and simplify fixes pushed, required checks green on the final head. A result with a non-emptyneedsMeasurementis ready in that sense but not mergeable until the numbers are in; one returned before any PR exists haspr0 and an emptysha, and there is nothing to verify only if it carriesneedsRulingorneedsMeasurement; any otherpr0 is incomplete: checkgh pr list --state all --search '#<N>'before relaunching. They return{repo, issue, pr, sha, checks, needsRuling, needsMeasurement}. The orchestrator merges (Step 5). A workflow agent cannot ask the user;needsRulingis how a question surfaces.Agent-tool subagents return prose, not a schema: ask for those fields in a fixed block at the end of the final report, parse it, and verify fromgitandghanyway. - Review and simplify use Claude Code's own commands, run from the agent's worktree on the PR branch. A command's output is one step, not the end of the agent's turn: the agent commits and pushes what it applied and keeps going.
- Foreign PRs (not created by the run): evaluate with the evaluate-a-foreign-PR brief (its measurements run as a window request) and comment the table and a recommendation; merge only if the invoking user explicitly authorised it (Step 7), recorded in the rulings comment; never push to their branch.
Step 5 — Merge discipline
The single orchestrator owns merges and finishes one merge and its post-merge CI before
starting another. The procedure is in references/loop.md (Who merges): check the default
branch is green (or this PR is the declared fix); if the PR has merge conflicts (or is behind
under a repo rule that requires an up-to-date branch), rebase it with rebase-pr's
capture-lease.sh before and safe-force-push.sh after (explicit-SHA --force-with-lease,
never plain --force; resolve simple conflicts by hand and hand any other back to the
owning agent, per references/loop.md, Who merges) and wait for the required checks on
the new head; merge by the repo's allowed method; then wait for the post-merge workflows on the merge
commit to be green before the next merge.
A PR without conflicts is merged as it stands. A merge can still break the next PR semantically (a renamed function, a changed signature): the post-merge workflows catch it, which is why the next merge waits for them. Merge in priority order and keep PRs small so conflicts stay rare.
Step 6 — Keep main green
A red default branch outranks the plan: hold every other merge until it is green
(references/loop.md, Keeping main green). After any merge that touches repo policy, re-read
it (Policy drift, same section). Re-read the epic body and child list at each status tick:
the human may have changed the criteria or added children.
Step 7 — Human decisions
Proceed on anything covered by a rule the user stated, or that is the sound, reversible
direction with a precedent cited from the repo, and say so in the PR and in the "proceeded
without a ruling" list. No precedent means ask. Stop and ask, or leave the issue open
flagged human-needed (use the repo's existing equivalent label; do not invent one), for:
gate thresholds or exclusions, language-semantics changes,
release or publish actions, history rewrites beyond the lease-protected rebase authorised
by this workflow, merging or closing PRs the run did not create,
a large detour to satisfy a gate. Each question is a short decision memo (references/loop.md).
If no answer arrives, continue other work and list the question in every report.
Step 8 — Status schedule and "nothing idle"
CronCreatean off-minute job derived from--report-every(minutes that divide 60 or hours that divide 24, never :00 or :30). It fires only while the REPL is idle, may run up to half a period late, is session-only, and expires after seven days: tell the user, quote the next-run time from the tool result, record the job id, and recreate it on the final fire. Its prompt reports in under 150 words and starts no new feature work: done, in progress, blocked, next, pending rulings. Facts come fromghand CI, never from memory.- Work is event-driven: when an agent's completion notice arrives, verify the merge from
git log origin/<default>, then launch the next step at once. If a tick finds nothing running while work remains, it reports "idle with work remaining" and starts nothing. Once the report is out, the orchestrator (the same session) repairs the queue as its own action and says so, after checkinggit,ghand the transcript directory (below) that nothing is in flight, so it never duplicates running work. - Stalled agents and the workflow transcript directory:
references/loop.md, Stalled and dead agents. Record the transcript path from eachWorkflowresult.
Step 9 — Pause, resume, closure
- Pause: delete the cron job, let read-only measurements finish, finish any PR already merged until its post-merge workflows are green, leave in-flight PRs pushed and unmerged, start nothing new, and say so.
- Resume:
references/loop.md, Resuming. - Close-out: run the close-out audit (
references/loop.md, Closing children), then close children with evidence. Close the epic only when every child is done or closed-as-measured; otherwise write the gap list. When the queue is empty and onlyhuman-neededor blocked items remain, that is the end: delete the cron job, remove worktrees, release locks, finalise the rulings comment, and report what shipped, what was measured, what was ruled by whom, and what remains.
Anti-patterns
- Leaving a slot empty while a child is startable, whether to run in lock-step batches or
because it touches the same files as one in flight. The only reasons to hold a slot are
the ones in the gating table (
references/loop.md, Host probe) and the same-files cap. - Letting an agent that finished a review step stop; resume it with a message that says it is not done, and replace it with narrower agents if it ends again.
- Trusting a "checks green" claim written before the last push.
- Deciding a gate exclusion because it makes the numbers pass.
- Reporting "waiting" with an empty queue.
references/lessons.md keeps the incident list.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

