skee. documentation

01Overview

skee. is an agent runtime. It runs small programs called errands on behalf of a wallet, on a schedule, inside hard limits called a leash. Each running instance is a skee.

The runtime holds the skee's keys, wakes it on schedule, executes the errand against a snapshot of on-chain state, simulates the resulting transaction, checks the leash, and signs or refuses. Every run ends in a plain-English receipt anchored on Robinhood Chain.

What skee. is not: a chat interface, a general-purpose agent, or a strategy engine. A skee does one errand and cannot be talked into another.

02Vocabulary

03Quickstart

npm i -g @skee/cli
skee login                       # connect owner wallet
skee spawn dca \
  --asset TSLAx --amount 25 \
  --cap 25 --day-cap 100 \
  --assets TSLAx,USDC \
  --nap 6h
# → skee 0x41…c2 spawned · first run in 6h · fund gas wallet: 0x9b…e1

Fund the gas wallet with a little ETH-equivalent on Robinhood Chain and the skee will run on schedule. skee receipts 0x41…c2 shows what it did.

04Install the CLI

npm i -g @skee/cli      # or: pnpm add -g @skee/cli
skee --version

The CLI talks to the skee. runtime API (§25) and to Robinhood Chain through the RPC in ~/.skee/config. Set SKEE_NETWORK=testnet to use the test deployment.

05Spawn your first skee

1. Pick an errand: skee errands lists the library with parameters.
2. Write a skee.yaml (§21) or pass flags.
3. skee spawn -f skee.yaml. The owner wallet signs once to create the skee contract (§17).
4. Fund the gas wallet printed at spawn.
5. Optionally skee run-now <id> to trigger a first run immediately.

06Jobs

A job is an errand with parameters filled in. Parameters are validated against the errand's schema at spawn time; a job that does not validate is not spawned. Jobs are immutable; to change one, edit the skee (§12), which creates a new job version and a receipt saying so.

07Errands

Errands live in a public library, each pinned by content hash and version. A skee references an exact hash; library updates never change a running skee.

Every errand must be: deterministic given its inputs, produce at most one transaction per run, be idempotent by run id, and emit a receipt sentence for every outcome. See §23 for the DSL and §29 for submitting one.

08The leash

The leash is checked by the runtime on the simulated transaction, not on what the errand claims. Rules:

• cap_per_run and cap_per_day — USD value moved, measured at execution price.
• assets — every asset touched, including intermediate swap legs, must be in the list.
• hours and tz — outside the window the skee does not wake.
• max_slippage — simulated vs quoted.
• skip_if_moved — do nothing if reference price moved more than X% since last run.

A failed leash check produces a refusal receipt. There is no override flag anywhere in the system.

09Naps & triggers

nap is either an interval (6h, 1d), a cron expression, or a trigger. Supported triggers at launch: on_listing (new asset registered), on_price(asset, cross, level), on_balance(asset, below, amount). Triggers are evaluated by the scheduler, not by the skee; a sleeping skee consumes nothing.

10Runs

A run is atomic and short. The runtime snapshots balances, prices and open orders at wake; the errand sees only the snapshot. If the chain state changes between snapshot and signing such that the simulation no longer matches, the run is refused and retried at the next nap, never immediately.

11Receipts

{
  "skee": "0x41…c2", "run": 182, "at": "2026-09-14T10:00:00Z",
  "summary": "bought $25 of TSLAx at 248.41 because it was 06:00 and that's the plan",
  "saw": { "USDC": 412.10, "TSLAx": 0.9821, "mid": 248.32 },
  "decided": { "action": "buy", "amount_usd": 25 },
  "leash": { "cap_run": [25,25], "cap_day": [25,100], "assets": "ok", "hours": "ok" },
  "did": { "tx": "0x8a1f…3e", "block": 4811902, "fee_usd": 0.02 },
  "next": "2026-09-14T16:00:00Z"
}

The receipt hash is anchored on-chain (§18). The full JSON is stored by the runtime and exportable; the summary line is what the app shows first.

12Owner & kill switch

The owner is the wallet that spawned the skee. Only the owner can: edit the job or leash, pause, resume, kill, withdraw the gas wallet. skee kill <id> sends one signed call; the runtime stops the scheduler, cancels open orders, and marks the skee killed. Resuming requires a second signature. Use a hardware wallet or multisig as owner (§30).

13Architecture

owner wallet ──spawn/kill──▶ SkeeFactory / Skee contract   (Robinhood Chain)
                                   ▲ receipts anchored
scheduler ──wake──▶ runner ──▶ errand (sandbox) ──intent──▶ simulator ──▶ leash ──▶ signer ──tx──▶ chain
                                   ▲ snapshot (balances, prices, orders)

Errand code runs in a sandbox with no network and no keys. It receives the snapshot and returns an intent. Everything after the intent is the runtime's.

14Key custody

Each skee has its own gas wallet, generated by the runtime and held in an HSM-backed signer. It holds only gas and the working balance the owner deposits. The owner's key is never in the runtime. Trading balances are held in the Skee contract, which only accepts calls from the signer and only within the leash encoded on-chain (§17).

15Simulation & signing

