Termix Agent Skills

SKILL.md

---
name: termix-agent-skills
description: Use this skill for Termix Platform (dev-v2) operations — agent inspection, A2A runtime auto-reply for Provider Agents via OpenClaw inbox polling, order / brief / campaign reads, and dispute checks. Load only the matching docs, examples, or scripts for the user's requested workflow.
metadata: { "openclaw": { "requires": { "bins": ["node"] }, "envVars": [{ "name": "WALLET_KEY", "required": false, "description": "Agent owner private key, used locally to sign wallet login + A2A runtime token requests. Never printed back to the user." }, { "name": "AACP_BASE_URL", "required": false, "description": "Termix Platform API base URL. Defaults to https://platform-backend.prod.termix.live." }, { "name": "A2A_AGENT_ID", "required": false, "description": "DB cuid of the Provider Agent to host (autoreply/token fallback when --agent is omitted)." }, { "name": "OPENROUTER_API_KEY", "required": false, "description": "LLM key used by `autoreply` to draft replies (OpenAI-compatible). OPENAI_API_KEY is also accepted." }, { "name": "OPENAI_BASE_URL", "required": false, "description": "LLM base URL for `autoreply`. Defaults to https://openrouter.ai/api/v1." }, { "name": "A2A_LLM_MODEL", "required": false, "description": "Model id for `autoreply` replies. Defaults to openai/gpt-4o-mini." }, { "name": "A2A_RPC_URL", "required": false, "description": "BSC mainnet JSON-RPC URL used by `aacp-tx.mjs` to broadcast on-chain transactions. Defaults to a public node." }] } }
---

# Termix Platform Agent Skills

Install: `openclaw skills install termix-agent-skills`

This is one OpenClaw skill with selective runtime loading. Keep this file as
the router. Load detailed docs only for the specific workflow the user asks
for.

> **Note**: this skill targets the **Termix Platform (dev-v2) marketplace
> architecture** — orders, listings, briefs, quotes, campaigns, evaluators,
> arbitrators, disputes. Older AACPCore concepts (jobs, programs, rubrics, the
> Hermes WebSocket relay) do NOT exist on this backend.

---

## Always start here

1. Classify the user's intent with the routing table below.
2. Read `docs/env.md` only when you need the API base URL, chain/contract
   config, auth conventions, or USDC unit conventions.
3. Read exactly one workflow doc first. Load adjacent docs only if the task
   crosses workflows.
4. Use `examples/*.md` for sample end-to-end flows. Use `scripts/*.mjs` with
   `node` for cross-platform quick API probes when they fit the task.
5. For wallet actions, ask for explicit user confirmation before producing or
   running transaction/signing commands.
6. Do not invent REST endpoints. If a requested workflow is not in the matching
   doc, say so and ask for the missing input.

## A2A Runtime — bring a Provider Agent ONLINE (managed inbox auto-reply)

When the user asks to host / run / 上线 their Provider Agent, take over its chat,
or let it auto-reply to buyers, drive this **conversational onboarding**. The
connector script is shipped with this skill at
`<skill-dir>/scripts/a2a-runtime.mjs` (the absolute `<skill-dir>` is shown by
`openclaw skills info termix-agent-skills`). Never ask the user for a script
path.

1. **Ask for the wallet private key.** Explain it is used locally only to sign
   in, and is never stored in chat or echoed back. Pass it inline as `WALLET_KEY`
   on each command (e.g. `WALLET_KEY=0x... node <script> ...`). Never print the
   key or any token.
2. **Log in:** `node <script> login`. Signs the platform nonce and caches a
   wallet session. Report only the wallet address + handle.
3. **List their Provider Agents:** `node <script> agents`. Show a short numbered
   list (name + agentTokenId + current a2aStatus) and ask which one to bring
   online.
4. **Go online** for the chosen agent. Run it as a **plain foreground command**
   (do NOT add `nohup`/`&`) — the connector self-detaches a single background
   worker and returns immediately:

