How do I install the Verify skill?

Run npx skillmds@latest add gabrielmoreira/verify in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Verify skill do?

Verify a Bun runtime change by driving the debug binary end-to-end. It is listed under Coding & Dev Tools on SkillMD.

Is Verify safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Verify?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Verify free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Verify?

gabrielmoreira (@gabrielmoreira) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Verify by gabrielmoreira — Agent Skill

Name: Verify
Rating: 4.5 (4 reviews)
Author: gabrielmoreira

File contents

Verify a Bun runtime change

Build and drive the debug binary directly — never bun test, never import-and-call.

Build

bun bd --version   # builds ./build/debug/bun-debug and prints its version

Drive

For any JS-visible change, run the debug binary with -e and observe stdout:

bun bd -e '<repro>'   # builds, then runs; sets BUN_DEBUG_QUIET_LOGS for you

For worker/subprocess-shaped changes, spawn a subprocess (still -e) so worker teardown / event-loop-idle paths are exercised. Cross-check against node -e '<same repro>' for Node-compat changes.

Gotchas

A src/js/** edit can silently not reach the binary. bundle-modules regenerates build/<cfg>/codegen/InternalModuleRegistryConstants.h, but the C++ TU that embeds it is not always recompiled, so the build succeeds while the binary still runs the OLD JS. Gate on the binary, not the build: ask the binary you just built — bun bd -e 'console.log(<Class>.toString().includes("<new-id>"))' (or run ./build/<cfg>/bun directly). Plain bun is the system Bun on $PATH and never has your edit, so it answers about the wrong binary. If false, touch src/jsc/bindings/InternalModuleRegistry.cpp and rebuild.
Prefix every bun bd with PATH="$HOME/.cargo/bin:$PATH" — Homebrew's rust formula shadows the pinned nightly, and bun bd dies with the option 'Z' is only accepted on the nightly compiler. bun bd re-runs cargo on every invocation, so this is needed for follow-up runs too, not just the first build.
node:cluster changes can't be driven with -e: cluster.fork() re-execs argv[1], so workers need a real file on disk. Write a scratch script and run ./build/debug/bun-debug <file>.
Only one bun bd per worktree at a time — a second one blocks on the build lock and looks like a runtime hang. Build once, then drive ./build/debug/bun-debug directly under timeout.
BUN_DEBUG_QUIET_LOGS=1 suppresses debug-build log spam.
Debug builds print [cachefs]/[sys] lines to stdout; filter them before diffing output against node.
MessagePort's .on/.off are added by requiring worker_threads — plain new MessageChannel() ports only have addEventListener until then.
The debug+asan build is 10-100× slower than release; large-allocation stress tests can time out locally while passing in CI.

---name: verifydescription: Verify a Bun runtime change by driving the debug binary end-to-end.---# Verify a Bun runtime changeBuild and drive the debug binary directly — never `bun test`, never import-and-call.## Build```shbun bd --version # builds ./build/debug/bun-debug and prints its version```## DriveFor any JS-visible change, run the debug binary with `-e` and observe stdout:```shbun bd -e '<repro>' # builds, then runs; sets BUN_DEBUG_QUIET_LOGS for you```For worker/subprocess-shaped changes, spawn a subprocess (still `-e`) so worker teardown / event-loop-idle paths are exercised. Cross-check against `node -e '<same repro>'` for Node-compat changes.## Gotchas- **A `src/js/**` edit can silently not reach the binary.** `bundle-modules` regenerates `build/<cfg>/codegen/InternalModuleRegistryConstants.h`, but the C++ TU that embeds it is not always recompiled, so the build succeeds while the binary still runs the OLD JS. Gate on the binary, not the build: ask the binary you just built — `bun bd -e 'console.log(<Class>.toString().includes("<new-id>"))'` (or run `./build/<cfg>/bun` directly). Plain `bun` is the system Bun on $PATH and never has your edit, so it answers about the wrong binary. If false, `touch src/jsc/bindings/InternalModuleRegistry.cpp` and rebuild.- **Prefix every `bun bd` with `PATH="$HOME/.cargo/bin:$PATH"`** — Homebrew's `rust` formula shadows the pinned nightly, and `bun bd` dies with `the option 'Z' is only accepted on the nightly compiler`. `bun bd` re-runs cargo on every invocation, so this is needed for follow-up runs too, not just the first build.- `node:cluster` changes can't be driven with `-e`: `cluster.fork()` re-execs `argv[1]`, so workers need a real file on disk. Write a scratch script and run `./build/debug/bun-debug <file>`.- Only one `bun bd` per worktree at a time — a second one blocks on the build lock and looks like a runtime hang. Build once, then drive `./build/debug/bun-debug` directly under `timeout`.- `BUN_DEBUG_QUIET_LOGS=1` suppresses debug-build log spam.- Debug builds print `[cachefs]`/`[sys]` lines to stdout; filter them before diffing output against `node`.- MessagePort's `.on/.off` are added by requiring `worker_threads` — plain `new MessageChannel()` ports only have `addEventListener` until then.- The debug+asan build is 10-100× slower than release; large-allocation stress tests can time out locally while passing in CI.

Frequently asked questions

Verify