GrantDeng/trading-analysis-skill

TradingAgents ロールシミュレーター

ユーザーがTradingAgentsのワークフロー自体をシミュレートしたい場合にこのスキルを使用します。コードベースを説明するだけではありません。このスキルは、サブエージェントとコーディネーターを使用して、リポジトリの安定したビジネスプロトコルを再現します。

• 4人のアナリストが専門家レポートを作成します
• 強気と弱気の研究者が固定最大深度のシーケンスで討論します
• リサーチマネージャーが投資計画を作成します
• トレーダーがその計画を取引提案に変換します
• アグレッシブ、コンサバティブ、ニュートラルのリスクロールが固定最大深度のシーケンスで討論します
• ポートフォリオマネージャーが最終的な評価と実行サマリーを1つ作成します

メインパスとしてTradingAgentsGraphやCLIを呼び出さないでください。このスキルのポイントは、LangGraphランタイムではなく、サブエージェントでロールプロトコルを再現することです。

このスキルを使用する場合

• 「TradingAgentsのロールをシミュレートして」というリクエスト
• 特定のティッカーと日付に対してTradingAgentsスタイルのレポートを生成するリクエスト
• サブエージェントを使用してリポジトリの分析チェーンを再現するリクエスト
• 異なるロールが最終決定にどのように貢献するかを比較または監査するリクエスト

このスキルは使用しないでください。

• レポート生成を伴わない単純なコードベースのウォークスルー
• リポジトリパイプラインをエンドツーエンドで実行することを明示的に要求するリクエスト

必須入力

サブエージェントを生成する前に、これらの入力を収集または推測します。

• ticker
• analysis_date：ユーザーが指定しない場合は、現在のローカル日付をデフォルトとします
• language：デフォルトはzh-CN
• output_root：デフォルトは現在のワークスペースのreports/ディレクトリ

.HK、.TO、.T、.Lなどの取引所サフィックスを含め、すべての場所でティッカーをそのまま保持します。

コーディネーターは、このスキルのために構成可能な深度やデータモードスイッチを公開してはなりません。このスキルは常に以下で実行されます。

• 最大深度のリサーチ討論
• 最大深度のリスク討論
• 最新のライブエビデンスのみ

最大深度のセマンティクスは固定されており、推測したり短縮したりしてはなりません。

• リサーチ討論：強気の開始ターンの後、ちょうど5回の強気/弱気の交換。5ラウンドが完了するまで、各サイドで1ターンずつ交互に行います
• リスク討論：Aggressive -> Conservative -> Neutralのちょうど5回の完全なサイクル

出力の永続化

ユーザーが明示的に別の保存先を要求しない限り、最終結果パッケージを現在のワークスペースのreports/ディレクトリの下に永続化します。

デフォルトのディレクトリ命名：

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

同じティッカーと日付での繰り返し実行間の衝突を避けるために、タイムスタンプを追加する必要があります。

推奨されるタイムスタンプ形式：

• YYYYMMDD_HHMMSS

推奨されるパッケージ構造：

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

コーディネーターは以下を両方書き込む必要があります。

• 監査可能性のためのステージレベルのファイル
• 人間によるレビューのための1つのマージされたcomplete_report.md

モデル選択ポリシー

すべてのロールを同じモデルにデフォルト設定しないでください。ロールに適したモデル階層を使用します。

推奨されるデフォルト：

• アナリストロール（Market、Social Sentiment、News、Fundamentals）：gpt-5.4、medium推論
• 討論ロール（Bull、Bear、Aggressive、Conservative、Neutral）：gpt-5.4、medium推論
• 統合ロール（Research Manager、Trader、Portfolio Manager）：gpt-5.4、mediumまたはhigh推論

タスクが必要とする場合にのみエスカレーションします。

• エビデンスが非常に矛盾している場合、またはユーザーが最大限の厳密さを明示的に望む場合、Research Manager、Trader、またはPortfolio Managerにgpt-5.4、high推論を使用します
• このスキルでは、ロールサブエージェントにminiモデルを使用しないでください