Intents are simulated with eth_call against the latest block. The simulator extracts: USD value moved, assets touched, effective slippage, gas. The leash is evaluated on these numbers. Signing happens only if all checks pass and the block is within 2 of the snapshot block.

16Scheduler

The scheduler is a replicated service that wakes skees. It is the only always-on component. It has no keys and cannot sign. If the scheduler is down, skees simply do not run; nothing is lost, and missed runs are not "caught up" unless the errand opts in with catch_up: true.

17Skee contract

Every skee is a small contract holding its working balance. The leash's assets and cap_per_day are also encoded on-chain and enforced by the contract independently of the runtime, so a compromised runtime still cannot exceed them. The owner can withdraw at any time.

18Receipt anchoring

After each run the receipt hash is written to the Skee contract's receipt log. Anyone can verify that a receipt the runtime shows matches what was anchored, and that no runs are missing from the sequence.

19Gas & fees

• Gas: paid from the skee's gas wallet per run.
• Runtime fee: a flat per-run fee, charged only on runs that act; "did nothing" runs are free.
• Errand author share: a portion of the runtime fee goes to the errand's author.

Live values: skee fees.

20Model calls

Some errands (e.g. watch) may call a model to classify inputs. Rules: the call is made by the runtime, its result is cached for the run, it may only return values from a fixed enum declared in the errand, and it can never produce an intent by itself. A model output is an input to a rule; the rule decides.

21skee.yaml

name: tsla-dca
errand: dca@1.2.0
params:
  asset: TSLAx
  amount_usd: 25
  skip_if_moved: 3%
leash:
  cap_per_run: 25
  cap_per_day: 100
  assets: [TSLAx, USDC]
  hours: "09:30-16:00"
  tz: America/New_York
  max_slippage: 0.5%
nap: 6h

22Leash schema

23Errand DSL

errand dca {
  params { asset: Asset, amount_usd: Usd, skip_if_moved: Pct? }
  run(s: Snapshot) -> Intent {
    if skip_if_moved && moved(s.price[asset], s.last.price) > skip_if_moved
      return nothing("price moved ${moved}% since last run, over the band, skipped")
    return swap(USDC -> asset, amount_usd)
      .why("bought $${amount_usd} of ${asset} because it was ${s.time} and that's the plan")
  }
}

The DSL compiles to a sandboxed module. It has no I/O, no randomness, and no access to keys. nothing(reason) and .why(sentence) are mandatory for every path.

24CLI commands

25HTTP API

POST /v1/skees                 spawn
GET  /v1/skees/:id             status, next wake
GET  /v1/skees/:id/receipts    run history
POST /v1/skees/:id/run         run now
POST /v1/skees/:id/kill        kill (owner signature in body)
GET  /v1/errands               library

All mutating calls require an owner signature over the request body.

26Contract interface

interface ISkee {
  function owner() external view returns (address);
  function leash() external view returns (Leash memory);   // assets, capPerDay
  function execute(bytes calldata intent) external;        // signer only, leash-checked
  function kill() external;                                // owner only
  function withdraw(address asset, uint256 amt) external;  // owner only
  function anchor(bytes32 receiptHash) external;           // signer only
}

27Errors

28Guide: a DCA skee, end to end

1. Write the skee.yaml from §21.
2. skee spawn -f skee.yaml; sign once.
3. Deposit working USDC: skee deposit <id> USDC 500.
4. Fund gas: send a small amount to the printed gas wallet.
5. Watch the first run: skee receipts <id> --follow.
6. Leave it alone for a month. Read the receipts when you feel like it.

29Guide: writing an errand

1. skee errand new my_errand scaffolds a DSL file and a test file.
2. Write run(). Every path must end in an intent with .why() or in nothing(reason).
3. skee errand test runs it against recorded snapshots and checks determinism and idempotence.
4. skee errand submit opens a review. Accepted errands are pinned and listed; you earn the author share (§19).

30Guide: multisig as owner

Spawn from a multisig so that kill, edit and withdraw need a quorum. The runtime accepts EIP-1271 signatures. Recommended for any skee holding more than pocket money.

31Safety checklist

• Set cap_per_day to what you'd be fine losing in a bad day.
• Keep assets minimal; add later if needed.
• Use hours for anything equity-related.
• Use a hardware wallet or multisig as owner.
• Deposit working balance in tranches, not all at once.
• Read the first ten receipts.

32FAQ

Can a skee run two errands?

No. Spawn two skees.

Can I talk to it?

No. There is no prompt. You configure it and read its receipts.

What if the runtime is compromised?

The on-chain leash (assets, daily cap) still holds; the attacker is bounded by it. Kill and withdraw with your owner key.

What if an errand has a bug?

The leash bounds the damage per run and per day. Report it; the errand version is frozen and running skees are paused pending owner review.

Does it use AI?

Only where an errand declares a classification step (§20), and never to decide whether to act.

33Glossary

errand — audited program. intent — what an errand wants to do, before simulation. leash — runtime limits. nap — wake schedule. receipt — run record. run — one cycle. skee — one running agent. snapshot — the state a run sees. working balance — funds in the Skee contract the errand may use.