Update to TraderSpy

{
  "description": "Query, explain and evaluate TraderSpy's AI crypto futures signals — the newest signals, signals for one coin, what a signal's entry / take-profit / stop levels and triggered conditions mean, whether a signal still stands at the current price, and how signals have performed (hit rate, hits vs stops) over the last 4h to 7d. Use this whenever the user mentions crypto signals, AI alerts, \"any setups\", \"what is the AI seeing\", long/short ideas, TraderSpy alerts, signal performance or track record — even when they never say the word \"signal\". Not for placing trades (no tool can), not for whale or top-trader positioning (smart-money), not for indicator reads on a coin (technical-analysis).",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 505
    },
    {
      "relative_path": "references/signal-fields.md",
      "size_in_bytes": 4133
    }
  ],
  "name": "trading-signals",
  "skill_md_contents": "---\nname: trading-signals\ndescription: Query, explain and evaluate TraderSpy's AI crypto futures signals — the newest signals, signals for one coin, what a signal's entry / take-profit / stop levels and triggered conditions mean, whether a signal still stands at the current price, and how signals have performed (hit rate, hits vs stops) over the last 4h to 7d. Use this whenever the user mentions crypto signals, AI alerts, \"any setups\", \"what is the AI seeing\", long/short ideas, TraderSpy alerts, signal performance or track record — even when they never say the word \"signal\". Not for placing trades (no tool can), not for whale or top-trader positioning (smart-money), not for indicator reads on a coin (technical-analysis).\n---\n\nTraderSpy's AI signals are automated reads of the market: a named preset fires when several\ntechnical conditions line up on one crypto futures pair, a validator scores the alignment, and\nthe published signal carries an entry, a take-profit ladder, a stop and — later — what actually\nhappened. The signals feed at https://traderspy.app/signals publishes every one with its resolved\noutcome. Your job is to fetch,\ntranslate and contextualise them; the decision stays with the user.\n\n## Tools\n\n| Tool | Use it for | Key arguments |\n| --- | --- | --- |\n| `get_signals` | The list: newest first | `limit` 1–50 (default 20), `skip`, `importance` high / medium / low / all, `coin` |\n| `get_signal_details` | One signal in full, plus the live price | `signalId` (the `id` from the list) |\n| `get_signal_stats` | Aggregate hit rate over a window | `period` 4h / 8h / 24h / 7d |\n\nThree argument behaviours that are easy to get wrong:\n\n- **`importance` is inclusive downward.** `high` returns high only, `medium` returns high AND\n  medium, `low` returns everything. To show \"medium and above\" pass `medium`, not `low`.\n- **`coin` is a prefix match** on the pair name. `BTC` matches `BTCUSDT` and also `BTCDOMUSDT`;\n  check the `coin` field of each row before presenting \"BTC signals\".\n- **`limit` is what gets rendered.** In hosts that draw signal cards, every fetched row becomes a\n  card. If the user asks for \"the last 5\", pass `limit: 5` — do not fetch 20 and show 5.\n\n## What a signal row contains\n\n`strategyName` (the preset, e.g. \"OBV Divergence Buy (4H)\") · `action` buy / sell · `timeframe`\n1h / 4h / 1d · `price` at trigger · `targets[]` as `{label, type, pct}` where `pct` is measured from\n`price` · `triggeredConditions[]` in plain language · `importance` · `signalStrength` weak /\nmoderate / strong / very_strong · `resolutionStatus` · `createdAt`.\n\nConvert target percentages to prices before showing them — users think in prices:\n\n- buy: TP = price × (1 + pct/100), SL = price × (1 − pct/100)\n- sell: TP = price × (1 − pct/100), SL = price × (1 + pct/100)\n- reward-to-risk at TP1 = TP1 pct ÷ SL pct (a 0.7 R:R is normal for this system, whose first target\n  sits close to entry; read it together with the hit rate from `get_signal_stats`, and do not call a\n  sub-1 R:R \"bad\" on its own).\n\n`resolutionStatus` is the outcome so far:\n\n| Status | Meaning |\n| --- | --- |\n| `pending` | Still inside its tracking window, nothing hit yet |\n| `tp1_hit` / `tp2_hit` / `tp3_hit` | Highest take-profit reached (a later stop touch does not downgrade it) |\n| `profit_locked` | Trend exhaustion detected before TP1; a partial gain was locked |\n| `stop` | Stop level touched before any take-profit |\n| `expired` | Window ended with neither side touched |\n\nOutcomes are judged on 1-minute wicks, so \"TP1 hit\" means price actually traded there. The\ntracking window is 24 × the signal timeframe (24h for a 1h signal, 4 days for a 4h signal); a 1h\nsignal that is still `pending` two days later is stale rather than alive.\n\n## Workflows\n\n**\"Latest signals\" / \"any setups?\"** → `get_signals` with the limit the user implies (default 10 if\nthey gave no number). Lead with the newest, group by side if several, and make the resolved ones\nvisible — a list that mixes three winners, two stops and five pending rows should say so.\n\n**\"Signals for SOL\"** → `get_signals` with `coin`. If the result is empty, say there is no recent\nsignal on that pair rather than offering a different pair as if it were the same thing.\n\n**\"Is this signal still valid?\" / \"Should I still care about it?\"** → `get_signal_details`, then\ncompare `livePrice` with the entry, TP1 and SL in the same units:\n\n- distance from entry in % (signed the way the trade wants it: for a buy, positive = in profit)\n- whether a level has already been crossed (a `pending` buy with `livePrice` below the SL price\n  is finished in everything but paperwork — say so)\n- `history.highestPrice` / `lowestPrice` show the best and worst it has seen since entry\n- `indicatorValues` are the readings at trigger time, not now; if the user wants the current\n  picture, hand off to technical-analysis rather than re-reading stale values as if they were live\n\n**\"How are the signals doing?\"** → `get_signal_stats`. Explain the number honestly: `winRate` is\nhits ÷ (hits + stops) over signals CREATED in the window, so it ignores `pending` rows, and a 4h\nwindow is a handful of signals. Prefer `7d` for a track-record question and say how many signals\nit rests on (`total`, `pending`).\n\n## Presenting\n\nFor a list, ALWAYS use a compact table and keep one signal per row:\n\n| Coin | Side | TF | Entry | TP1 | SL | Preset | Status | Age |\n\nFor one signal, use this order: headline (coin, side, timeframe, preset, importance) → the levels\nas prices with the % in brackets → what triggered it (the `triggeredConditions`, lightly\nrephrased) → where price is now versus entry / TP1 / SL → the outcome so far → the one-line risk\nnote. Quote `livePrice` with its timestamp when the answer depends on it.\n\nDo not invent an \"AI review\" if `aiReview` is null — most signals do not carry one. When it exists,\nreport `score` and `decision` as the reviewer's opinion, not as a verdict.\n\n## Conduct\n\n- These are indicator alignments with published outcomes, not instructions. Report what the\n  signal says, what has happened to it and what has happened to signals like it; if the user asks\n  whether to take it, lay out what supports and what undercuts it and hand the decision back. Never\n  tell the user to buy, sell, size or leverage.\n- Historical hit rates describe the sample they were computed on. Never present a win rate as a\n  forecast or imply any outcome is assured.\n- Nothing in this connector trades. There is no order, close, transfer or withdrawal tool, by\n  design. If asked to execute, say so plainly; the decision and the trade stay with the user.\n- Every number comes from a tool result; if a field is null, say it is unavailable rather than\n  estimating it.\n- When the answer is about a specific trade idea, end with one plain sentence that crypto\n  derivatives are high-risk and this is market information, not financial advice. Once per answer\n  is enough.\n\nFor the full field glossary, including the `indicatorValues` keys, read\n`references/signal-fields.md`.\n"
}