تشغيل أي مهارة في Manus بنقرة واحدة

townhouse-operator

النجوم٠

التفرعات١

آخر تحديث١٥ يونيو ٢٠٢٦ في ١٩:٢٧

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.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

toon-protocol

toon-protocol/town

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مديرو الشبكات وأنظمة الحاسوبمهن الحاسوب والرياضيات·SOC 15-1244

مستكشف الملفات

3 ملفات

SKILL.md

readonly

المزيد من هذا المستودع

نفس المستودع

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

townhouse-live-e2e

toon-protocol/town

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

2026-06-030

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-operator

description

Townhouse Operator (agent surface)

This skill lets a Claude agent act as a Townhouse operator — running the revenue-earning side of TOON Protocol — through the townhouse_* MCP tools. A Townhouse is an apex (the connector, nodeId g.townhouse) plus its child nodes: a town (pay-per-event Nostr relay), a mill (multi-chain swap peer), and a dvm (NIP-90 compute, e.g. Arweave blob storage). Clients pay the apex over BTP; the apex validates their payment-channel claim, takes its fee, and forwards to the child for free (settled in aggregate). The operator earns the fees.

Composes with the operator runbook in packages/townhouse/RUNBOOK.md (recovery playbooks) and docs/architecture.md (apex/child topology). For the client side (publishing/reading/paying), see the separate toon-client skill.

Mental model: the apex IS the long-lived layer

Unlike the client (which has a toon-clientd daemon), the operator has no second daemon. The apex — the connector + a Fastify control API on 127.0.0.1:9400, started by townhouse up — IS the always-on layer. Each townhouse_* tool maps to either:

the apex API (live telemetry + money/topology: balances, earnings, add/remove node, withdraw, transport), or
the townhouse CLI (lifecycle/config that must work before the apex is up: init, up, down, status, chains, credits, seed, logs, metrics, channels, health).

The MCP server holds no chain keys — the operator seed lives at the townhouse layer (TOWNHOUSE_MNEMONIC), and the apex owns the wallet.

First calls: status, then up

townhouse_status — apex / connector / node / transport snapshot. Prefers the live API; falls back to the CLI when the apex is down.
If the apex isn't running and TOWNHOUSE_AUTOUP=1 (default), telemetry/money tools transparently kick off up and return a "booting — retry" result — poll townhouse_up_status and retry. Operators who want explicit control set TOWNHOUSE_AUTOUP=0 (then a down apex yields apex_not_running).

townhouse_health probes apex / api / nodes / .anyone and returns the full breakdown even when a probe is unhealthy (the underlying CLI exits non-zero but still reports).

Lifecycle

