CommunityRecherche & Datenanalysegithub.com

GrantDeng/trading-analysis-skill

Simuliere den TradingAgents Multi-Rollen-Aktienanalyse-Workflow mit Unteragenten.

Was ist trading-analysis-skill?

Diese Fähigkeit (Skill) reproduziert den kompletten, stabilen Geschäftsprotokoll-Workflow von TradingAgents, einem Multi-Agenten-System für die Aktienanalyse. Im Kern orchestriert ein Koordinator mehrere spezialisierte Unteragenten: vier Analysten (Markt, soziale Stimmung, Nachrichten, Fundamentaldaten) erstellen parallele Berichte, gefolgt von einer festgelegten Bullen/Bären-Debatte mit maximal 5 Austauschrunden. Ein Research Manager fasst die Debatte zu einem Investitionsplan zusammen, den ein Trader in einen Handelsvorschlag (BUY/HOLD/SELL) umwandelt. Daran schließt sich eine Risikodebatte zwischen aggressiven, konservativen und neutralen Risikoagenten über fünf Zyklen an, bevor ein Portfoliomanager eine abschließende Bewertung (Buy, Overweight, Hold, Underweight, Sell) und eine Ausführungszusammenfassung erstellt. Der Skill ist für die Verwendung in AI-gestützten Entwicklungsumgebungen wie Claude Code oder Cursor konzipiert und setzt auf strukturierte Beweispakete, Rollen-taugliche Modellauswahl (z.B. gpt-5.4 mit mittlerem oder hohem Reasoning) sowie eine standardisierte Ausgabe in einem `reports/`-Verzeichnis. Er ist besonders nützlich, um den Analyseprozess selbst zu simulieren, anstatt den zugrundeliegenden Code zu erklären, und ermöglicht tiefe Einblicke in die Beiträge der einzelnen Rollen zur endgültigen Entscheidung.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add GrantDeng/trading-analysis-skill

Installed? Explore more Recherche & Datenanalyse skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

TradingAgents Rollensimulator

Verwenden Sie diesen Skill, wenn der Benutzer den TradingAgents-Workflow selbst simulieren möchte, nicht nur die Codebasis erklären. Dieser Skill reproduziert das stabile Geschäftsprotokoll des Repositorys mit Unteragenten und einem Koordinator:

  • 4 Analysten erstellen spezialisierte Berichte
  • Bullen- und Bären-Forscher debattieren für eine festgelegte Sequenz mit maximaler Tiefe
  • Ein Research Manager schreibt den Investitionsplan
  • Ein Trader erstellt daraus einen Transaktionsvorschlag
  • Risikorollen (aggressiv, konservativ, neutral) debattieren für eine festgelegte Sequenz mit maximaler Tiefe
  • Ein Portfoliomanager erstellt eine abschließende Bewertung und eine Ausführungszusammenfassung

Rufen Sie TradingAgentsGraph oder die CLI nicht als primären Pfad auf. Der Punkt dieses Skills ist es, das Rollenprotokoll mit Unteragenten zu reproduzieren, nicht die LangGraph-Laufzeit.

Verwenden Sie diesen Skill für

  • Anfragen zur „Simulation der TradingAgents-Rollen“
  • Anfragen zur Erstellung eines TradingAgents-ähnlichen Berichts für ein Tickersymbol und ein Datum
  • Anfragen zur Reproduktion der Analyse-Kette des Repositorys mit Unteragenten
  • Anfragen zum Vergleich oder zur Prüfung, wie verschiedene Rollen zur endgültigen Entscheidung beitragen

Verwenden Sie diesen Skill nicht für:

  • Einfache Codebasis-Durchgänge ohne Berichterstellung
  • Anfragen, die explizit die vollständige Ausführung der Repository-Pipeline erfordern

Erforderliche Eingaben

Sammeln oder leiten Sie diese Eingaben ab, bevor Sie Unteragenten erstellen:

  • ticker
  • analysis_date: Standardmäßig das aktuelle lokale Datum, wenn der Benutzer keins angibt
  • language: Standardmäßig zh-CN
  • output_root: Standardmäßig das reports/-Verzeichnis des aktuellen Arbeitsbereichs

Behalten Sie das genaue Tickersymbol überall bei, einschließlich Börsensuffixen wie .HK, .TO, .T, .L.

