buidl

Cancel a running loop

Cancel loop and remove worktree + branch

Show learning system health report

Optimize a metric (gas, bundle_size, test_time, throughput) via automated experimentation

Resume an interrupted loop from its last checkpoint

Use this agent during Phase 4 of /buidl after all builders finish but BEFORE the auditor. This is the integration validation specialist -- it checks that contract ABIs match frontend/backend calls, addresses are consistent, and network configs align across all layers. It is READ-ONLY and cannot modify any files. <example> Context: Contract-dev and frontend-dev have both finished. Time to validate integration. user: "All builders done. Run cross-layer validation before audit." assistant: "Launching the cross-layer validator to check ABI-to-frontend method mapping." <commentary> Validator runs AFTER all builders but BEFORE auditor. Catches mismatches early. </commentary> </example> <example> Context: Frontend-dev called a contract method that doesn't exist in the ABI. user: "Validator found ABI mismatch. Route to frontend-dev." assistant: "Launching frontend-dev to fix the contract call." <commentary> Validator findings are routed to the responsible builder for fixes before audit. </commentary> </example>

Use this agent during Phase 4 of /buidl to implement a feature spec in an isolated worktree. The builder writes code, writes tests, and runs the verify pipeline until everything passes. <example> Context: The spec is approved and explorers have mapped the codebase. Time to build. user: "Spec approved. Starting the build phase." assistant: "Launching the builder agent in the worktree to implement the spec." <commentary> Builder gets the spec, codebase context, and any reviewer findings from prior cycles. </commentary> </example> <example> Context: Reviewer found issues in cycle 1. Builder needs to fix them in cycle 2. user: "Reviewer found 3 issues. Starting build cycle 2." assistant: "Launching the builder agent with the reviewer's findings to address each issue." <commentary> Builder receives structured findings and must address each one explicitly. </commentary> </example>

Use this agent to deeply analyze a codebase before implementing changes. Spawned in pairs during Phase 3 of the /buidl command. <example> Context: The /buidl command is in Phase 3 (Explore) and needs codebase understanding before building. user: "Launching explorer agents to understand the codebase before building." assistant: "I'll use the loop-explorer agent to analyze the codebase structure and find relevant code." <commentary> Explorer agents run in parallel: one mapping structure, one finding spec-relevant code. </commentary> </example> <example> Context: The user invoked /buidl with a spec and the system needs to understand existing code. user: "/buidl ./specs/auth/" assistant: "Starting the explore phase. Launching two explorer agents in parallel." <commentary> Before building, explorers learn the codebase so the builder has context. </commentary> </example>

Use this agent during Phase 1 of /buidl to check if an existing solution covers the user's need (build vs buy gate). Runs in background while the challenge interrogation continues. <example> Context: User described an idea and we need to check if something already exists. user: "I want to build a token price chart component" assistant: "Let me check if a suitable existing solution exists before we build from scratch." <commentary> Researcher searches the web for existing tools/libraries that solve the same problem. </commentary> </example>

Use this agent during Phase 5 of /buidl to review a PR produced by the builder. The reviewer is read-only — it cannot modify any code. It reads the PR diff, checks against the spec, and produces structured findings. <example> Context: Builder pushed code and created a PR. Time to review. user: "Builder finished. PR #42 is ready for automated review." assistant: "Launching the reviewer agent to analyze the PR against the spec." <commentary> Reviewer reads the diff via gh, checks spec compliance, and produces structured findings. </commentary> </example> <example> Context: User wants to review an existing PR with /buidl-review. user: "/buidl-review 42" assistant: "Launching the reviewer agent on PR #42." <commentary> Standalone review mode — reviewer checks the PR without a build loop. </commentary> </example>

Audit skill derived from 27 confirmed real OP_NET bugs. Triggers on: audit, review, security check, code review, PR review of OPNet code. Covers: btc-runtime, native-swap, opnet, opnet-node, op-vm, transaction repos. Categories: serialization, storage/pointer, arithmetic/AMM, access-control/crypto, business-logic, memory/bounds, gas/runtime, networking/indexer, type-safety.

This skill should be used when the user describes a new feature idea, wants to start a new project, mentions wanting to build something, or asks about the buidl commands. Proactively suggest the appropriate /buidl command when the user's intent matches. Examples of triggers: "I want to build...", "I have an idea for...", "Let's add...", "How do I use the loop?", "What commands does the loop have?", "build an OPNet contract", "OP20 token", "OP721 NFT", "Bitcoin smart contract", "OPNet frontend", "wallet integration", "NativeSwap", "MotoSwap", "OPNet dApp"

Exhaustive problem-solving methodology for builder agents. Forces systematic debugging, prevents premature surrender, and enforces proactive verification. Auto-triggers when: (1) task fails 2+ times, (2) about to say 'I cannot' or suggest user do work manually, (3) repeating same approach with minor tweaks, (4) fixing something without verifying the fix. Applies to ALL agent types: contract-dev, frontend-dev, backend-dev, builder, auditor.

3 hooks across 2 events