[!IMPORTANT] Release status

Release package v0.10.2 supports Node.js 22+ for the portable Skill; source and release gates require Node.js 24+. Its bundled status retains publicationStateVerified: false; verify the public tag, GitHub release, and installed bytes before treating it as published or live. Package checks and public CI do not establish model behavior, an independent audit, project approval, deployment, routing, registration, or launch authority.

Programmable v4 Builder is an evidence-first Agent Skill. It accepts a plain idea or an existing public repository. Hooks, tokens, apps, games, services, standalone settlement systems, and mixed projects can all be modeled.

The Builder does not limit unfamiliar work to a fixed catalog. Starters and capability packs speed up repeated work; unknown ideas remain eligible for architecture review. Local checks stay separate from maintainer review, launch authority, deployment, provider support, and public availability.

Install the immutable release

After confirming that GitHub exposes the immutable v0.10.2 release, preview that exact Skill before installing it:

gh skill preview 0xprogrammable/hookbuilder \
  [email protected]

Install the same immutable release for Codex:

gh skill install 0xprogrammable/hookbuilder \
  skills/programmable-v4-hook-builder \
  --agent codex \
  --scope user \
  --pin v0.10.2

GitHub's gh skill commands are in preview. Clean package placement has been checked for Codex, Claude Code, and GitHub Copilot; host behavior remains a separate question. See Portability and lifecycle before choosing another destination.

From the installed Skill directory, verify its package:

node scripts/verify-skill.mjs --installed

At the start of each build, cli.mjs policy reads the exact current 0xprogrammable/submit-launch:main build rules. Those returned Rule IDs are the only Programmable launch requirements; bundled security guidance cannot add another.

Then give your agent one clear request:

Use the Programmable v4 Builder skill. Build and check this project, then prepare its exact application for Submit a Launch. Submit the draft only when I explicitly authorize the GitHub write: <idea or public GitHub URL>

What the Builder does

Stage Output
Understand Preserves the stated product intent and isolates the owner choices that materially change it.
Design Produces the smallest complete architecture, capability graph, value flow, and repository plan.
Build Uses composable starters and capability packs without treating them as an allowlist.
Check Runs deterministic validation, intent-fidelity checks, security boundaries, and executable evidence where available.
Bind Closes over the exact public source repositories, commits, trees, files, and required evidence.
Prepare Freezes the exact source revision and evidence needed by a separate Applicant review request.

The Builder loads only the protocol, runtime, liquidity, service, and security material relevant to the confirmed project. Every canonical catalog capability must have an explicit knowledge route or routing fails closed. The optional Project Compiler --brief view shortens presentation only; it preserves the full report identity, result, and evidence boundary.

flowchart TD
  A["Idea or public repository"] --> B["Intent and material owner choices"]
  B --> C["Architecture and repository plan"]
  C --> D["Implementation and local checks"]
  D --> E["Exact source revision and evidence"]
  E --> R["Submit a Launch application"]
  R --> F["Programmable maintainer review"]
  F -. "separate authority and evidence" .-> G["Launch authorization"]
  G -. "separate authority and evidence" .-> H["Deployment and public availability"]

Inspect the local router on the development source:

node skills/programmable-v4-hook-builder/scripts/cli.mjs context --mode explore

Submit a hook for review

All new one-off applications go through the Builder to 0xprogrammable/submit-launch, immutable GitHub repository ID 1320171831. Project source stays in the builder's own public repository.

Every complete project with exact public source and a valid closed package uses the public Application V3 path. PROJECT_PREFLIGHT_VALID is optional stronger execution evidence, not a Draft admission requirement. The local application command derives a closed 3.1.0 package from Submission V2, exact source, review, security, and verifier evidence. When no legacy Fee V2 contract was selected, the package declares feeApplicability: "not-selected" and omits rather than fabricates Fee V2 records. The no-write handoff preview and local validator remain available for inspecting the exact bytes. See the generic handoff contract.

The namespaced open-world submit, update, and status commands read the protected base active-contract manifest and the accepted V3 schema at that exact commit. A submit or update first returns a read-only plan bound to those bytes, the source closure, and the intended draft pull request. It never means reviewed, approved, deployed, or live.

The top-level prepare-pr, submit, update, and status commands preserve the historical six-file transport only. Do not use them for a new project. New submissions use the namespaced Application V3.1 commands above, and no application pull request should be assembled by hand.