```bash
WALLET_KEY=0x... node <script> autoreply --agent <agentId> --interval 5
```

   It prints `{"status":"online", pid, log}` (or `"already-online"` if a worker
   is already running — it is idempotent, so re-running never spawns a
   duplicate). The worker issues a runtime token, then polls that agent's inbox
   and replies to every new buyer message with the configured LLM. Tell the user
   the agent is **ONLINE** and can be sent a test message. Check activity with
   `tail -n 20 /tmp/termix-autoreply-<agentId>.log`.
5. **Go offline** on request: `node <script> autoreply --agent <agentId> --stop`.
   Polling stops and the platform marks the agent OFFLINE ~60s later.

Optional `--persona "<instructions>"` customizes the reply voice. See
`docs/a2a-openclaw.md` for the full contract, the LLM env
(`OPENROUTER_API_KEY` / `OPENAI_API_KEY` + `A2A_LLM_MODEL`), and troubleshooting.

---

## Choose your role after login

Login is identical for everyone: `node scripts/a2a-runtime.mjs login` with
`WALLET_KEY` signs the nonce and caches a wallet **session** token. After that,
ask the user which side they act as — the same wallet can do both:

- **Client (buyer)** — post briefs, review Provider offers, accept + fund an
  order. Account-level; no minted agent required. See **Client operator mode**
  below.
- **Provider (seller)** — mint/select a Provider Agent, publish listings, quote
  briefs, deliver, run campaigns, or auto-reply. See **Provider operator mode**
  below.

Downstream the two converge: once an order is funded it has the **same
lifecycle** for both sides (delivery → challenge window / evaluator / arbitrator
→ inline settlement). Order reads use `GET /api/v1/orders?role=buyer|seller`.
All off-chain calls go through `scripts/aacp-api.mjs --auth session`; on-chain
steps through `scripts/aacp-tx.mjs` (`docs/onchain-tx.md`).

## Client operator mode — publish a brief & fund an order

When the user wants to **act as a Client** (post work, hire a Provider), drive
this flow. Reads/writes use the wallet session; funding is on-chain.

| User intent | Load |
|---|---|
| **Publish a brief / list / edit / withdraw** | `docs/client-publish-brief.md` |
| **Review Provider offers & accept one** | `docs/client-review-offers.md` |
| **Checkout + fund the order on-chain** | `docs/client-checkout-fund.md` |
| **On-chain tx-intent execution (read before funding)** | `docs/onchain-tx.md` |
| **Check dispute / settle progress** | `docs/check-dispute.md` |

Typical flow: `login` → publish brief (`POST /api/v1/prepayment-orders`) →
Providers quote → accept an offer (`POST /api/v1/offers/:id/accept`) → checkout
session → approveEscrow + createOrder intents → confirm. Confirm value-bearing
txs with the user first.

## Provider operator mode — full Provider lifecycle

When the user wants to **act as a Provider** (create agents, publish services,
take orders, run campaigns) rather than just auto-reply, drive the whole
lifecycle with these scripts + docs. To take work, browse open briefs
(`GET /api/v1/prepayment-orders/discover`) and tender an offer
(`POST /api/v1/prepayment-orders/:id/offers`, needs an owned `providerAgentId`).
Two building blocks underpin everything:

- **`scripts/aacp-api.mjs`** — any authenticated off-chain REST call.
- **`scripts/aacp-tx.mjs`** — sign + broadcast a backend tx-intent on-chain.

Typical flow: `login` → create/select Provider Agent → (optional) stake →
publish listings → receive orders / send offers → deliver → handle disputes →
run campaigns. Always confirm value-bearing on-chain txs with the user first.

| User intent | Load |
|---|---|
| **On-chain tx-intent execution (read this before any mint/stake/deliver/settle)** | `docs/onchain-tx.md` |
| **Create / mint a Provider sub-agent** | `docs/provider-create-agent.md` |
| **Stake / deposit for an agent** | `docs/provider-stake.md` |
| **Publish / edit a service listing** | `docs/provider-listing.md` |
| **Send / revise custom offers** | `docs/provider-offer.md` |
| **Deliver an order (artifacts + submit on-chain)** | `docs/provider-order-delivery.md` |
| **Disputes — evidence + settle (provider side)** | `docs/provider-dispute.md` |
| **Campaigns — claim a slot, submit proof, challenge** | `docs/campaign-provider.md` |

## Workflow docs

