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

Review an existing PR with the loop reviewer agent

Refine an idea into a spec without building

Show current loop state

Show agent execution trace for the current loop session

Full dev lifecycle: idea → challenge → spec → build → review → ship

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>

Use this agent during Phase 4 of /buidl (Step 2c.5) to perform adversarial invariant testing against OPNet smart contracts. This agent is READ-ONLY -- it analyzes contract source and spec to construct attack sequences that could violate stated invariants. <example> Context: The pattern-based audit (Step 2c) passed. Before deployment, the adversarial auditor runs. user: "Audit passed. Run adversarial invariant testing before deployment." assistant: "Launching the adversarial auditor to construct attack sequences against contract invariants." <commentary> The adversarial auditor reads requirements.md to extract invariants, then reads contract source to find input sequences that could violate them. It does NOT modify code. </commentary> </example> <example> Context: A staking contract claims "users cannot withdraw more than their staked balance." user: "Verify the staking invariants with adversarial testing." assistant: "Launching the adversarial auditor to test the 'no over-withdrawal' invariant with edge-case inputs." <commentary> For each invariant, the auditor constructs specific input sequences (zero amounts, max u256, rapid stake/unstake, multi-caller interleaving) to test the claim. </commentary> </example>

Use this agent during Phase 4 of /buidl (Step 2e.5) to run adversarial E2E tests against deployed OPNet contracts. Unlike the happy-path E2E tester, this agent specifically targets boundary values, revert exploitation, access control bypass, and race conditions with real on-chain transactions. <example> Context: Happy-path E2E tests passed. Before UI testing, adversarial E2E tests run. user: "Happy-path E2E passed. Run adversarial on-chain tests." assistant: "Launching the adversarial tester to send boundary-value and attack transactions on testnet." <commentary> The adversarial tester sends real transactions targeting edge cases that happy-path tests miss: zero amounts, max values, unauthorized callers, rapid sequential calls. </commentary> </example> <example> Context: A token contract is deployed. The adversarial tester checks for transfer edge cases. user: "Test the deployed OP-20 contract for transfer edge cases." assistant: "Launching the adversarial tester to attempt zero transfers, self-transfers, and over-balance transfers." <commentary> Each test sends a real transaction and verifies the on-chain result (revert or success) matches the expected behavior from the spec. </commentary> </example>

Use this agent during Phase 4 of /buidl to perform security audits on OPNet dApp code. This is the security specialist -- it reviews contracts, frontend, and backend code for vulnerabilities. It has READ-ONLY access and cannot modify any files. <example> Context: All builder agents have finished. Time for security audit before deployment. user: "Contract, frontend, and backend are built. Run the security audit." assistant: "Launching the auditor agent to review all code for OPNet-specific vulnerabilities." <commentary> Auditor runs after ALL builders finish but BEFORE deployment. Any CRITICAL/HIGH finding blocks deployment. </commentary> </example> <example> Context: Builder fixed audit findings. Need to re-audit. user: "Contract-dev fixed the reentrancy issue. Re-run the audit." assistant: "Launching the auditor agent to verify the fix and check for remaining issues." <commentary> Auditor re-runs after fixes to verify they're correct and haven't introduced new issues. </commentary> </example>

Use this agent during Phase 4 of /buidl to build OPNet backend services with hyper-express. This is the backend specialist -- it builds APIs, WebSocket servers, and database integrations. It does NOT write smart contracts, frontend code, or deployment scripts. <example> Context: Contract ABI is ready. The spec requires a backend API for indexing and serving data. user: "Contract compiled. Build the backend API for indexing token transfers." assistant: "Launching the backend-dev agent to build the hyper-express API server." <commentary> Backend-dev runs in parallel with frontend-dev after the contract ABI is available. </commentary> </example> <example> Context: Reviewer found the backend is missing rate limiting on public endpoints. user: "Reviewer: MAJOR - no rate limiting on /api/transfers endpoint." assistant: "Launching the backend-dev agent to add rate limiting." <commentary> Backend-dev addresses reviewer findings specific to the backend layer. </commentary> </example>

Use this agent during Phase 4 of /buidl to write OPNet smart contracts in AssemblyScript. This is the contract development specialist -- it writes contracts, unit tests, compiles WASM, and exports the ABI. It does NOT write frontend, backend, or deployment code. <example> Context: The orchestrator has approved a spec for an OP-20 token. Contract development is Step 1. user: "Spec approved. Build the smart contract for the OP-20 token." assistant: "Launching the contract-dev agent to write the AssemblyScript contract and tests." <commentary> Contract-dev is the first builder agent in the pipeline. It must produce compiled WASM + ABI before frontend/backend can start. </commentary> </example> <example> Context: The auditor found a reentrancy vulnerability in the contract. Contract-dev needs to fix it. user: "Auditor found CRITICAL: reentrancy in stake() method. Fix and recompile." assistant: "Launching the contract-dev agent to address the audit finding and recompile." <commentary> Contract-dev receives specific audit findings and must fix them, then re-run the verify pipeline. </commentary> </example> <example> Context: The reviewer found the contract is missing a method that the spec requires. user: "Reviewer: MAJOR - spec requires unstake() method but contract only has stake(). Add unstake()." assistant: "Launching the contract-dev agent to implement the missing unstake() method." <commentary> Contract-dev addresses reviewer findings that are contract-specific. </commentary> </example>