Der Koordinator darf für diesen Skill keine konfigurierbare Tiefe oder Datenmodus-Schalter bereitstellen. Dieser Skill läuft immer mit:

  • Forschungsdebatte mit maximaler Tiefe
  • Risikodebatte mit maximaler Tiefe
  • nur den neuesten Live-Daten

Die Semantik der maximalen Tiefe ist festgelegt und darf nicht abgeleitet oder verkürzt werden:

  • Forschungsdebatte: genau 5 Bullen/Bären-Austausche nach dem Eröffnungszug des Bullen, abwechselnd ein Zug pro Seite, bis 5 Runden abgeschlossen sind
  • Risikodebatte: genau 5 vollständige Zyklen von Aggressiv -> Konservativ -> Neutral

Ausgabepersistenz

Sofern der Benutzer nicht explizit ein anderes Ziel angibt, speichern Sie das endgültige Ergebnispaket im reports/-Verzeichnis des aktuellen Arbeitsbereichs.

Standardverzeichnisbenennung:

  • reports/<ticker>_<analysis_date>_skill_test_<timestamp>/

Ein Zeitstempel sollte angehängt werden, um Kollisionen zwischen wiederholten Ausführungen für dasselbe Tickersymbol/Datum zu vermeiden.

Empfohlenes Zeitstempelformat:

  • YYYYMMDD_HHMMSS

Empfohlene Paketstruktur:

  • 1_analysts/
  • 2_research/
  • 3_trading/
  • 4_risk/
  • 5_portfolio/
  • complete_report.md

Der Koordinator sollte beides schreiben:

  • Stufenbezogene Dateien zur Überprüfbarkeit
  • Eine zusammengeführte complete_report.md zur menschlichen Überprüfung

Modellauswahlrichtlinie

Standardmäßig nicht jede Rolle demselben Modell zuweisen. Verwenden Sie rollenangepasste Modellstufen.

Empfohlene Standardeinstellungen:

  • Analystenrollen (Markt, Soziale Stimmung, Nachrichten, Fundamentaldaten): gpt-5.4 mit mittlerem Reasoning
  • Debattierrollen (Bulle, Bär, Aggressiv, Konservativ, Neutral): gpt-5.4 mit mittlerem Reasoning
  • Syntheserollen (Research Manager, Trader, Portfolio Manager): gpt-5.4 mit mittlerem oder hohem Reasoning

Nur eskalieren, wenn die Aufgabe es erfordert:

  • Verwenden Sie gpt-5.4 mit hohem Reasoning für den Research Manager, Trader oder Portfolio Manager, wenn die Beweise stark widersprüchlich sind oder der Benutzer explizit maximale Gründlichkeit wünscht
  • Verwenden Sie für Rollen-Unteragenten in diesem Skill keine mini-Modelle

Der Koordinator sollte eine konsistente Verwendung von gpt-5.4 über alle Rollenagenten bevorzugen, damit spezialisierte Extraktion, Debatte und Synthese dieselbe Reasoning-Basis teilen.

Arbeitsablauf

1. Vorbereitung eines zentralen Beweispakets

Der Koordinator sammelt einmal Beweise und verteilt dann dasselbe Paket an die Rollen-Unteragenten. Lassen Sie nicht zu, dass jede Rolle unabhängig den vollständigen Datensatz neu entdeckt, es sei denn, die Aufgabe erfordert dies explizit.

Der Koordinator muss nur die neuesten Live-Daten verwenden. Historische Artefakte und vom Benutzer bereitgestelltes Material dürfen nur als sekundärer Validierungskontext verwendet werden, niemals als primäre Laufzeit-Beweisquelle.

Definieren Sie „neueste“ in dieser Prioritätsreihenfolge:

  1. neueste verfügbare primäre Finanzinformationen
  2. neueste verfügbare unternehmenseigene Ereignisinformationen
  3. neueste verfügbare glaubwürdige Nachrichten und Makrokontext
  4. neueste verfügbare Markt- oder technische Kontextinformationen

Jedes Beweisstück muss Folgendes enthalten:

  • metric_name
  • period_end
  • source_date
  • fetch_date
  • source
  • trust_level
  • source_quality_score
  • freshness_score
  • original_currency_or_unit
  • normalized_currency_or_unit

