agentleFS
hyperlane-xyzhyperlane-xyz/hyperlane-monorepo/.agents/skills/start-http-registry/SKILL.md

start-http-registry

Skill76 starsChanged 20 days agoApache-2.0View on GitHub

Start the http-registry server in the background. Instructions: --writeMode (optional): append --writeMode when the calling skill will write artifacts back through the server — warp deploy, warp apply, and warp alt create persist the resulting config/addresses via the write routes. Omit it for read-only flows (warp read, warp check). Serving private/pinned RPCs (the reason to use the HTTP registry at all) is independent of --writeMode; the flag only enables the write routes. Why CI=false: the infra HTTP registry wraps getRegistryForEnvironment…

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Start the http-registry server in the background.

    line 11
  2. Very specific:

    Run the command with run_in_background: true, prefixing with cd to the monorepo root AND CI=false inline (see next paragraph for why):

    line 19
  3. Very specific:

    Wait for the log line Server running in the background task's output before any downstream consumer hits the server.

    line 29

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Start HTTP Registry Server

Start the http-registry server in the background.

Instructions:

  1. First, find the monorepo root (working directory may have drifted):
    git rev-parse --show-toplevel
  2. Run the command with run_in_background: true, prefixing with cd to the monorepo root AND CI=false inline (see next paragraph for why):

    cd <MONOREPO_ROOT> && CI=false pnpm -C typescript/infra start:http-registry

    --writeMode (optional): append --writeMode when the calling skill will write artifacts back through the server — warp deploy, warp apply, and warp alt create persist the resulting config/addresses via the write routes. Omit it for read-only flows (warp read, warp check). Serving private/pinned RPCs (the reason to use the HTTP registry at all) is independent of --writeMode; the flag only enables the write routes.

    Why CI=false: the infra HTTP registry wraps getRegistryForEnvironment (typescript/infra/config/registry.ts:192), which merges filesystem chain metadata with per-chain RPC overrides. The override source is CI-gated: CI !== 'true' → GCP Secret Manager (private / keyed URLs like Alchemy, Dwellir, Ankr, TronGrid); CI === 'true' → MAINNET3_<CHAIN>_RPC_URLS env vars (the GitHub-Actions injection path). On Haggis workers and any environment where those env vars aren't set, CI=true silently falls back to the public on-disk registry URLs — which are rate-limited (e.g. Tron's public trongrid.io = 3 rps unauthenticated → 429 during broadcasts). Prefix inline so the setting is scoped to this single invocation; do NOT export CI=false globally — other flows in the same session may legitimately need CI=true.

  3. Wait for the log line Server running in the background task's output before any downstream consumer hits the server. This is the canonical readiness signal.
  4. Verify the server is reachable using the /readiness endpoint, NOT the root path — the root returns 404 by design and is not a liveness signal:

    curl -sf http://localhost:<port>/readiness && echo "ok"

    The server only routes specific paths: /readiness, /metadata, /addresses, /chains, /chain/<name>, /warp-route/deploy/<id>, /warp-route/deploy?<filter>, etc. Hitting http://localhost:<port>/ returns 404 even when the server is healthy. Do NOT interpret a root-404 as "server is dead" and fall back to passing the local FS registry path to downstream --registry flags — falling back bypasses the centralized RPC config the HTTP registry provides and can cost real mainnet gas on retries against flaky public RPCs.

  5. Report the task/shell ID + the port (typically 3333, read from the logs) to the user.
  6. Remind the user they can stop it later with KillShell using that ID, or via /stop-http-registry.

Example output:

Started http-registry server in background (shell ID: shell_abc123) on http://localhost:3333. Readiness verified. To stop it later, I can use KillShell or you can run /stop-http-registry.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.