コーディネーターは、ロールエージェント間で一貫したgpt-5.4の使用を好むべきであり、専門家の抽出、討論、および統合が同じ推論フロアを共有するようにします。

ワークフロー

1. 中央エビデンスパケットを準備する

コーディネーターはエビデンスを一度収集し、同じパケットをロールサブエージェントに配布します。各ロールがデータセット全体を独立して再発見することを許可しないでください。タスクが明示的にそれを要求する場合を除きます。

コーディネーターは最新のライブエビデンスのみを使用する必要があります。過去のアーティファクトやユーザー提供の資料は、二次的な検証コンテキストとしてのみ使用できます。主要なランタイムエビデンスソースとして使用することはできません。

この優先順位で「最新」を定義します。

1. 利用可能な最新の一次ソース財務開示
2. 利用可能な最新の企業発信イベント開示
3. 利用可能な最新の信頼できるニュースとマクロコンテキスト
4. 利用可能な最新の市場またはテクニカルコンテキスト

すべてのエビデンス項目は以下を保持する必要があります。

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

このソース優先順位を使用します。

• 財務：企業IR、SECファイリング、取引所ファイリング
• 企業イベント：企業IR、公式リリース
• ニュースとマクロ：一次ニュースアウトレット
• 市場とテクニカルコンテキスト：一次取引所スタイルのデータが利用できない場合にのみ、サードパーティのアグリゲーター

エビデンスパケットには以下を含める必要があります。

• インストゥルメントブロック：正確なティッカー、分析日、既知の市場/取引所
• 市場ブロック：価格アクションとテクニカル指標のサマリー
• センチメントブロック：企業固有のセンチメントとディスカッションのサマリー
• ニュースブロック：企業ニュースとマクロ/グローバルニュースのサマリー
• ファンダメンタルブロック：財務プロファイル、主要指標、およびステートメントのハイライト
• バリュエーションブロック：最小バリュエーションアンカー、履歴コンテキスト、および感応度ノート
• ソースブロック：エビデンスの出典とその鮮度

エビデンスが下流に渡される前に、主要な数値項目を正規化します。

• 元の通貨と単位を保持します
• 比較のために、コーディネーター側の正規化された通貨と単位を1つ定義します
• quarter、FY、TTM、YoY、またはQoQなどの期間タイプを明示的にラベル付けします
• 期間タイプが明示的でない限り、期間間でメトリクスを比較しないでください
• 元の数値と正規化された数値を1つのラベルのない値にまとめないでください

サブエージェントが生成される前に、エビデンス検証パスを実行し、各項目を次のように分類します。

• trusted：内部的に一貫性があり、日付がスタンプされ、もっともらしいソースがある
• questionable：数値、日付、単位、またはソース品質が弱いため、注意して使用可能
• conflicted：別の項目と実質的に矛盾している、または事実として下流に渡すのが安全でない

また、短い検証サマリーを生成します。

• 古いまたは混合日付の項目
• 単位の不一致
• 異なる数値を持つ重複した主張
• HOLD-1などの不正なアクションラベル

また、ロールが生成される前にconflict_resolution_summaryを生成します。

• 争点となっているメトリクスまたは主張
• 候補値
• 選択された値、または選択されなかった決定
• その処理方法が選択された理由
• 問題が下流で未解決のままかどうか

混合日付のエビデンスは、次の場合にのみ許可されます。

• 各項目に明示的に日付がスタンプされている
• 各項目が明示的にtrustedまたはquestionableとラベル付けされている
• 混合日付の項目が、あたかも同日のスナップショットであるかのように下流に提示されていない

サードパーティの市場またはテクニカルデータは、一次取引所スタイルのデータが利用できない場合は常にquestionableとラベル付けする必要があります。

エビデンスの重み付けは、以下を両方使用する必要があります。

• source_quality_score
• freshness_score

コーディネーターのガイダンス：

