Der Skill hypothesis-test

---
name: hypothesis-test
description: Testet eine Trading-Idee auf der ATAS-Historie über den ATAS-MCP-Server, mit einem Standardbericht zu Kosten, Stichprobengröße, Out-of-Sample-Prüfung und Vergleich mit zufälligen Einstiegen. Verwenden, wenn der Nutzer einen Backtest möchte, ein Setup, ein Muster oder ein Level testen will oder wissen möchte, wie oft etwas passiert („funktioniert Absorption am POC von gestern“, „teste meine Idee“, „wie oft kehrt der Preis zum POC zurück“). Nicht für heutige Signale, Einstiegspunkte oder das Platzieren von Orders.
compatibility: Erfordert den ATAS-MCP-Server, eine Verbindung zu einer Kryptobörse und die Möglichkeit, Code für Berechnungen auszuführen. AI Connect gibt dem Agenten Marktdaten für Krypto.
metadata:
  version: 0.2
  updated: 2026-11-05
---

# hypothesis-test

Teste eine Trading-Idee auf der in ATAS verfügbaren Historie und berichte, was die Daten stützen. Antworte in der Sprache des Nutzers, knapp. Platziere niemals Orders und bezeichne das Ergebnis nie als Beweis, dass die Strategie Geld verdient.

## Feste Regeln

- Teste nur die Regeln, die der Nutzer bestätigt hat. Füge Filter, Sessions oder Zeitfenster nicht auf eigene Initiative hinzu, entferne oder verschärfe sie nicht. Ignoriere Vorlieben aus früheren Teilen des Gesprächs, sofern der Nutzer sie für diesen Test nicht wiederholt hat.
- Verwende nur ATAS-Daten. Externe Dienste und Dateien nur, wenn der Nutzer in derselben Anfrage darum gebeten hat; nenne dann die Quelle im Bericht.
- Rechne mit Code (deinem Tool zur Codeausführung). Berechne keine Statistiken im Kopf. Wenn du keinen Code ausführen kannst, sag das und beschränke dich darauf, Signale zu zählen.
- Halte jede Änderung und Annahme im Bericht unter „Annahmen und Änderungen“ fest, auch kleine.
- Lies Zahlen aus Tools ab. Schätze sie nie anhand eines Screenshots.

## 1. Regeln festlegen

Fülle die Felder aus der Anfrage aus. Frag einmal nach allem, was fehlt, und biete einen Standardwert an. Beginne erst, wenn der Nutzer bestätigt.

| Feld | Beispiel | Standard, wenn der Nutzer zustimmt |
|---|---|---|
| Instrument und Börse | BTCUSDT, Binance Perpetual Futures | Keiner, der Nutzer muss es angeben |
| Bar-Periode | 5 Minuten | Keiner, der Nutzer muss es angeben |
| Setup | Bullishes Engulfing mit Berührung des POC der vorherigen Session | Keiner, der Nutzer muss es angeben |
| Einstieg | Eröffnung des nächsten Bars | Eröffnung des nächsten Bars |
| Stop | Hinter dem Tief des Musters | Keiner, der Nutzer muss es angeben |
| Ziel | 1R | Keiner, der Nutzer muss es angeben |
| Zeitausstieg | Schließen um 20:00 UTC | Keiner, der Nutzer muss es angeben |
| Tageszeitfilter | Nur die Stunden der US-Session | Keiner |
| Seiten | Long und Short | Wie es sich aus dem Setup ergibt |
| Historie | Letzte 60 Tage | Alles, was der Chart laden kann |
| Kosten | Kommission in % des Handelswerts, Slippage 1 Tick pro Seite | Kommission aus `commissions_list`, Slippage 1 Tick pro Seite |
| Funding | Bei einem Perpetual-Futures-Kontrakt berücksichtigen | Nicht berücksichtigen und das in den Annahmen festhalten |

Wenn sich eine Regel auf zwei Arten lesen lässt, frag nach. „Berührt den POC“ braucht eine Definition in Ticks.

