---
name: create-strategy
description: >-
  Use when the user wants to build a new trading strategy — "build me a
  momentum play on ETH", "find a strategy for BTC", "I want to trade X",
  "make a strategy", or after Stage 0 greeter when the wallet is ready
  and the user is moving into Stage 2 (Author) of trading-bot-workflow.md.
  Drives the author → backtest path using reference strategies (Mechanism
  2) and KB-grounded parameter choices (Mechanism 1) so parameters are
  evidence-backed, not library-default guesses. Wraps
  search_reference_strategies + build_strategy_from_reference +
  create_strategy_autonomous + create_strategy_manual + kb_search.
---

# Create Strategy Skill

The agent's job in this skill: turn a loose user goal ("momentum on ETH")
into a strategy config with **specific signals and specific parameters
backed by evidence**, not library defaults.

Two mechanisms drive "intuition":

- **Mechanism 2 (reference strategies) — the primary path.** Curated
  known-good configs. The agent searches these FIRST, bulk-backtests
  the top matches onto the user's target, and promotes by ranked
  performance. Zero parameter guessing for the common case.
- **Mechanism 1 (KB-grounded parameters) — the fallback.** When
  references don't fit (unusual asset, unusual goal, or user wants to
  modify), the agent is REQUIRED to call `kb_search` for every signal
  it picks before finalizing params. No library-default fallback.

### Portability — reference strategies are signal combos, not pins

Every reference in the library is a **portable signal combination**: the
asset and timeframe on the reference record are where Oracle *found*
the combo worked, not a constraint on where you can apply it.
`build_strategy_from_reference` accepts both `asset` and `timeframe`
overrides for exactly this reason. If the user asks for a strategy on
AVAX 1h and search returns references recorded on BTC 1h + SOL 5m,
both are valid candidates — retarget them onto (AVAX, 1h) and let the
backtest pick the winner. Never quote the reference's own stored
metrics to the user as if they apply to the retarget.

### Bulk-backtest is the default

When Phase A returns multiple plausible matches (the common case),
**do not ask the user to pick by label or description** — build all of
them onto the user's (asset, timeframe), backtest each, and rank by
actual performance. Picking by label is a KB-grounding regression; the
whole point of the library is measured outcomes. Ask the user to choose
only when the backtests tie, or to pick between equivalent PASSes.

A third mechanism (mined parameter priors from the 1.4M-strategy DB)
will land via MangroveAI endpoint after MangroveOracle issue #156. This
skill will transparently benefit once the SDK exposes it — no rewrite
needed here.

## Trigger

Activate when the user:

- Explicitly asks for a strategy ("build me...", "make a strategy", "find me...")
- Is in Stage 2 of `trading-bot-workflow.md` (wallet ready, wants to author)
- Says "trade X", "start running", "put money to work" and a strategy doesn't yet exist

Do NOT activate if the user is asking questions about an existing strategy (use `/monitor-trades` instead) or wants to promote/pause one (use `/promote-strategy`).

## Input — What to Collect

The agent needs four pieces of info before searching references. ORDER these in the order the user volunteered them; if they gave everything in one message, skip straight to Phase A (FAST ADVANCE):

1. **asset** — symbol (BTC, ETH, SOL, etc.). REQUIRED.
2. **timeframe** — 5m / 15m / 30m / 1h / 4h / 1d. Default 1h if user unclear. **1m is NOT supported** — the server will reject it. If the user asks for 1m, say: "1m isn't supported on the Mangrove data source; the smallest is 5m, but I'd recommend 1h for a first strategy — less noise, faster to backtest."
3. **goal / style** — natural language. Used for category detection (momentum, mean_reversion, trend_following, breakout, volatility).
4. **appetite for trades** — high-frequency (many small edges) vs. swing (fewer, bigger moves). Affects which references to recommend.

FAST ADVANCE: if the user's first message has asset + strategy_type + timeframe, skip the Q&A and go straight to Phase A. Infer the rest (knowledge level, sentiment) from tone — don't ask unnecessary clarifying questions.

Example FAST ADVANCE triggers:
- "Build a momentum strategy for ETH on 1h" → asset=ETH, timeframe=1h, goal=momentum
- "Give me a trend following BTC 4h setup" → asset=BTC, timeframe=4h, goal=trend_following