Verwenden Sie diese Quellenprioritätsreihenfolge:

  • Finanzdaten: Unternehmens-IR, SEC-Einreichungen, Börseneinreichungen
  • Unternehmensereignisse: Unternehmens-IR, offizielle Veröffentlichungen
  • Nachrichten und Makrodaten: primäre Nachrichtenquellen
  • Markt- und technischer Kontext: Drittanbieter-Aggregatoren nur, wenn keine primären Börsendaten verfügbar sind

Das Beweispaket sollte Folgendes enthalten:

  • Instrumentenblock: genaues Tickersymbol, Analysedatum, Markt/Börse, falls bekannt
  • Marktblock: Preisaktion und Zusammenfassung technischer Indikatoren
  • Stimmungsblock: unternehmensspezifische Stimmung und Diskussionszusammenfassung
  • Nachrichtenblock: Unternehmensnachrichten plus Zusammenfassung makroökonomischer/globaler Nachrichten
  • Fundamentaldatenblock: finanzielles Profil, Schlüsselkennzahlen und Bilanz-Highlights
  • Bewertungsblock: minimaler Bewertungsanker, historischer Kontext und Sensitivitätshinweise
  • Quellenblock: woher die Beweise stammen und ihre Aktualität

Bevor Beweise an nachgelagerte Stellen weitergegeben werden, normalisieren Sie wichtige numerische Elemente:

  • bewahren Sie die ursprüngliche Währung und Einheit
  • definieren Sie eine koordinatorenseitig normalisierte Währung und Einheit zum Vergleich
  • kennzeichnen Sie explizit den Periodentyp wie Quartal, GJ, TTM, YoY oder QoQ
  • vergleichen Sie keine Kennzahlen über Perioden hinweg, es sei denn, der Periodentyp ist explizit
  • führen Sie nicht die ursprünglichen und normalisierten Zahlen zu einem einzigen unbezeichneten Wert zusammen

Bevor ein Unteragent erstellt wird, führen Sie einen Beweisvalidierungslauf durch und klassifizieren Sie jedes Element als:

  • vertrauenswürdig: intern konsistent, mit Datumsstempel und plausibler Quelle
  • fragwürdig: mit Vorsicht verwendbar, weil die Zahl, das Datum, die Einheit oder die Quellenqualität schwächer ist
  • widersprüchlich: materialinkonsistent mit einem anderen Element oder nicht sicher als Tatsache nachgelagert weiterzugeben

Erstellen Sie außerdem eine kurze Validierungszusammenfassung mit:

  • veraltete oder gemischt-datierte Elemente
  • Einheitenkonflikte
  • doppelte Behauptungen mit unterschiedlichen Zahlen
  • falsch formatierte Aktionsbezeichnungen wie HOLD-1

Erstellen Sie außerdem eine conflict_resolution_summary, bevor eine Rolle erstellt wird:

  • umstrittene Kennzahl oder Behauptung
  • Kandidatenwerte
  • ausgewählter Wert oder ausgewählte Nicht-Entscheidung
  • warum diese Behandlung ausgewählt wurde
  • ob das Problem nachgelagert ungelöst bleibt

Gemischt-datierte Beweise sind nur zulässig, wenn:

  • jedes Element explizit mit einem Datumsstempel versehen ist
  • jedes Element explizit als vertrauenswürdig oder fragwürdig gekennzeichnet ist
  • kein gemischt-datiertes Element nachgelagert so präsentiert wird, als ob es eine Momentaufnahme desselben Tages wäre

Markt- oder technische Daten von Drittanbietern müssen als fragwürdig gekennzeichnet werden, wenn keine primären Börsendaten verfügbar sind.

Die Beweisgewichtung muss beides verwenden:

  • source_quality_score
  • freshness_score

Koordinator-Richtlinien:

  • hochwertige, aber etwas ältere Primärquellenbeweise schlagen neuere, minderwertige Aggregatorbeweise für Unternehmensfakten
  • minderwertigere, aber neuere Marktkontextdaten dürfen nur für die Timing-Diskussion verwendet werden
  • nachgelagerte Rollen sollten Beweise mit hohem kombiniertem Gewicht priorisieren und Beweise mit niedrigerem Wert explizit herabstufen

