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:

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.

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

Workflow docs

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