## 2. Daten holen, ohne die Charts des Nutzers anzufassen

1. `workspace_get_overview`, dann `instruments_search` für das Instrument.
2. Öffne einen separaten Chart: `modules_open` mit `placement: "newTab"` und `tabName: "Hypothesis test"`. Ändere weder Periode noch Historientiefe auf den Charts des Nutzers.
3. Setze die Tiefe über `module_update_context` mit `timeFrame: {"minutes": 5, "daysToLoad": N}`. Wenn `loaded` false ist, warte und prüfe erneut. Lange Zeiträume können eine Weile zum Laden brauchen.
4. Lies Bars mit `chart_get_bars`: `format: "table"`, nur die benötigten `fields`, `count` bis 2000. Blättere mit `to` rückwärts. Verwirf den letzten Bar, wenn er sich noch bilden könnte.
5. Session-Levels: Füge dem Testchart den Indikator Volumenprofil & TPO hinzu (englisch Volume Profile & TPO, finde ihn mit `indicators_search`) und lies `indicators_get_values` mit `levels: 0`, bis zu 30 Profile pro Aufruf, geblättert mit `to`. Berechne POC und Value Area nicht aus Bars neu.
6. Footprint-Bedingungen: `chart_get_bars` mit `footprint: true`. `footprintBars` ist auf 100 Bars pro Aufruf begrenzt und zählt vom neuesten zurückgegebenen Bar an. Teste Footprint-Bedingungen deshalb nur auf dem Abschnitt, den du tatsächlich lesen kannst, und sag, wie weit er zurückreicht. Prüfe den Footprint zuerst: Wenn das Volumen pro Level auf den meisten Bars fast gleich ist, ist es gleichmäßig verteilt, und solche Levels und POC dürfen nicht verwendet werden. Sag das und nenne die Tage, an denen die Daten normal sind.
7. Ein Setup, das sich als Skript pro Bar ausdrücken lässt, kann mit `scripts_preview` berechnet werden: Es rechnet über die letzten 20000 Bars und speichert nichts. Dafür sind Script Lab und die Erlaubnis zum Ausführen von Skripten nötig. Wird das abgelehnt, nutze Bars.

Wenn ATAS keine Marktdaten für das Instrument liefert, sag, dass sie über AI Connect für Krypto verfügbar sind, und halte an, bis der Nutzer ein Instrument wählt. Replay-Bars und ATAS Sim sind nicht verfügbar; suche keine Umwege.

Bar-Zeiten sind in UTC. Krypto wird rund um die Uhr gehandelt, daher werden Sessions über Tageszeiten definiert. Nimm den Chart-Offset aus `chartTimeZoneOffset` und berücksichtige Sommerzeitumstellungen, wenn die Session an New York oder London gebunden ist.

Halte vor der Berechnung den ersten und letzten Bar, die Anzahl der Sessions und eventuelle Lücken fest, und ob der angeforderte Zeitraum vollständig geladen wurde. Wenn nicht, nenne dem Nutzer den tatsächlichen Zeitraum.

## 3. Ehrlich rechnen

- **Kein Look-ahead.** Ein Signal existiert erst, nachdem sein Bar geschlossen hat. Ein Level existiert erst, nachdem die Session, die es gebildet hat, geschlossen hat. Einstieg auf dem nächsten Bar oder später.
- **Stop und Ziel im selben Bar:** Werte es als Stop und berichte, wie viele Trades das betraf.
- **Kosten:** Kommission und Slippage bei jedem Trade, beim Einstieg und beim Ausstieg. Berechne eine prozentuale Kommission aus dem Handelswert zum Füllpreis. Berücksichtige Funding nur, wenn der Nutzer darum gebeten hat.
- **Offene Positionen:** jeweils eine Position, sofern der Nutzer nichts anderes gesagt hat. Berichte, wie viele Signale deshalb übersprungen wurden.
- **Kontrakte:** Spot und Perpetual Futures haben keine Rollovers. Wenn das Instrument ein Verfallsdatum hat, vermerke Rollovers innerhalb des Zeitraums.
- **Bars sind keine Ticks.** Ein- und Ausstiege nähern nur an, was eine echte Order bekommen hätte.

