What makes Build notable?

1.1K downloads. Trust evidence available

How should Build be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

Build

Scaffold new Aomi apps and plugins from API docs, OpenAPI/Swagger specs, or SDK references. aomi-build generates production-ready Rust SDK crates (lib.rs, cl... Skill: Build Owner: ceciliaz030 Summary: Scaffold new Aomi apps and plugins from API docs, OpenAPI/Swagger specs, or SDK references. aomi-build generates production-ready Rust SDK crates (lib.rs, cl... Tags: ai-agents:0.1.0, development:0.1.0, latest:0.1.1, scaffolding:0.1.0 Version history: v0.1.1 | 2026-07-10T19:31:13.740Z | auto aomi-build v0.1.1 - Revamped documentation and manifest for clarity, precise permissio

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.1k

Updated

Oct 11, 2026

Version

0.1.1

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.1K downloadsadoption · observed Oct 11, 2026
Latest release: 0.1.1release · observed Jul 10, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s174406t7fv0e6ry94swqb3jc186877h:aomi-build

Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-ceciliaz030-aomi-build/snapshot"

Documentation

CLAWHUB

143,167 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: aomi-build
description: >
  Scaffold new Aomi apps and plugins from API docs, OpenAPI/Swagger specs, or SDK
  references. aomi-build generates production-ready Rust SDK crates (lib.rs,
  client.rs, tool.rs) with tool schemas, preambles, host-interop flows, and
  validation — turning a vendor's API surface into AI-agent-callable tools. It
  covers the current `aomi-build` OpenAPI pipeline (`gen-specs` → `gen-client`
  → `gen-tool` → curate → compile/test) as well as greenfield apps. Use when
  the user wants to scaffold a new Aomi app from a spec, wrap a REST API as
  agent-callable tools, port an existing SDK, or extend an Aomi runtime with new
  integrations. Trigger with prompts about wrapping APIs, scaffolding Rust crates
  from specs, or adding protocol integrations that aomi-transact can drive. Output
  crates support progenitor-generated OpenAPI clients, curated tool layers, sync
  HTTP, async tools (DynAsyncSink), typed secrets, route plans
  (ToolReturn/RouteStep), EVM and SVM host handoffs, and multi-step
  quote→approval→swap flows. Same runtime that aomi-transact drives.
tags: [crypto, web3, evm, rust, sdk-scaffolding, openapi, swagger, agent-tools, defi, builder-tools]
compatibility: 'Best when a local aomi-sdk checkout is available, often at ../aomi-sdk. Falls back to bundled references when the SDK repo is not present. Verified against aomi-sdk v3.0.1 (Rust 2024 edition) and the current aomi-build Rust CLI. Install the current CLI with cargo install --git https://github.com/aomi-labs/aomi-sdk --features cli aomi-sdk, or run from source with cargo run -p aomi-sdk --features cli --bin aomi-build -- <command>. Designed for claude-code; also works with Cursor, Codex CLI, Gemini, and any agent runtime that supports the Anthropic skill spec.'
license: MIT
version: "0.1.1"
author: 'aomi-labs <[email protected]>'
# Claude Code allowed-tools. The skill scaffolds Rust source files (Write/Edit),
# inspects existing apps and SDK examples (Read/Grep), and runs cargo + git
# (Bash). Operational scope is locked down by OWASP permissions.shell below
# to `cargo` and `git` only — defense in depth.
allowed-tools: 'Bash(cargo:*), Bash(git:*), Read, Write, Edit, Grep'
metadata:
  author: 'aomi-labs <[email protected]>'
  version: "0.1.1"
  # Provenance — author-declared upstream coordinates.
  # `gh skill install` will add/overwrite `ref`, `tree_sha`, `installed_via`,
  # and `installed_at` at install time. Do not pre-populate those fields.
  repository: aomi-labs/skills
  homepage: https://github.com/aomi-labs/skills/tree/main/aomi-build

# OWASP AST03 (Over-Privileged Skills) permission manifest.
# Spec: https://owasp.org/www-project-agentic-skills-top-10/ast03
# Universal Skill Format v1.0 (March 2026).
permissions:
  files:
    # The skill reads source files in the user's project (the aomi-sdk
    # checkout or wherever the user runs from) and the SDK's bundled
    # docs/examples for pattern reference.
    read:
      - ./
      - ../aomi-sdk/

_meta.json

{
  "ownerId": "kn7axfgphsdj10cpkqw6n840nh86837c",
  "slug": "aomi-build",
  "version": "0.1.1",
  "publishedAt": 1783711873740
}

references/aomi-sdk-patterns.md

# Aomi SDK Patterns

These patterns come from the SDK examples (`sdk/examples/app-template-http`), current SDK source, and inspected public apps in `aomi-sdk/apps`. Current SDK is **v3.0.1**, Rust **2024 edition**.

## Canonical Layout

Use this split unless there is a strong reason not to:

```text
apps/my-app/
├─ Cargo.toml
└─ src/
   ├─ lib.rs
   ├─ client.rs
   └─ tool.rs
```

- `lib.rs`: manifest, preamble, `dyn_aomi_app!`
- `client.rs`: app struct, HTTP client, auth, models, helpers
- `tool.rs`: `DynAomiTool` impls and user-facing tool surface

`Cargo.toml` must declare `edition = "2024"`, `crate-type = ["cdylib"]`, and depend on `aomi-sdk = { workspace = true }`. The host enforces an exact-match SDK version gate: after bumping `sdk/Cargo.toml`, all apps must be rebuilt — see `docs/sdk-version-compatibility.md`.

## Minimal Manifest Shape

```rust
use aomi_sdk::*;

mod client;
mod tool;

const PREAMBLE: &str = r#"## Role
You are ...
"#;

dyn_aomi_app!(
    app = client::MyApp,
    name = "my-app",
    version = "0.1.0",
    preamble = PREAMBLE,
    tools = [
        client::SearchThing,
        client::GetThing,
    ],
    namespaces = ["evm-core"]
);
```

Keep `lib.rs` small. The manifest should be easy to audit at a glance.

The `namespaces` field is required. Current canonical host namespaces are explicit strings:

- `namespaces = ["evm-core"]` for most EVM apps and generated OpenAPI apps. This injects the current EVM host tools such as `encode_and_call`, `stage_tx`, `simulate_batch`, `commit_txs`, and `evm_commit_message`.
- `namespaces = ["svm-reads", "svm-ix-broadcast", "svm-tx-broadcast"]` for Solana apps that need SVM read/stage/commit host tools.
- `namespaces = []` only for apps that should receive no host namespace at all.

Do not copy the old `"common"` namespace into new apps. Current SDK docs note that legacy namespace was removed in host iter-39; the loader skips unknown namespaces.

The macro generates the C ABI exports (`aomi_create`, `aomi_manifest`, `aomi_async_tool_start`, `aomi_dyn_exec_poll`, etc.) and embeds the SDK version stamp the host uses for compatibility checks.

## What The Real Apps Show

### `sdk/examples/app-template-http`

Use as the default baseline for read-only HTTP APIs.

- Simple `reqwest::blocking` client
- Clean typed args
- Small tool surface
- Straightforward JSON normalization

### `apps/x`

Use this pattern when the upstream API:

- needs an env-backed API key
- has a wrapper response envelope
- benefits from normalized data models and formatting helpers

Notable conventions:

- auth env vars live in `client.rs`
- logical API failures are normalized before reaching tools
- tools return concise, model-friendly JSON

### `apps/polymarket`

Use this pattern when the app needs:

- multiple upstream API surfaces
- dynamic preamble context such as exact current date
- intent resolution before execution
- multi-step flows with explicit user confirmation

Notable conventions:

- preamble explains exact

references/examples.md

# Build Examples

Read this when:

- You need to translate a concrete spec or doc set into a working app.
- You want to see the SKILL.md guidance applied end-to-end.
- You're deciding what kind of app to build and want to pattern-match against a real one in `apps/`.

Each example is anchored to a real app crate in `aomi-sdk/apps`. Code excerpts come directly from those crates; the **"What you'd type"** blocks show how you'd brief the skill to reproduce them.

The build lifecycle is consistent across every example:

> **identify surface** → **propose toolset** → **scaffold** → **wire client + tools** → **build + test** → **handoff hooks**

If you only remember one thing: **don't mirror endpoints; map user intents.** A spec with 20 endpoints is rarely 20 tools. It's usually 4-8.

---

## 1. CEX read + signed orders — `apps/binance` shape

**Anchored to** `apps/binance/src/{lib.rs, client.rs, tool.rs, types.rs}`. The canonical "exchange API" shape: HMAC auth, public reads, signed writes, normalized response models.

### Source material

A REST API doc (Binance Spot v3) with ~30 endpoints across:

- public: tickers, depth, klines, 24h stats
- signed (HMAC-SHA256): place order, cancel order, account balances, trade history

### What you'd type

> "Build an Aomi app for Binance Spot. Cover the main public reads (price, depth, klines, 24h stats) plus signed order placement and account queries. Auth is HMAC-SHA256 with `BINANCE_API_KEY` + `BINANCE_SECRET_KEY`. Trading pairs use uppercase no-separator format (BTCUSDT)."

### Tool decisions

Resist 1:1 mapping. The spec has 30+ endpoints; the user intent reduces to 8 tools:

| Tool name | Intent | Endpoint(s) |
|-----------|--------|-------------|
| `binance_get_price` | "what's the price of X?" | `GET /ticker/price` |
| `binance_get_depth` | "what's the order book for X?" | `GET /depth` |
| `binance_get_klines` | "give me OHLC for technical analysis" | `GET /klines` |
| `binance_get_24hr_stats` | "rolling 24h stats" | `GET /ticker/24hr` |
| `binance_place_order` | "submit a buy/sell order" | `POST /order` (signed) |
| `binance_cancel_order` | "cancel my order" | `DELETE /order` (signed) |
| `binance_get_account` | "what's my balance?" | `GET /account` (signed) |
| `binance_get_trades` | "my fill history" | `GET /myTrades` (signed) |

Skip: server time, exchange info, system status, sub-account endpoints, futures (a separate app), savings, staking, mining. They'd bloat the model's tool surface without serving a clear primary user intent.

### Manifest (`lib.rs`)

```rust
use aomi_sdk::*;

mod client;
mod tool;
mod types;

const PREAMBLE: &str = r#"## Role
You are an AI assistant specialized in interacting with the Binance cryptocurrency exchange...

## Authentication
- Public market data endpoints do not require authentication
- Signed endpoints (orders, account, trades) require both api_key and secret_key
- The signature is computed as HMAC-SHA256(secret_key, query_string_with_timestamp)
- The timestamp p

references/host-routes.md

# Host Routes

Read this when:

- The app you're building must hand off to the host wallet (sign, submit, broadcast) at some point.
- The app needs to chain multiple tool calls where a later step depends on an artifact produced by an earlier wallet callback (`signature`, `transaction_hash`).
- You see `ToolReturn` or `RouteStep` in an existing app and want to know what the runtime does with them.

## What this replaces

Older Aomi apps returned a `SYSTEM_NEXT_ACTION` field embedded inside a JSON payload, and the runtime parsed prose hints to figure out what to call next. **That convention is gone.** The current contract is structured: tools return `ToolReturn::with_routes(value, [...])` envelopes, the runtime resolves the routes mechanically, and prose is never parsed.

If you see `SYSTEM_NEXT_ACTION` in older code or docs, treat it as outdated. Replace it with a `RouteStep` that names the next tool by its `host::*` marker.

## The envelope

A tool returns either a bare `Value` (read-only) or a `ToolReturn` (with routes):

```rust
pub struct ToolReturn {
    pub value: Value,                 // the tool's structured payload
    pub routes: Vec<RouteStep>,       // ordered continuations
}
```

Tools opt into routes by overriding `run_with_routes()` instead of (or in addition to) `run()`. The default `run_with_routes()` impl wraps `run()` into `ToolReturn::value(...)` with empty routes — so non-routing tools need no changes.

```rust
impl DynAomiTool for BuildMyOrder {
    type App = MyApp;
    type Args = BuildMyOrderArgs;
    const NAME: &'static str = "build_my_order";
    const DESCRIPTION: &'static str = "Build an order and return the next signing step.";

    fn run_with_routes(
        _app: &Self::App,
        args: Self::Args,
        ctx: DynToolCallCtx,
    ) -> Result<ToolReturn, String> {
        // ... build typed_data, prepare submit_template ...
        Ok(ToolReturn::with_routes(
            json!({ "preview": preview, "wallet_request": typed_data.clone() }),
            [
                RouteStep::on_return("evm_commit_message", typed_data)
                    .bind_as("clob_l1_signature")
                    .prompt("Sign the typed data to authorize the order."),
                RouteStep::on_bound_event(
                    "submit_my_order",
                    submit_template,
                    "clob_l1_signature",
                )
                .prompt("Wallet signed — submit the order now."),
            ],
        ))
    }
}
```

## RouteStep anatomy

```rust
pub struct RouteStep {
    pub tool: String,          // the next tool to call (host or app-local)
    pub args: Value,           // hinted args; aliases get spliced in
    pub trigger: RouteTrigger, // OnSyncReturn or OnBoundEvent { alias }
    pub bind_as: Option<String>, // publish this step's result under an alias
    pub prompt: Option<String>,  // override prompt text for this step
}
```

### Triggers

- **`RouteTrigger::OnSyncReturn`** (built via `RouteSte

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.