• 企業の事実については、高品質だがやや古い一次ソースエビデンスは、新しい低品質のアグリゲーターエビデンスよりも優先されます
• 低品質だが新しい市場コンテキストは、タイミングの議論にのみ使用できます
• 下流のロールは、複合的な重みが高いエビデンスを優先し、スコアの低いエビデンスを明示的に低重み付けする必要があります

より新しいまたはより高品質のファンダメンタルエビデンスが存在する場合、テクニカルまたはセンチメントのプロキシが企業品質の判断を支配することを許可しないでください。

conflictedアイテムを、あたかも事実であるかのように下流のロールプロンプトに渡さないでください。削除するか、争点として明示的にラベル付けします。

最新のライブエビデンスを取得できない場合、実質的に矛盾している場合、または鮮度を検証できない場合は、ロールエージェントを生成する前に停止し、ユーザーにどのように進めるかを尋ねます。アーティファクトモードまたはユーザー提供モードに静かにダウングレードしないでください。

ロール実行前の最小エビデンスしきい値：

• 最新の一次財務開示を検証できない場合は、停止します
• 信頼できる企業またはニュースソースが最新の企業イベントコンテキストをサポートできない場合は、信頼度をダウングレードし、ニュースロールをエビデンスが薄いと明示的にマークします
• 信頼できる市場コンテキストソースが利用できない場合は、市場ロールがレジームと不確実性についてのみ議論することを許可し、正確な同日のテクニカル結論は許可しません
• ソーシャルセンチメントのエビデンスが薄い場合は、ソーシャルロールが公開ディスカッションプロキシを使用することを許可しますが、信頼度が低下したことを明示的に述べる必要があります

エビデンスパケットは、1つの未分化なテキストの壁としてではなく、構造化された形式で引き渡される必要があります。これらのコーディネーター側パケットを維持します。

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

各パケットは、これらの必須キーを保持する必要があります。

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

このオプションのキーも保持される場合があります。

• full_text

デフォルトの下流への引き渡しはsummary + evidence_tableです。full_textは監査可能性のために保持され、争いが未解決の場合、またはステージが生のトランスクリプトを明示的に必要とする場合にのみ、下流に渡されるべきです。

これらのパケットを構築する前に、references/handoff-schema.mdをロードします。

2. アナリストステージを並行して実行する

4つの独立したサブエージェントを並行して生成します。

• マーケットアナリスト
• ソーシャルセンチメントアナリスト
• ニュースアナリスト
• ファンダメンタルズアナリスト

各アナリストは以下を受け取ります。

• 共有のanalyst_packet
• conflict_resolution_packet
• 自身のロール目標
• references/output-contract.mdからの出力契約

各アナリストは、以下を含む中国語のMarkdownレポートを返す必要があります。

• 明確な結論
• エビデンス
• 推論チェーン
• 主要なリスク
• 後のロールへの下流への影響

アナリストステージの出力は、ロールごとに分離されたままにする必要があります。1つのブレンドされたサマリーにまとめないでください。

3. 強気/弱気討論を実行する

4つのアナリストレポートとdebate_packetから討論コンテキストを作成します。次に、この正確な順序でサブエージェントのターンを交互に実行します。

1. 強気研究者の開始ターン
2. 弱気研究者の応答
3. 強気研究者の応答
4. 弱気研究者の応答
5. 強気研究者の応答
6. 弱気研究者の応答
7. 強気研究者の応答
8. 弱気研究者の応答
9. 強気研究者の応答
10. 弱気研究者の最終応答

このシーケンスは、固定された最大深度のリサーチ討論を構成します。ユーザーがこのスキル外の軽量モードを明示的に要求しない限り、短縮しないでください。

ルール：

• 各サイドは、相手側の前の議論に直接回答する必要があります
• 各サイドは、アナリストレポートまたは討論パケット項目からのエビデンスを引用する必要があり、サポートされていない事実をでっち上げてはいけません
• 討論の出力は、会話的で敵対的なままにする必要があり、中立的なサマリーになってはいけません
• 各サイドは、コーディネーターのconflict_resolution_summaryを尊重する必要があり、拒否された値をあたかも受け入れられた事実であるかのように復活させてはいけません