townhouse_init({ preset?, network? }) — create config. If TOWNHOUSE_MNEMONIC is set, it loads that seed; otherwise it generates and returns a fresh operator mnemonic for the agent to custody (cold start — back it up, it is shown once). With TOWNHOUSE_MNEMONIC set and no password, init scaffolds config only (no encrypted wallet; walletMode:'mnemonic').
townhouse_up({ transport? }) — boot the apex. Returns a handle immediately; the boot itself takes minutes (image pulls, HS bootstrap, the ~20s town inbound-session warm-up). Poll townhouse_up_status for per-step NDJSON progress until a terminal done/error. transport is direct (default — clients dial ws://host:3000/btp) or hs (anonymous .anon hidden service). Do not hold a tool call open waiting for boot.
townhouse_down({ hs? }) — stop the stack (hs:true for a hidden-service apex).

Direct and HS stacks are port-mutually-exclusive; switching transports tears one down before bringing the other up.

Nodes

townhouse_list_nodes() — provisioned nodes (id, type, ilpAddress, status).
townhouse_add_node({ type, relays?, turboToken? }) — provision a town | mill | dvm child (an atomic multi-step pipeline: derive keys → register child peer → tag the apex as parent → start). A child must be registered relation:'child' and tag the apex (g.townhouse) as its parent, or paid traffic is rejected (T00/F06) — the pipeline handles this; if a publish to the child is rejected, suspect this. mill requires relays (Nostr relay URLs) — pass them here (or set nodes.mill.relays/MILL_RELAYS); without any, add returns a preflight 400. dvm optionally takes turboToken (Arweave Turbo JWK) for larger uploads. Passing these in the call avoids the trap where env vars exported after the apex booted are never seen.
townhouse_remove_node({ id }) — deprovision by id.
townhouse_set_node_fees({ type, feePerEvent?, feeBasisPoints?, feePerJob?, kindPricing?, enabled? }) — tune fees (town feePerEvent, mill feeBasisPoints, dvm feePerJob + kindPricing) or toggle enabled. A fee change restarts the connector, which transiently drops routes (see RUNBOOK) — expect a brief blip.

Child fee = 0 for a free-forward apex. The apex forwards parent→child packets without a per-packet claim, so the child's own fee should be 0; the apex's fee is what the operator earns. A non-zero town fee on a child apex double-charges and rejects.

Settlement chains & transport

townhouse_chains({ op, args? }) — list (API), or add/remove (CLI, with passthrough flags in args, e.g. --chain-type evm --chain-id 8453 ...).
townhouse_transport({ set? }) — get transport status, or flip it (set: 'direct' | 'hs').

Earnings & money

townhouse_earnings() — apex + per-peer earnings with today/month/year deltas.
townhouse_balances() — EVM / Solana / Arweave balances per node.
townhouse_withdraw({ nodeType, chainFamily, token, recipient, amount, dryRun? }) — withdraw earnings to a recipient (EVM in v1). Always run dryRun:true first for a gas/fee estimate, confirm the recipient + amount with the user, then withdraw for real. This moves real on-chain funds and is irreversible.
townhouse_credits({ op, token?, amount?, quoteOnly? }) — buy (op:'buy', on-chain; quoteOnly:true for a quote) or check (op:'balance') Arweave upload credits used by the dvm.
townhouse_seed() — reveal the operator mnemonic for backup. This is the master key to every node's funds — only surface it when the user explicitly asks to back up, and treat the output as a secret (never log it elsewhere).

Observability

townhouse_logs({ service?, level?, maxLines? }) — bounded log tail. Prefers the live SSE stream, falls back to recent CLI history; the result's source field says which.
townhouse_metrics() — connector metrics snapshot (live WS, CLI fallback; carries source).
townhouse_channels() — open payment channels (nonce watermark + transferred).
townhouse_version() — this MCP package version, the pinned townhouse range, and the detected CLI version; satisfies:false/null flags version skew (a too-old CLI) before a tool misbehaves — check this if tools act oddly.

Resources mirror the two cheap reads for clients that prefer resource fetches: townhouse://status and townhouse://earnings.

Failure & retry guidance

booting / apex unreachable → not an error under TOWNHOUSE_AUTOUP=1; poll townhouse_up_status (and ~/.townhouse/up.log) and retry. A boot can take minutes.
node_lifecycle_in_flight (409) → another node op is running; wait and retry — do not fire a second add/remove concurrently.
CLI non-zero exit → surface the stderr + failing command verbatim; don't silently retry a config mutation.
API typed errors (insufficient_balance, invalid_recipient, unknown_node_type, …) → pass through with their status; fix the input rather than retrying.
a publish to a child is rejected (T00/F06) → parent/child mis-tagging or a non-zero child fee — re-check townhouse_list_nodes relation/parent and the child fee.
Never fabricate an address, balance, earnings figure, nonce, or txHash — read them from tool results.

Social Context

Operating a Townhouse means running revenue infrastructure that clients pay real (testnet or mainnet) value to use, and custodying the keys that hold those earnings. That raises the stakes above a read-only dashboard:

The seed and withdrawals are real money. townhouse_seed reveals the master key; townhouse_withdraw moves funds on-chain irreversibly. Confirm recipient + amount, dry-run withdrawals first, and treat the seed as a secret — surface it only on an explicit backup request.
Config changes affect a live, paying network. A fee change or transport flip restarts the connector and briefly drops routes (RUNBOOK); a chain add/remove changes what clients can settle. Tell the user what a mutation will disrupt before you make it, and don't tune fees in a loop.
Boots and lifecycle ops take time — poll, don't block. up/hs up run for minutes; return the handle and poll townhouse_up_status rather than holding a call open. Run one node lifecycle op at a time.
Report the operator's financial state faithfully. Earnings, balances, and channel watermarks are the user's books — read them from the tools, never invent them, and flag anything that looks like unexpected spend or a stuck settlement (see the RUNBOOK's IN_PROGRESS wedge).