## Phase A — Search References (ALWAYS DO THIS FIRST)

Call `search_reference_strategies(asset, timeframe, goal_hint)`. You will get back up to 5 ranked candidates, each with:

- `id` (e.g. `ref-004` or `oracle-exp_…-<run_index>`)
- `label` (human-readable)
- `description` (why this works / source lineage)
- `entry_signals` + `exit_signals` (names, types, params)
- `category`
- `notes` (tuning hints — may be empty for Oracle-sourced entries)

If search returns 2+ plausible candidates, **do not ask the user to pick by label** — move straight to Phase B-bulk. If search returns exactly one, proceed to Phase B. If it returns 0 results or only low-score matches, jump to **Phase C (Custom build, KB-grounded)**.

Note: the library spans assets and timeframes beyond just the user's target — Oracle-sourced entries have lineage tied to the experiment where the combo was found, but the combo itself is portable. Treat the returned set as candidates regardless of their recorded asset/TF.

## Phase B — Build from Reference (single match)

Only when Phase A returned exactly one candidate. Call `build_strategy_from_reference(reference_id, asset=<user's>, timeframe=<user's>, name=<optional>)`.

You get back a `create_strategy_manual`-compatible payload. Pass it directly to `create_strategy_manual(...)` — DO NOT modify `entry`, `exit`, or `execution_config`. The whole point of Mechanism 2 is that these values came from strategies that already backtested well.

Only adjustable fields:

- `asset` override (retarget the combo onto the user's asset)
- `timeframe` override (retarget onto the user's TF)
- `name` (cosmetic)

If the user wants to TWEAK the reference (e.g. "but use RSI(9) not RSI(14)"): acknowledge their change, then move to Phase C's KB-citation discipline BEFORE applying the tweak. Don't change params without citation.

## Phase B-bulk — Build + backtest the top N references (common case)

When Phase A returns multiple candidates, bulk-build and bulk-backtest. This is the default path because picking by label means picking by description — and descriptions don't predict backtest performance.

```
for ref in references[:N]:        # N ~= 3-5
    payload = build_strategy_from_reference(
        reference_id=ref.id,
        asset=<user's asset>,     # retarget every ref onto the user's target
        timeframe=<user's TF>,    # same
    )
    strategy = create_strategy_manual(**payload)
    backtest_strategy(strategy.id, mode="full")
```

Then rank the results by the Phase F thresholds (sortino, sharpe, calmar, irr, max_drawdown, win_rate). Present the ranked table to the user:

- Winner (PASS) + 1–2 runners-up with per-threshold verdicts
- The loser(s) shown briefly so the user sees that the top one earned its spot, not picked blindly

Ask: "Promote the winner to paper, iterate on the runners-up, or start over with a different goal?" Do NOT auto-promote — the transition is the user's call.

If every backtest fails (all FAIL against threshold_spec), that's a signal the combos in the library don't fit this (asset, TF, goal). Move to Phase C or Phase D rather than promoting a losing config.

## Phase C — Custom Build (KB-GROUNDED, Mechanism 1)

Use this path when:
- Reference search returned nothing useful
- User explicitly wants something unusual (e.g. "combine Ichimoku and Bollinger breakouts")
- User wants to tweak a reference's parameters

**For each signal you consider, you MUST:**

1. Call `kb_search(query="<signal_name> parameters <asset> <timeframe>")`. Example: `kb_search("MACD parameters ETH 1h")`.
2. Read the top 1-3 results. Extract the recommended parameter range or default.
3. In your response, CITE the KB result verbatim (or paraphrase + attribute): "KB recommends MACD(8, 21, 5) for 1h crypto — tighter than the stock 12/26/9 because 1h bars have less noise than daily."
4. Only then write the param values into the strategy.

**Do NOT use library-default params without KB citation.** If the KB has nothing, say so: "KB doesn't have guidance on this specific (signal, asset, timeframe) combo. I'll use the signal's declared default [X] but flag it — consider running a wider backtest to validate."

Composition rules (TRIGGER vs FILTER) — from MangroveAI signal spec:

- **Entry**: EXACTLY ONE TRIGGER + ZERO OR MORE FILTERS
- **Exit**: ZERO OR ONE TRIGGER + ZERO OR MORE FILTERS
- **NEVER a FILTER without a TRIGGER in the same group**
- If the user doesn't specify exits explicitly, use `exit: []` — the volatility-based stop-loss + take-profit are AUTOMATIC at entry, not exit rules
- Each signal does ONE thing (Single Responsibility). Don't stack two momentum triggers; don't mix concepts.

When the config is ready, call `create_strategy_manual(...)` with it.

## Phase D — Autonomous path (FALLBACK when user says "just pick something")

If the user doesn't want to choose a reference or design custom, call `create_strategy_autonomous(goal, asset, timeframe)` with the user's goal text. The server generates N candidates, backtests them in bulk, and returns the winner.

Autonomous is the "I don't care, you decide" escape hatch. It's NOT the primary path — references are. Use autonomous when:
- User explicitly says "pick for me" / "surprise me" / "you decide"
- Phase A returned nothing AND Phase C is too much friction for the user's patience
- You've tried Phase B/C and the user rejected the results

Under no circumstances go straight to Phase D as the first move. Always try Phase A first.

## Phase E — Hand off to /backtest

Regardless of which phase built the strategy, hand off to the
**`/backtest` skill** for the backtest + verdict + iteration flow. That
skill owns window sizing (bar-count-driven, not months-per-timeframe),
the threshold verdict, the benchmark-relative line, and failure-mode
advice.

For Phase B-bulk: the bulk-backtest loop inside this skill still runs
`backtest_strategy` per candidate with a shared window (so the ranked
table is comparable). Size that shared window via the same bar-count
table `/backtest` uses (2000–5000 bars target). Once the winner is
picked, the user can invoke `/backtest` on the winner alone for deeper
investigation (walk-forward, alternative windows).

Do not duplicate the threshold table or verdict rules here — they live
in `/backtest`. If this skill detects a PASS, tell the user the result
and let them invoke `/promote-strategy` directly; if it detects a FAIL
or MARGINAL, suggest `/backtest` for the iteration path rather than
iterating in-place.

## Prohibited

- **Never** claim a signal is "firing" based on catalog listing alone. Only `evaluate_strategy` output can claim that.
- **Never** fabricate backtest metrics. If `metrics` missing from a tool response, say so.
- **Never** use library-default params in Phase C without KB citation.
- **Never** modify a reference's params in Phase B — move to Phase C if the user wants changes.
- **Never** invent signal names not returned by `list_signals` or a reference strategy. If you don't have a name, call `list_signals` first.
- **Never** place a FILTER without a TRIGGER in the same group (entry or exit).
- **Never** recommend 1m timeframes — server rejects them.

## Never Default to Swap Router

Manual swaps (`get_swap_quote` / `execute_swap`) are a fallback. Only route there if the strategy layer is down (`search_reference_strategies` + `create_strategy_autonomous` both fail), and disclose it.

## Summary — Decision Tree

```
User wants a strategy
│
├─→ Phase A: search_reference_strategies(asset, timeframe, goal_hint)
│       │
│       ├─ ≥2 candidates → Phase B-bulk (build all, backtest all, rank)
│       ├─ 1 candidate   → Phase B (single build + backtest)
│       ├─ 0 candidates  → Phase C
│       └─ user says "just pick" → Phase D (autonomous)
│
├─ Phase B-bulk: loop build_strategy_from_reference → create_strategy_manual
│       → backtest_strategy for each; retarget every ref onto the user's
│       (asset, timeframe); rank by threshold_spec; present ranked table
│
├─ Phase B: build_strategy_from_reference + create_strategy_manual
│       (single match; signals + params copied exactly, asset/tf applied)
│
├─ Phase C: kb_search each signal → cite → create_strategy_manual
│       (custom, evidence-backed)
│
└─ Phase D: create_strategy_autonomous(goal, asset, timeframe)
        (server generates + backtests N candidates, returns winner)

→ /backtest skill (window sizing, verdict, iteration)
→ /promote-strategy skill (draft → paper → live)
```