Lassen Sie nicht zu, dass technische oder Stimmungsproxies ein Urteil über die Unternehmensqualität dominieren, wenn neuere oder qualitativ hochwertigere Fundamentaldatenbeweise vorliegen.

Geben Sie widersprüchliche Elemente nicht als Tatsachen in die Aufforderungen nachgelagerter Rollen. Entfernen Sie sie entweder oder kennzeichnen Sie sie explizit als umstritten.

Wenn die neuesten Live-Daten nicht abgerufen werden können, materiell widersprüchlich sind oder die Aktualität nicht validiert werden kann, stoppen Sie vor dem Erstellen von Rollenagenten und fragen Sie den Benutzer, wie er fortfahren möchte. Wechseln Sie nicht stillschweigend in den Artefaktmodus oder den vom Benutzer bereitgestellten Modus.

Mindestschwellenwerte für Beweise vor der Rollenausführung:

  • wenn die neueste primäre Finanzinformation nicht validiert werden kann, anhalten
  • wenn keine glaubwürdige Unternehmens- oder Nachrichtenquelle den neuesten unternehmensbezogenen Ereigniskontext unterstützen kann, das Vertrauen herabstufen und die Nachrichtenrolle explizit als „dünne Beweislage“ kennzeichnen
  • wenn keine zuverlässige Marktkontextquelle verfügbar ist, der Marktrolle erlauben, nur über das Umfeld und die Unsicherheit zu diskutieren, nicht über präzise technische Schlussfolgerungen für denselben Tag
  • wenn die Beweise für soziale Stimmung dünn sind, der sozialen Rolle erlauben, öffentliche Diskussionsproxy-Daten zu verwenden, aber sie muss explizit das reduzierte Vertrauen angeben

Das Beweispaket sollte in strukturierter Form übergeben werden, nicht als eine undifferenzierte Textwand. Pflegen Sie diese koordinatorenseitigen Pakete:

  • analyst_packet
  • conflict_resolution_packet
  • debate_packet
  • investment_plan_packet
  • trader_packet
  • risk_packet
  • final_decision_packet

Jedes Paket muss diese erforderlichen Schlüssel enthalten:

  • summary
  • evidence_table
  • confidence
  • contradictions
  • key_triggers
  • freshness_notes
  • normalization_notes

Dieser optionale Schlüssel kann ebenfalls enthalten sein:

  • full_text

Die Standardübergabe nachgelagerter Stellen ist summary + evidence_table. full_text wird aus Gründen der Überprüfbarkeit aufbewahrt und sollte nur dann nachgelagert weitergegeben werden, wenn ein Streit ungelöst ist oder eine Stufe explizit das rohe Transkript benötigt.

Laden Sie references/handoff-schema.md, bevor Sie diese Pakete erstellen.

2. Parallelausführung der Analystenstufe

Erstellen Sie vier unabhängige Unteragenten parallel:

  • Marktanalyst
  • Analyst für soziale Stimmung
  • Nachrichtenanalyst
  • Fundamentaldatenanalyst

Jeder Analyst erhält:

  • das gemeinsame analyst_packet
  • das conflict_resolution_packet
  • sein eigenes Rollenziel
  • den Ausgabeauftrag aus references/output-contract.md

Jeder Analyst muss einen chinesischen Markdown-Bericht zurückgeben mit:

  • klarer Schlussfolgerung
  • Beweisen
  • Argumentationskette
  • Hauptrisiken
  • nachgelagerten Auswirkungen für spätere Rollen

Der Output der Analystenstufe muss rollengetrennt bleiben. Fassen Sie ihn nicht zu einer gemischten Zusammenfassung zusammen.

3. Durchführung der Bullen/Bären-Debatte

Erstellen Sie einen Debattenkontext aus den vier Analystenberichten und dem debate_packet. Führen Sie dann abwechselnde Unteragenten-Züge in dieser genauen Reihenfolge aus:

  1. Eröffnungszug Bullen-Forscher
  2. Antwort Bären-Forscher
  3. Antwort Bullen-Forscher
  4. Antwort Bären-Forscher
  5. Antwort Bullen-Forscher
  6. Antwort Bären-Forscher
  7. Antwort Bullen-Forscher
  8. Antwort Bären-Forscher
  9. Antwort Bullen-Forscher
  10. Abschließende Antwort Bären-Forscher