## 4. Mit etwas vergleichen

- **Nach Zeit teilen, bevor du dir das Ergebnis ansiehst:** Die ersten 70 % sind In-Sample, die letzten 30 % die Out-of-Sample-Prüfung. Berichte beide Teile. Wenn Out-of-Sample weniger als 30 Trades hat, sag, dass es nichts bestätigen kann.
- **Vergleichsbasis:** dieselben Ausstiege und Kosten bei zufälligen Einstiegen in denselben Sessions, mit genug Wiederholungen für ein stabiles Ergebnis. Zeig das Setup neben dieser Basis, zusammen mit der Streuung der Durchläufe. Liegt das Ergebnis des Setups innerhalb der Streuung, schreib, dass es sich nicht von zufälligen Einstiegen unterscheidet. Nenne es weder besser noch schlechter.
- **Parameteranpassung:** Optimiere nur, wenn darum gebeten wird. Wenn ja, berichte, wie viele Varianten du probiert hast, und teste die gewählte nur ein einziges Mal Out-of-Sample.

## 5. Ein Urteil wählen

Verwende genau eines:

- **Zu wenig Daten:** weniger als 30 Trades insgesamt. Nenne die Anzahl und ziehe keine Schlüsse über das Ergebnis.
- **Kein Vorteil erkennbar:** Nach Kosten ist das Setup nicht besser als die Vergleichsbasis, oder sein Erwartungswert liegt nicht über null.
- **Schwache Bestätigung:** In-Sample besser als die Vergleichsbasis, aber Out-of-Sample weicht es ab, es gibt zu wenige Trades, oder wenige Trades bringen den Großteil des Ergebnisses.
- **Weiter testen lohnt sich:** in beiden Teilen nach Kosten besser als die Vergleichsbasis und nicht von wenigen Trades abhängig.

Schreib niemals „funktioniert“, „profitabel“ oder „bewiesen“. Der stärkste Schluss ist, dass sich weiteres Testen der Idee lohnt.

## 6. Bericht

Verwende dieses Format. Gib Ergebnisse in R und in Prozent des Einstiegspreises an, in Geld nur, wenn die Positionsgröße bekannt ist.

```
Hypothese: <eine Zeile>
Regeln wie getestet: <alle Felder>
Daten: <Instrument, Börse, Zeitraum, erster und letzter Bar, Stunden, Quelle>
Annahmen und Änderungen: <alles, was du selbst entschieden hast, oder "keine">

                   In-Sample   Out-of-Sample   Zufällige Einstiege
Trades
Trefferquote (95-%-Bereich)
Durchschn. Gewinn / Verlust (R)
Erwartungswert nach Kosten (R)
Profit-Faktor
Max. Drawdown (R)
Längste Verlustserie

Kosten pro Trade: <% und R>
Breakeven-Trefferquote für diese Ausstiege: <%>
Stop und Ziel im selben Bar: <Anzahl>
Übersprungene Signale: <Anzahl>
Anteil der 3 besten Trades am Gewinn: <%>
Nach Monaten: <Trades und Erwartungswert>

Urteil: <eines der vier>
Warum: <zwei oder drei Sätze mit Zahlen>
Was dieser Test nicht sagen kann: <seine echten Grenzen>
Nächster Test: <ein konkreter Vorschlag>
```

## 7. Aufräumen

Frag, ob der Testchart behalten werden soll. Wenn nicht, schließe ihn mit `modules_close`. Markiere Beispiel-Trades nur auf Wunsch des Nutzers (`LongPosition` / `ShortPosition`) und nur auf dem Testchart.

Schließe mit einer Zeile: Das ist ein historischer Test; vergangene Ergebnisse garantieren keine zukünftigen Ergebnisse, und die Entscheidung liegt beim Trader.