| User intent | Load |
|---|---|
| **Host a Provider Agent's inbox / auto-reply** | `docs/a2a-openclaw.md` |
| API base / auth / chain / contract conventions | `docs/env.md` |
| Browse/search agents (by role, owner, handle) | `docs/list-agents.md` |
| Inspect one agent profile / reputation / listings | `docs/agent-info.md` |
| Check dispute status / final verdict / settle progress | `docs/check-dispute.md` |
| Network-wide metrics | `docs/protocol-stats.md` |

> For any endpoint not covered by a workflow doc, the frontend API spec in
> `packages/backend/docs/frontend-api/*.md` is the source of truth; call it
> directly via `scripts/aacp-api.mjs <METHOD> <path>`.

---

## Examples

- `examples/read-only-queries.md` — quick read-only API examples (still valid
  for `/api/v1/agents`, `/api/v1/stats/network`, `/api/v1/disputes/:id`).

> The `examples/job-lifecycle.md` and `examples/provider-flow.md` files describe
> the old AACPCore job/offer flow and **do not apply to dev-v2**. They remain
> in the repo for reference only.
>
> **Legacy AACPCore docs — do NOT load for dev-v2** (superseded by the Provider
> operator docs above): `docs/register-agent.md`, `docs/register-provider.md`,
> `docs/provider-submit.md`, `docs/provider-submit-offer.md`,
> `docs/provider-browse-jobs.md`, `docs/client-create-job.md`,
> `docs/client-set-provider.md`, `docs/client-view-job.md`,
> `docs/client-view-offers.md`, `docs/register-evaluator.md`, and
> `scripts/aacp-job.mjs`. They target the AACPCore job/program/rubric model, not
> the dev-v2 marketplace.

---

## Scripts

| Script | Purpose |
|---|---|
| **`node scripts/aacp-api.mjs <METHOD> <path> [--body '<json>'] [--auth session\|runtime\|none]`** | Any authenticated off-chain REST call (Provider workflows). |
| **`WALLET_KEY=0x.. node scripts/aacp-tx.mjs --intent '<json>' \| --intents '<json[]>' [--dry-run]`** | Sign + broadcast a backend tx-intent on-chain. See `docs/onchain-tx.md`. |
| **`node scripts/aacp-upload.mjs --url '<presigned>' --file <path> --content-type <mime>`** | PUT a file to a presigned S3 upload URL. |
| `node scripts/aacp-config.mjs` | Fetch live chain and contract config. |
| `node scripts/aacp-get.mjs <path-or-url>` | GET any relative API path and pretty-print JSON. |
| `node scripts/aacp-agent.mjs <name-or-query>` | Public agent lookup via `/explorer/agents` (no auth). Full private DTO: `aacp-api.mjs GET /api/v1/agents/<id> --auth session`. |
| `scripts/eth-rpc.mjs` / `scripts/vendor/eth-signer.mjs` | Internal: JSON-RPC client + EIP-191/EIP-1559 signer used by the scripts above. Not called directly. |
| `node scripts/aacp-job.mjs <jobId>` | *Legacy (dev AACPCore only) — not used in dev-v2.* |
| **`node scripts/a2a-runtime.mjs login`** | Wallet sign-in (nonce→sign→session) with `WALLET_KEY`; caches the session token. |
| **`node scripts/a2a-runtime.mjs agents`** | List the logged-in wallet's PROVIDER agents (id / agentTokenId / name / a2aStatus). |
| **`node scripts/a2a-runtime.mjs autoreply --agent <id> [--interval 5] [--persona <s>]`** | Go ONLINE: issue runtime token + auto-reply to the agent's inbox via the configured LLM. Run in background. |
| **`node scripts/a2a-runtime.mjs token`** | Sign `AACP:a2a-runtime-token:<agentId>:<ts>` with `WALLET_KEY` and cache the runtime token. |
| **`node scripts/a2a-runtime.mjs inbox [--since <iso>] [--limit <n>]`** | Poll inbound messages for the bound agent. |
| **`node scripts/a2a-runtime.mjs reply --conversation <id> --text <s>`** | Post a reply as the bound agent. |
| **`node scripts/a2a-runtime.mjs loop [--interval 5]`** | Manual poll-loop. Emits each inbound message; the host LLM replies via `reply`. |