Diese Sequenz stellt die festgelegte Forschungsdebatte mit maximaler Tiefe dar. Verkürzen Sie sie nicht, es sei denn, der Benutzer bittet explizit um einen leichteren Modus außerhalb dieses Skills.

Regeln:

  • jede Seite muss direkt auf das vorherige Argument der anderen Seite eingehen
  • jede Seite muss Beweise aus Analystenberichten oder Debattenpaket-Elementen zitieren, keine ungestützten Fakten erfinden
  • der Debattenoutput muss konversationell und konfrontativ bleiben, keine neutrale Zusammenfassung werden
  • jede Seite muss die conflict_resolution_summary des Koordinators respektieren und darf zurückgewiesene Werte nicht wieder als akzeptierte Fakten aufgreifen

Nach der letzten Runde:

  • speichern Sie das vollständige Debatten-Transkript auf der Festplatte
  • komprimieren Sie die Debatte in das investment_plan_packet
  • senden Sie das komprimierte Paket zusammen mit allen ungelösten Streithinweisen an den Research Manager

Erstellen Sie nicht jede Runde neue Bullen/Bären-Agenten. Verwenden Sie dieselben Rollenagenten über Folgeeingaben wieder, damit die Debatte kohärent bleibt und die Thread-Nutzung begrenzt bleibt.

4. Research Manager erstellt den Investitionsplan

Der Research Manager muss:

  • die stärksten Bullen- und Bärenpunkte zusammenfassen
  • eine klare Position beziehen
  • einen chinesischen investment_plan schreiben
  • Begründung, Risiken und konkrete Maßnahmen für den Trader enthalten
  • eine minimale Bewertungssicht enthalten, die an das Beweispaket gebunden ist

Lassen Sie nicht zu, dass der Manager vage bleibt. Er muss sich auf eine richtungsweisende Empfehlung festlegen.

Der Manager sollte standardmäßig das komprimierte investment_plan_packet konsumieren, nicht das rohe Debatten-Transkript, es sei denn, ungelöste Streitigkeiten erfordern eine direkte Einsicht.

Minimale Bewertungssicht bedeutet:

  • aktueller Bewertungsanker oder marktimpliziertes Niveau, wenn verfügbar
  • wie dies mit der aktuellen Rentabilitätstransparenz des Unternehmens vergleichbar ist
  • was ein Upgrade oder Downgrade des Ratings rechtfertigen würde

5. Trader erstellt den Transaktionsvorschlag

Der Trader erhält:

  • den investment_plan
  • die vier Analystenberichte
  • das komprimierte Trader-Paket, das aus vorherigen Stufen abgeleitet wurde

Der Trader muss ausgeben:

  • Hauptteil auf Chinesisch
  • explizite Ausführungsüberlegungen
  • eine chinesische Schlusszeile mit Kaufen/Halten/Verkaufen-Formulierung
  • eine abschließende englische Ankerzeile in genau diesem Format:

FINAL TRANSACTION PROPOSAL: **BUY/HOLD/SELL**

Der Trader sollte nicht die gesamte vorgelagerte Analyse wiederholen. Er sollte den Investitionsplan in eine ausführbare Handelsansicht umwandeln.

Der Output des Traders ist nur eine ausführungsschichtbezogene Beratung. Der Trader sollte die Bewertung als Ausführungsbeschränkung behandeln, nicht als Ersatz für die richtungsweisende Position des Managers.

6. Durchführung der Risikodebatte

Erstellen Sie einen Risikokontext aus:

  • Trader-Vorschlag
  • vier Analystenberichte
  • Research-Manager-Plan
  • risk_packet

Führen Sie die Risikorollen in diesem festgelegten Zyklus aus:

  1. Aggressiver Risikoanalyst
  2. Konservativer Risikoanalyst
  3. Neutraler Risikoanalyst

Wiederholen Sie diesen vollständigen Zyklus genau 5 Mal.

Regeln:

  • aggressiv argumentiert für Aufwärtspotenzial und Opportunitätskosten
  • konservativ argumentiert für Absicherung nach unten und Kapitalerhalt
  • neutral hinterfragt beide Extreme und schlägt ausgewogene Anpassungen vor
  • jeder Zug muss auf die vorherigen Positionen eingehen, nicht nur eine statische Ansicht wiederholen