prepare-canary is a separate hidden, non-production workflow-test path. It returns the exact canonical application.json bytes and plan digest. Automated local writing currently fails closed because the portable client does not yet bundle a descriptor-bound writer; it never writes GitHub or grants launch authority. See the workflow-canary client contract.

The older Applicant files in this Hookbuilder repository are frozen legacy continuations. Only pull requests #10, #11, #12, #14, #15, #18, #19, and #20 may continue on that path, and only against Hookbuilder main. Every new application belongs in Submit a Launch. Neither path approves, deploys, signs, routes, or launches a project. See the Submit a Launch guide.

Build it with us

The Builder is maintained by Programmable and developed in public. Contributions are welcome when they improve its accuracy, composability, efficiency, testability, portability, or documentation without weakening evidence bounds.

If you found or need Start here
A reproducible defect Open a bug report
A missing capability, source, or integration Propose a capability
A code, documentation, template, or evaluation change Read the contribution guide
A possible vulnerability Report it privately

Each rule has one owning layer. Change the canonical contract and its tests instead of copying policy into several files. Pull requests should name the problem, owning layer, checks run, and remaining evidence boundary.

Evidence boundaries

A result can establish It does not establish
A specific local check passed for exact bytes An independent audit or a guarantee that code is safe
A package was placed and verified for one host directory That the host selected or executed the Skill correctly
An exact Applicant review request was prepared Maintainer acceptance, launch authorization, or deployment
Deployment or source/runtime evidence exists Provider indexing, quoting, simulation, execution, or public availability
A project resembles an existing template or model Duplication, ineligibility, or unsafe behavior

The Builder builds and checks. It does not approve routes, execute trades, audit, deploy, list, endorse, or launch. Every external write, signature, deployment, publication, credentialed provider action, and material cost requires separate authority.

  • Fee applicability follows the exact project graph. Zero-scope work must not invent a market, PoolKey, hook, or fee receipt.
  • Each Programmable-canonical execution scope preserves the inclusive 10 bps share of executed gross quote-side swap or fill volume exactly once. Claim authority and platform administration remain separate roles.
  • Fee V2 names four settlement profiles. The bundled Solidity kernel evidences only standard-amm; every other profile needs its own implementation, custody proof, tests, and review.
  • Public Applicant review requires exact public GitHub source. Local, private, ZIP-packaged, pasted, or non-GitHub source can support exploration but cannot enter the public review path.
  • Applicant requests and local Launch Bundles remain review-only and NOT_AUTHORIZED; neither grants production or launch authority.

Read the canonical details in Open-World V2 architecture, Security and review, and Programmable platform boundaries.

Repository map

skills/programmable-v4-hook-builder/   canonical portable Skill
  references/                         routed knowledge, schemas, and policy
  assets/                             starters, capability packs, reference kernels
  scripts/                            deterministic tools and package tests
evals/                                adversarial agent evaluations
docs/                                 usage, architecture, security, release records
submissions/                          frozen legacy Applicant contracts and continuations
config/plugin.json                    canonical host metadata
plugins/programmable-v4-builder/      generated, byte-verified Codex payload
mcp/ and .mcp.json                    canonical Codex-only MCP companion

The portable Skill and root MCP files are canonical. Generated manifests and the Codex payload remain byte-aligned with them. See Architecture before changing package or host metadata.

Verify from source

Node.js 24 or newer is required and CI verifies the Node 24 line. The repository has no npm runtime or development dependencies.

npm test
gh skill publish --dry-run

The two bundled reference fee kernels additionally use Foundry:

cd skills/programmable-v4-hook-builder/assets/reference-kernels/programmable-volume-fee-v1
forge test
cd ../programmable-volume-fee-v2
forge test

Model-backed evaluations are separate because they require provider credentials and may cost money. npm test still validates their structure; an unavailable model result or provider receipt is never treated as passed.

Documentation

Goal Documents
Use the Builder Agent Skill guide · Applicant submission beta
Understand the system Architecture · Open-World V2 · Knowledge routing
Extend it safely Templates and extensions · Security and review · Contribution guide
Inspect portability and releases Portability and lifecycle · Release gates · Release process

Submit a Launch is the canonical public Applicant pull-request surface. Project source stays in the Applicant's own public GitHub repository; review remains separate from platform contracts, routing, deployment, and the Explorer.

License and independence

Programmable v4 Builder is independent open-source software under the MIT License. Uniswap is a source protocol and ecosystem referenced by the Builder. This repository does not claim affiliation with or endorsement by Uniswap Labs or the Uniswap Foundation.