Use this agent during Phase 4 of /buidl to deploy OPNet smart contracts to testnet or mainnet. This is the deployment specialist -- it handles TransactionFactory deployment, verification, and recording of deployment receipts. It does NOT write application code. <example> Context: Audit passed. Time to deploy the contract to testnet. user: "Audit PASS. Deploy the contract to OPNet testnet." assistant: "Launching the deployer agent to deploy and verify the contract on testnet." <commentary> Deployer only runs after audit PASS. Testnet deployment is automatic. Mainnet requires user approval. </commentary> </example> <example> Context: User approved mainnet deployment after successful testnet testing. user: "Testnet deployment verified. Deploy to mainnet." assistant: "Launching the deployer agent for mainnet deployment." <commentary> Mainnet deployment only happens after explicit user approval via the orchestrator. </commentary> </example>

Use this agent during Phase 4 of /buidl to run REAL on-chain end-to-end tests against a deployed OPNet contract. This agent writes and executes test scripts that send actual transactions on testnet using test wallets — not simulations, not mocks, not Playwright. It verifies that every contract method works when real BTC is on the line. This is the final gate before anything is declared "ready." If this agent doesn't pass, the build is not done. <example> Context: Contract deployed to testnet. Deployer produced receipt.json with contract address. user: "Contract deployed at opt1s... Run the on-chain E2E tests." assistant: "Launching the E2E tester agent to run real transactions against the deployed contract." <commentary> E2E tester runs AFTER deployment. It uses real test wallets with real testnet BTC. Every contract method gets a real transaction, not just a simulation. </commentary> </example> <example> Context: NFT marketplace deployed. Need to test full purchase flow across two wallets. user: "Marketplace deployed. Test the full list -> reserve -> executeBTC flow with seller and buyer wallets." assistant: "Launching the E2E tester to run the cross-wallet purchase flow on testnet." <commentary> For multi-party flows (marketplace, swap, auction), the E2E tester creates scripts that use multiple test wallets to simulate real user interactions. </commentary> </example>

Use this agent during Phase 4 of /buidl to build OPNet dApp frontends with React + Vite. This is the frontend specialist -- it builds wallet-connected, dark-mode, production-ready UIs. It does NOT write smart contracts, backend code, or deployment scripts. <example> Context: Contract-dev has finished and exported the ABI. Frontend development is Step 2. user: "Contract compiled. ABI ready at artifacts/contract/abi.json. Build the frontend." assistant: "Launching the frontend-dev agent to build the React dApp with WalletConnect integration." <commentary> Frontend-dev receives the ABI and builds the UI layer. It runs in parallel with backend-dev if both are needed. </commentary> </example> <example> Context: The reviewer found the frontend is missing error handling for failed transactions. user: "Reviewer: MAJOR - no error handling when sendTransaction fails. Add error states." assistant: "Launching the frontend-dev agent to add transaction error handling and user feedback." <commentary> Frontend-dev addresses reviewer findings specific to the frontend layer. </commentary> </example> <example> Context: The UI tester found console errors and missing elements on the main page. user: "UI tester: FAIL - 3 console errors on load, wallet button not rendering." assistant: "Launching the frontend-dev agent to fix the rendering issues and console errors." <commentary> Frontend-dev fixes UI issues found by the tester agent. </commentary> </example>

Use this agent during Phase 4 of /buidl to test OPNet dApp frontends with Playwright. This is the UI testing specialist -- it runs smoke tests, E2E tests with wallet mocking, visual regression tests, and captures screenshots. It does NOT write application code. <example> Context: Frontend is built and contract is deployed to testnet. Time for UI testing. user: "Frontend built, contract deployed. Run UI tests." assistant: "Launching the UI tester agent to run smoke tests and E2E tests with wallet mock." <commentary> UI tester runs after deployment so it can test against the deployed contract address. </commentary> </example> <example> Context: Frontend-dev fixed UI issues. Need to re-test. user: "Frontend-dev fixed the rendering issues. Re-run UI tests." assistant: "Launching the UI tester agent to verify the fixes." <commentary> UI tester re-runs to verify that fixes resolved the reported issues. </commentary> </example>

Use this agent during Phase 2B of /buidl to generate TLA+ formal specifications from contract requirements. This agent translates requirements into TLA+ specs that TLC can verify, catching design-level bugs (race conditions, state invariant violations, ordering bugs) before any code is written. <example> Context: Phase 2 complete, requirements.md approved. Time for formal verification. user: "Requirements approved. Generate the TLA+ spec for this contract." assistant: "Launching the spec-writer agent to produce the TLA+ formal specification." <commentary> Spec-writer runs after requirements are approved but before any code is generated. It produces a .tla and .cfg file for TLC verification. </commentary> </example> <example> Context: TLC found an invariant violation. Spec-writer needs to fix the spec. user: "TLC violation: BalanceConservation violated. Counterexample in violations-iter-1.json." assistant: "Launching the spec-writer agent to fix the specification based on the counterexample." <commentary> On violation, spec-writer receives the counterexample trace and must fix the DESIGN, not just suppress the check. </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