最終ラウンド後：

• 完全な討論トランスクリプトをディスクに永続化します
• 討論をinvestment_plan_packetに圧縮します
• 圧縮されたパケットと未解決の争いメモをリサーチマネージャーに送信します

毎ラウンド新しい強気/弱気エージェントを再生成しないでください。フォローアップ入力で同じロールエージェントを再利用し、討論が首尾一貫し、スレッド使用量が制限されたままになるようにします。

4. リサーチマネージャーが投資計画を作成する

リサーチマネージャーは以下を行う必要があります。

• 最も強い強気と弱気のポイントを要約します
• 明確なスタンスを選択します
• 中国語のinvestment_planを書きます
• 根拠、リスク、およびトレーダーのための具体的なアクションを含めます
• エビデンスパケットに関連付けられた最小バリュエーションビューを含めます

マネージャーがあいまいなままにすることを許可しないでください。方向性のある推奨にコミットする必要があります。

マネージャーは、デフォルトで圧縮されたinvestment_plan_packetを消費する必要があります。未解決の争いが直接の検査を必要とする場合を除き、生の討論トランスクリプトは消費しません。

最小バリュエーションビューとは、以下を意味します。

• 利用可能な場合は、現在のバリュエーションアンカーまたは市場が暗示するレベル
• それが企業の現在の収益性の可視性とどのように比較されるか
• レーティングの上方または下方修正を正当化するもの

5. トレーダーが取引提案を作成する

トレーダーは以下を受け取ります。

• investment_plan
• 4つのアナリストレポート
• 以前のステージから派生した圧縮されたtrader_packet

トレーダーは以下を出力する必要があります。

• 中国語の本文
• 明示的な実行に関する考慮事項
• buy/hold/sellの文言を含む1つの中国語の結論行
• 次の正確な形式の1つの英語のアンカー行：

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

トレーダーは、上流の分析全体をやり直すべきではありません。投資計画を実行可能な取引ビューに変換する必要があります。

トレーダーの出力は、実行レイヤーのアドバイスにすぎません。 トレーダーは、バリュエーションをマネージャーの方向性スタンスの代わりとしてではなく、実行制約として扱う必要があります。

6. リスク討論を実行する

以下からリスクコンテキストを作成します。

• トレーダー提案
• 4つのアナリストレポート
• リサーチマネージャープラン
• risk_packet

この固定サイクルでリスクロールを実行します。

1. アグレッシブリスクアナリスト
2. コンサバティブリスクアナリスト
3. ニュートラルリスクアナリスト

その完全なサイクルを正確に5回繰り返します。

ルール：

• アグレッシブは、アップサイドと機会費用を主張します
• コンサバティブは、ダウンサイドコントロールと資本保全を主張します
• ニュートラルは、両方の極端に挑戦し、バランスの取れた調整を提案します
• 各ターンは、以前のポジションに回答する必要があり、単に静的な見解を再述するのではありません

完全なリスクトランスクリプトをディスクに永続化しますが、デフォルトでは圧縮されたfinal_decision_packetを下流に渡します。未解決の争いが生のトランスクリプトレビューを必要とする場合を除きます。

各サイクルで新しいリスクロールエージェントを作成する代わりに、すべてのサイクルで同じ3つのリスクロールエージェントを再利用します。

7. ポートフォリオマネージャーが1つの最終評価を発行する

ポートフォリオマネージャーは、圧縮されたfinal_decision_packetを受け取り、未解決の争いが必要とする場合にのみ、完全なリスク討論トランスクリプトを検査できます。

ポートフォリオマネージャーは、正確に1つの最終評価を生成する必要があります。

• Buy
• Overweight
• Hold
• Underweig

…

[翻訳のため一部省略]