Run any Skill in Manus with one click

townhouse-live-e2e

Stars0

Forks1

UpdatedJune 3, 2026 at 21:52

Run the full operator+client live-infra exercise against a local townhouse hidden-service (HS). Use when the user wants to "run the townhouse live e2e", "stand up an HS and pay packets to town/dvm/mill", "do the operator and client agent demo", "exercise all three node types over the .anon", "upload an image to the dvm and verify the Arweave txId", or "/townhouse-live-e2e". Orchestrates two background agents — an OPERATOR that adopts-or-stands-up the apex + town/dvm/mill against local Docker chains and funds wallets, and a CLIENT that uses @toon-protocol/client over the apex .anon SOCKS5h address to pay a kind:1 publish to town, a kind:5094 hero-image blob upload to the dvm, and an EVM→Solana streamSwap to the mill — then files GitHub issues for findings and dispatches worktree-isolated fixer PRs. Bakes in the hard-won gotchas (RAM ceiling/adopt-don't-rebuild, sub-agents can't spawn sub-agents, dvm destination g.townhouse via localDelivery, MockUSDC 18-decimal, mill claim-issuance-layer caveat, prettier glob

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

toon-protocol

toon-protocol/town

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

More from this repository

same repository

townhouse-operator

toon-protocol/town

Operate a TOON Protocol Townhouse (the apex + town/mill/dvm nodes) from a Claude agent via the townhouse_* MCP tools. Covers lifecycle ("start/ boot my townhouse apex", "shut down my nodes", townhouse_init/up/up_status/ down/status, direct vs hidden-service transport), node provisioning ("add or remove a town/mill/dvm node", townhouse_add_node/remove_node/list_nodes), fee tuning ("set my relay fee", townhouse_set_node_fees, feePerEvent/ feeBasisPoints/feePerJob/kindPricing), settlement chains (townhouse_chains, townhouse_transport), earnings & money ("how much has my node earned?", "withdraw my earnings", "what are my balances?", townhouse_earnings/balances/ withdraw/credits/seed), and observability ("are my nodes healthy?", "show node logs/metrics", "what channels are open?", townhouse_health/logs/metrics/ channels/version). Use whenever the user wants to run, configure, monitor, or take earnings from a Townhouse operator node through the townhouse_* tools.

2026-06-150

toon-client

toon-protocol/town

Act as a TOON Protocol client from a Claude agent (Desktop or Code) via the toon-* MCP tools backed by the toon-clientd daemon. Covers pay-to-write publishing ("how do I publish to TOON?", "how do I post a note on TOON?", toon_publish, paid write, payment-channel claim, balance proof, ILP/BTP), free reads ("how do I read from TOON?", "how do I subscribe to a TOON relay?", toon_subscribe, toon_read, NIP-01 filter, event buffer, cursor), channel and balance management ("how do I open a payment channel?", "how do I check my channel nonce/balance?", toon_open_channel, toon_channels, nonce watermark), mill swaps ("how do I swap tokens on TOON?", toon_swap, multi-chain swap), client status/identity ("am I connected to TOON?", "what is my TOON address?", toon_status, toon_identity, bootstrapping), and threshold/off-chain settlement semantics ("how does paying per write work on TOON?", "why is reading free?"). Use whenever the user wants to publish, read, pay, or swap on the TOON network through the toon-* tools.

2026-06-130

akash-deploy

toon-protocol/town

Deploy and manage applications on Akash Network's decentralized cloud using the provider-services CLI. Use when the user asks about: (1) deploying on Akash ('deploy on Akash', 'deploy to decentralized cloud', 'Akash deployment'), (2) writing SDL manifests ('create SDL', 'Akash deployment file', 'deploy.yaml for Akash'), (3) Akash CLI operations ('install provider-services', 'Akash CLI', 'check deployment status', 'view Akash logs', 'close deployment'), (4) Akash cost/pricing ('how much does Akash cost', 'Akash pricing', 'choose Akash provider'), (5) Akash advanced features ('persistent storage on Akash', 'GPU deployment Akash', 'Akash AuthZ', 'IP leases'), (6) Akash troubleshooting ('no bids on Akash', 'deployment failed', 'escrow overdraw').

2026-04-090

skill-eval-framework

toon-protocol/town

Evaluate, validate, and benchmark TOON Claude Agent Skills using the skill-creator methodology extended with TOON compliance checks. Use when asked to evaluate a TOON skill ("evaluate this TOON skill", "run evals on this skill", "validate this skill"), check TOON compliance ("check TOON compliance", "is this skill TOON-compliant?", "run compliance checks"), benchmark skill performance ("benchmark this skill", "what's the pass rate?", "run skill benchmarks"), run batch validation across all skills ("validate all skills", "run batch validation", "aggregate compliance report"), grade skill output ("grade this skill's output", "produce grading results"), check if a skill is ready for publication ("is this skill ready?", "publication readiness check"), or run with/without testing to measure skill value-add ("compare with and without skill", "measure skill effectiveness").

2026-04-080

git-collaboration

toon-protocol/town

Decentralized git collaboration on Nostr and TOON Protocol using NIP-34. Covers repository announcements ("how do I announce a repo on Nostr?", kind:30617), patches ("how do I submit a patch?", kind:1617, git format-patch), pull requests ("how do I open a PR on TOON?", kind:1618), issues ("how do I open an issue?", kind:1621), comments ("how do I comment on a PR?", kind:1622), status events ("how do I merge a PR?", kind:1630-1633), and Arweave blob storage (kind:5094). Helps with git workflow decisions ("should I submit a patch or a PR?", "what is the cost of submitting a patch?"). Implements NIP-34 on TOON's ILP-gated network where patches cost per-byte.

2026-03-280

git-objects

toon-protocol/town

Git object binary format reference for TOON Protocol. Covers blob format ("how do I create a git blob?", "blob header format", blob size null-byte content), tree format ("how do I construct a git tree?", "tree entry format", mode name sha1, sorted entries), commit format ("how do I build a git commit object?", "commit header format", tree parent author committer message), SHA-1 computation ("how is a git SHA-1 computed?", "git object hash", "content-addressed storage", SHA-1 of header plus content), Nostr pubkey to git author mapping ("how do I map a Nostr pubkey to a git author?", "hex pubkey author format"), and git object construction for Arweave upload ("how do I prepare git objects for kind:5094?", "git objects on Arweave", "content-addressed git storage"). This is a REFERENCE skill -- git objects are uploaded to Arweave via kind:5094 DVM requests (see git-collaboration skill).

2026-03-280

name

townhouse-live-e2e

description

Townhouse live E2E (operator + client)

Reproduce the end-to-end TOON Protocol demonstration: an operator stands up (or adopts) a townhouse hidden-service (HS) apex with town + dvm + mill children against local Docker chain devnets, and a client uses the real @toon-protocol/client to pay packets to all three node types over the apex .anon address — kind:1 → town, kind:5094 hero-image upload → dvm, EVM→Solana streamSwap → mill. Both agents file GitHub issues for anything rough; you (the orchestrator) dispatch worktree-isolated fixer agents that open PRs.

Argument: adopt (default) reuses a healthy running HS stack; fresh drives a real townhouse init → hs up → node add bring-up.

Fast deterministic alternative (no agents): ./scripts/townhouse-3node-e2e.sh runs just the 3-node client exercise against an already-running stack and prints PASS/FAIL per node. Use this skill when you want the full agentic flow (bring-up verification + issue-filing + fixer PRs).

Hard constraints (read first)

RAM is tight (~8 GB free; Mina alone wants ~4 GB). Do NOT stand up a second full stack. If a healthy stack is already running (docker ps shows townhouse-hs-connector/town/dvm/mill + townhouse-dev-anvil/solana/mina), adopt it — verify via CLI/admin, don't rebuild.
Sub-agents CANNOT spawn their own sub-agents (the Agent tool isn't exposed to them). So the operator/client agents file issues but CANNOT self-dispatch fixers — you dispatch fixer agents after collecting their findings.
Per-package tests only with timeouts (pnpm --filter <pkg> test, timeout 120000). NEVER root pnpm test/pnpm build; NEVER pet-circuit. Set a timeout on every Bash call.
Public ATOR proxies are flaky → 60–120 s handshake timeouts, retry/rotate among the :9052 IPs.

Phase 0 — preflight (you, before spawning agents)

docker ps — is a townhouse HS + chains already up? Note the active config dir (~/.townhouse-local or ~/.townhouse), the .anon hostname (<configdir>/host.json), and the connector admin URL (usually http://127.0.0.1:9401).
curl -s http://127.0.0.1:9401/admin/peers — confirm town+mill connected. dvm shows connected:false by design (it receives via the connector localDelivery HTTP route to http://townhouse-hs-dvm:3300, not a BTP session).
Ensure the from-source townhouse CLI is built (packages/townhouse/dist/cli.js) and chains are healthy (curl :28545 anvil, :28899 solana; Mina's unhealthy is usually a strict-healthcheck false negative — daemon GraphQL serves on 3085).
mkdir -p /tmp/toon-e2e.

Phase 1 — spawn the OPERATOR agent (background)

Give it the verified facts from Phase 0 and have it:

Verify the deployment via the real CLI (status, node list, health) + /admin/peers.
Derive each node's nostr pubkey from its container NODE_NOSTR_SECRET_KEY (older images ship an empty NODE_NOSTR_PUBKEY; getPublicKey via nostr-tools). NOTE the mill has TWO keys: the NODE_NOSTR_SECRET_KEY node identity AND the MILL_MNEMONIC-derived swap gift-wrap recipient — streamSwap callers need the mnemonic-derived one (it's what mill_ready logs and what kind:10032 publishes).
Fund the client wallet (anvil acct[6] 0x976EA74…) with ETH + MockUSDC (scripts/faucet-evm.sh or direct cast). MockUSDC is 18-decimal on-chain (scale EVM claims by 1e18).
Write /tmp/toon-e2e/handoff.json: .anon hostname/btpUrl, node ilp addresses + pubkeys, mill swapPair + solana channelId, chain RPCs (anvil 28545 / solana 28899), MockUSDC + registry, client funding key, socks proxies, hero image path. The client agent BLOCKS on this file.
Collect findings (mis-wirings, healthcheck false-negatives, empty pubkey env, funding gaps).

If the argument is fresh: instead drive a real bring-up — townhouse init --network custom --evm-url http://townhouse-dev-anvil:8545 --sol-url http://townhouse-dev-solana:8899 → hs up -c <config.yaml> (note -c, not --config-dir) → docker network connect townhouse-hs-net townhouse-dev-anvil (+solana/mina so child DNS resolves) → node add town|dvm|mill.

Phase 2 — spawn the CLIENT agent (background, after handoff.json exists)

Have it reuse the existing harnesses rather than rewrite transport:

packages/client/scripts/all-three-nodes-hs-LOCAL.ts (the consolidated 3-node harness) — or the per-node templates social-flow-hs-LOCAL.ts (town) + mill-swap-hs-LOCAL.ts (mill).
Connect BtpRuntimeClient over socks5h://<ator>:9052 to ws://<.anon>:3000/btp, open a client→apex EVM channel, sign the balance proof, then:
- town: publishEvent(kind:1) → expect FULFILL.
- dvm: buildBlobStorageRequest kind:5094 of the hero image (_bmad-output/branding/social-assets/github-hero-readme.jpg, image/jpeg) to destination g.townhouse → expect FULFILL; decode base64 FULFILL → Arweave txId (view via https://arweave.net/<txId>; 404 right after upload = Turbo free-tier propagation delay).
- mill: streamSwap EVM USDC→Solana USDC → expect state:completed + signed claim. KNOWN: the current mill image returns ILP T00 live (the handler ACCEPTS in local repro); the Solana mint/channel aren't on-chain on the devnet, so the swap verifies at the claim-issuance layer only. Report mill, don't hard-fail on it.
Write /tmp/toon-e2e/client-results.json and collect client-side findings.

Phase 3 — issues + fixer PRs (you)

Each role agent files GitHub issues for its findings: gh issue create --repo <owner/repo> --title … --body "<repro + observed + affected files + proposed fix>" (client agent dedupes against the operator's via gh issue list).

Then you dispatch ONE fixer per issue (or grouped by package to avoid conflicting PRs) using the Agent tool with isolation:"worktree", in batches of ≤2 for RAM. Each fixer:

bases off origin/main (git checkout -b fix/issue-<n>-<slug> origin/main);
runs tests cheaply WITHOUT pnpm install — symlink deps then run vitest directly: ln -sfn <repo>/node_modules ./node_modules, ln -sfn <repo>/packages/<pkg>/node_modules ./packages/<pkg>/node_modules, <repo>/node_modules/.bin/vitest run <test> --root packages/<pkg> --no-coverage;
commits (Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>), pushes, opens a PR (Closes #<n>). Verify prettier with the repo's glob (pnpm format:check), not an explicit file path — a path-scoped prettier --check can falsely pass.

Report a consolidated table: each node's result (town/dvm FULFILL, dvm Arweave txId, mill state), issues filed, and PR links.

Cleanup

git worktree prune the fixer worktrees once branches are pushed. Leave the docker stack running unless asked to tear down (townhouse hs down + docker compose -p <proj> … down).