Speichern Sie das vollständige Risiko-Transkript auf der Festplatte, geben Sie aber standardmäßig ein komprimiertes final_decision_packet nachgelagert weiter, es sei denn, ungelöste Streitigkeiten erfordern eine Überprüfung des rohen Transkripts.

Verwenden Sie dieselben drei Risikorollen-Agenten über alle Zyklen hinweg wieder, anstatt jeden Zyklus neue zu erstellen.

7. Portfoliomanager erstellt eine abschließende Bewertung

Der Portfoliomanager erhält das komprimierte final_decision_packet und darf das vollständige Risikodebatten-Transkript nur einsehen, wenn ungelöste Streitigkeiten dies erfordern.

Der Portfoliomanager muss genau eine abschließende Bewertung erstellen:

  • Kaufen
  • Übergewichten
  • Halten
  • Untergewichten
  • Verkaufen

Die Bewertung muss enthalten:

  • primäre Schlussfolgerung auf Chinesisch
  • eine einzelne englische Ankerzeile in genau diesem Format:

FINAL RATING: **BUY | OVERWEIGHT | HOLD | UNDERWEIGHT | SELL**

Die englische Ankerzeile muss in Großbuchstaben sein und das Pipe-Symbol zwischen den Optionen darf nur die ausgewählte Option anzeigen, z. B. **BUY**.

Der Portfoliomanager muss außerdem eine Ausführungszusammenfassung bereitstellen, die Folgendes enthält:

  • wichtigste Katalysatoren oder Risiken für den Preis
  • Positionsgrößen- oder Timing-Richtlinien (qualitativ)
  • Bedingungen, die eine Neubewertung auslösen würden

Die Ausführungszusammenfassung sollte Präzision anstreben. Vermeiden Sie vage Formulierungen wie „Marktstimmung überwachen“, wenn es keine umsetzbare Schwelle gibt.

8. Ausgabe des endgültigen Pakets

Das endgültige Paket muss enthalten:

  • 1_analysts/ – vier getrennte Analystenberichte
  • 2_research/ – Debatten-Transkript und Investitionsplan
  • 3_trading/ – Transaktionsvorschlag des Traders
  • 4_risk/ – Risikodebatten-Transkript
  • 5_portfolio/ – Portfolio-Manager-Bewertung
  • complete_report.md – Alle vorherigen Stufen in einer einzigen lesbaren Datei, mit Zwischenüberschriften für jede Stufe und am Ende eine einzige Schlussfolgerung mit der englischen Ankerzeile

Empfohlene Werkzeuge

  • Bash oder Terminal zum Erstellen von Verzeichnissen, Schreiben von Dateien und ggf. Ausführen von Benutzerbefehlen
  • Edit oder Datei schreiben, um die Ausgabe in das Dateisystem zu schreiben
  • Lesen / Datei lesen, um references/handoff-schema.md und references/output-contract.md zu laden

Wichtige Hinweise

  • Der Koordinator muss die Kontrolle über den Workflow behalten, einschließlich Reihenfolge, Paketerstellung und Validierung. Lassen Sie nicht zu, dass Rollen ohne Aufsicht in nicht autorisierte Bereiche abweichen.
  • Jeder Unteragent muss die Aufforderungen des Koordinators akzeptieren und pünktlich einen strukturierten Output zurückgeben. Wenn ein Unteragent nicht antwortet oder die falsche Ausgabe erzeugt, melden Sie sich dem Koordinator, versuchen Sie es ein einziges Mal erneut und brechen Sie dann ab.
  • Wenn Sie gpt-5.4 nicht über die Tool-API zur Verfügung haben oder das bevorzugte Modell nicht startet, wechseln Sie zum nächstbesten verfügbaren Modell, das spezialisierte Extraktion, Debatte und Synthese unterstützt. Stufen Sie nicht auf ein Modell unter o3 herunter, es sei denn, dies ist erforderlich.
  • Das endgültige Paket muss auf der Festplatte persistiert werden, damit der Benutzer es später überprüfen kann. Eine Bildschirmausgabe allein reicht nicht aus.

Verwandte Skills