# Strategy Builder

> Give YOURSELF a loop — write a tick playbook (a strategy) under your own slug, dry-run it, and start it. The shared contract for how a strategy is authored, validated and launched; read by any agent that wants to act autonomously instead of only answering what it is handed.

- Skill: `hummingbot/strategy-builder` (Agent Skill)
- Install (CLI): `npx skillmds@latest add hummingbot/strategy-builder`
- Raw SKILL.md: https://api.skillmd.com/api/skills/hummingbot/strategy-builder/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: hummingbot (https://skillmd.com/u/hummingbot)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/hummingbot/strategy-builder

---


# Strategy Builder

You are an **agent**. You can already be delegated to and looped — from the
moment you existed. This playbook covers the last of those: giving your loop a **specific
tick playbook** instead of the generic default.

A **strategy** is a tick system prompt the engine runs in a **session**, at a frequency
the user sets. It lives at `agents/{your_slug}/strategies/{strategy_slug}/strategy.md` and
it is yours — you author it, under your own slug.

> **Scope.** This is about giving *yourself* a loop. Creating, editing or deleting *other*
> agents belongs to Condor (`agent_builder`). If the user wants a whole new specialist,
> say so and let them ask Condor.

## When a strategy is worth it

`control_agent(action="start", strategy_id="<your_slug>")` already works with no
strategy — it ticks a default playbook driven by your AGENT.md. That default is deliberately generic. Write a
strategy when the loop needs to be **specific and disciplined**: a fixed analysis order, a
decision rule, executor schemas, risk limits.

**The loop does NOT have to trade.** Define the tick task however the user wants:

- read a routine's output and **decide whether to trade** (create/stop executors),
- or just **send a report / notification**,
- or watch a condition and act only when it's met.

## Step 1 — Prepare (only if it trades)

BEFORE writing the strategy, read the signature of every create tool the loop will use —
`create_grid_executor`, `create_position_executor`, etc.; their typed parameters ARE the
schema — and embed the required params/types directly into the instructions. The tick LLM has no other way to learn them.
Same for any controller config it manages (`manage_controllers`).

If the loop should reason over structured data, make sure the routine exists first
(`manage_routines(action="list", agent="<your_slug>")`). Routines are agent-scoped, so any
strategy you own can call them. Need a new one? Do NOT write it inline — hand it to a
background worker: `delegate(action="start", agent="condor", task="build a routine that …
for agent <your_slug>")`.

## Step 2 — Create the strategy

```
manage_strategies(
    action="create",
    agent_slug="<your_slug>",              # yourself
    name="BRL MM",
    description="…",
    instructions="<tick system prompt>",
    # agent_key omitted → inherits your model; overridable at launch
    config={"connector_name": "binance", "frequency_sec": 60,
            "total_amount_quote": 100, "execution_mode": "loop"}
)
```

Returns the composite key `"<your_slug>.<strategy_slug>"` — that is the `strategy_id` for
everything after.

The tick instructions MUST include:

- **Objective** — what one tick is for.
- **Analysis** — which routine to call *by name* and how to read its output.
- **Decision logic** — act / report / hold, with the condition for each.

…and, only if it trades:

- **Executor config** — the FULL schema: every required field, type, range, ordering rule.
- **Parameter inference** — how to derive prices/side/TP from routine output + market data.
- **Risk rules** — max position, position limits, stop behaviour.
- **Error recovery** — on a failed create, re-fetch the schema, fix, retry once, journal it.

**Generic vs specific:**
- GENERIC (default): pair/connector are NOT in the instructions — they arrive at launch via
  `trading_context`. Refer to "the configured trading pair"; keep a sensible `default_config`.
- SPECIFIC: pair/connector baked in (e.g. an ETH/BTC ratio play).

## Step 3 — Dry run before live (if it trades)

```
control_agent(action="start", strategy_id="<your_slug.strategy_slug>",
    config={"execution_mode": "dry_run",
            "trading_context": "Trade BTC-USDT on binance_perpetual",
            "frequency_sec": 60, "total_amount_quote": 100,
            "risk_limits": {"max_position_size_quote": 200, "max_open_executors": 3}})
```

Review with `trading_agent_journal_read(agent_id=…, section="run:1")`: routines called
right, decision logic sound, conditional language ("would place…"), no real create/stop
calls, risk rules respected. Do not go live until the user is satisfied.

> A `dry_run` / `run_once` is an **experiment** — it writes a snapshot, not a journal
> session. Read it back the same way; don't expect a numbered run to persist.

## Step 4 — Go live

Offer `run_once` (single live tick), `loop` (continuous), or `loop` + `max_ticks`. Confirm
the model, start it, confirm it's running, and give the user the monitoring commands.
**Always include risk limits when the loop can trade.**

## Monitoring what you own

1. `manage_agents(action="list")` — agents and the strategies they own.
2. `control_agent(action="list")` — running loop instances, with their status.
3. `trading_agent_journal_read(agent_id=…, section="summary"|"runs"|"run:N")`.

**Operating a loop that is already running — pausing it, resuming it, ending it — is the
`operate_your_loop` playbook, not this one.** Read it
(`manage_skill(action="read", name="operate_your_loop")`) before stopping anything: `stop`
halts the ticks and leaves the positions open, `shutdown` winds them down first, and picking
the wrong one strands live capital. This playbook ends at launch.

## Reference

**Model:** the strategy's `agent_key` defaults to yours; override per launch with
`config={"agent_key": "…"}`. Never invent one — call `get_available_models` and pick from
what the operator actually has, or leave it inherited. A pydantic-ai key
(`ollama:`/`openai:`/`groq:`/`lmstudio:`/`openrouter:`/`custom@…`) enforces the `tools`
allowlist; an ACP key (`claude-code`/`claude-acp`/`gemini`/`copilot`) runs unrestricted,
with mutations still confirmation-gated.

**Server:** leave `server_name` empty unless the user pins it. A strategy you own runs on
whichever server your agent resolves.

**Editing & deleting:** `update_strategy(strategy_id=…, instructions=…)` to revise the tick
playbook; `delete_strategy(strategy_id=…)` to remove it. Stop any running instance first.

## Rules

- Author strategies **under your own slug only**. Another agent's fleet is not yours to edit.
- Fetch executor/controller schemas BEFORE writing instructions that use them.
- One strategy per loop job — don't overload a tick with unrelated objectives.
- A loop doesn't have to trade. When it does: risk limits always, dry run always.
- Show the user the dry-run journal before proposing to go live.
- Don't write routine code inline — delegate it to a Condor worker.