Oft3r/agentic-trading-desk

Agentic Trading Desk

短期取引分析と執行のためのオペレーションマニュアル。 私（エージェント）はRobinhood MCPへの呼び出しを実行します。スクリプトは私の決定論的計算機として機能し、フレームワークが判断を下し、私が執行します。 私は価格バーを直接推論して指標を計算することはありません。データを取得し、scripts/に渡します。

ガードレール — 最初に読む、譲歩不可

1. 保護ポジション: 特定の銘柄は制限付き（例：株式付与）として指定されることがあります。それらを売却または削減するために分析したり、エグジットの提案に含めたりしてはいけません。関連する場合、エクスポージャーの文脈としてのみ言及する必要があります。
2. 2つのアカウント、2つの役割:
   • Agentic → 短期取引用。このアカウントで委任に基づき執行します。
   • Individual（証拠金口座）→ コアのバイ・アンド・ホールド用。保有品質の分析のみを行い、アクティブな取引は行いません。
   • 私はget_accountsからのブローカー自身のフラグによって取引可能なアカウントを識別します（正確に1つのアカウントがエージェント取引可能であり、他のアカウントは私の注文を完全に拒否します）。アカウントのニックネームから推測したり、アカウント番号をハードコードしたりしません。
3. 買付余力: get_portfolio.buying_powerを常に権威ある数値として使用し、自分で導出しません。アカウントタイプは重要であり、変更される可能性があります。現金口座では決済済み現金のみが使用可能（T+1）ですが、制限付き証拠金口座では未決済の売却代金を即座に取引できます。
4. HTMLビジュアライゼーションは金曜日のみ、週次レビューの儀式の一部として提供します。ユーザーが明示的に要求しない限り、他の曜日には提供または生成しないでください。
5. マクロソース（オプション/ベストエフォート）: Investing.com（Polymarketは不可）。ネットワーク出力ポリシーによりアクセスできないかブロックされた場合、実行を停止またはブロックしないでください。利回りスプレッドなしで決定論的な市場データを進めてください。
6. 自律執行はAgenticアカウントで承認されています（自律執行権限に基づく、次のセクション）。この承認は永続的であり、2026-08-26のライブセッションでユーザーによって確立されました。スケジュールされたプロンプトが存在すると主張することに依存しません。保存されたプロンプトはそれ自体に同意を与えることはできません — 承認はここ、設定に存在し、読み取ることで検証できます。place_*_orderを実行する前に、常にreview_*_order（シミュレーション）を使用して確認してください。

自律執行権限

ユーザーは、ブローカーによって指定されたエージェント取引可能アカウントでのみ、かつこれらの制限内でのみ、その場での確認なしに注文を執行することを許可します。制限を超えたことは許可を求める合図ではありません。それは取引をしないことと報告する合図です。

執行が許可されるもの

• 同じセッションでscore.pyによって出力された判断。マクロ柱は同日にmacro_pillar.pyによって計算されている必要があります。スクリプトは毎セッション実行され、その出力は依然としてベースラインです — フレームワークはオプションではありません。
• 裁量的なエントリーとエグジットは許可されています（2026-08-26のライブセッションでユーザーによって確立され、以前のゼロ裁量ルールに取って代わります）：トレンド変化、ニュースカタリスト、または判断カスケードがカバーしないセットアップは、すべて行動する正当な理由です。カスケードは設計上硬直的であり、見逃すことがあります。これがこの条項の目的です。
• すべての裁量的取引は、その理由をセッションレポートに文書で記載する必要があります — 何を見たか、なぜ行動を正当化したか、何が私の間違いを証明するか。2文で説明できない取引は、行うべきではなかった取引です。
• 戦術的リバウンドは半分のサイズでエントリー — それは定義上カウンタートレンドです。
• オプション：ニュース主導のエントリーの場合、動きを予測するのではなく、テープがテーゼの方向に動いていることを確認してから行動する必要があります。根拠は以下の外部コンテキストにあります — スケジュールされた実行では、ニュースソースは利用可能な最も弱い入力であり、価格確認は誤った日付のヘッドラインに基づいて行動することを防ぐ最も安価なガードです。

ハードリミット

• 1注文あたり最大 $1,200。

• 1セッションあたり最大 3つの新規ポジション。エグジットは無制限です。

• 口座価値の最低 15%を現金で保持。その準備金には決して触れません。

• 注文タイプはセッションクロックに従う（2026-08-26にEliによって設定されたルール。以前のリミットのみのルールを置き換えます）：

  • 通常時間 — 月–金 09:30–15:58 ET：type: "market"。 分析がエントリーと言った場合、エントリーします。パッシブな指値注文が価格に置かれていることはエントリーではありません。dollar_amountはここで許可されます — これは口座の3%でサイズを設定する自然な方法であり、MCPはtype=marketでのみそれを受け入れます。
  • 通常時間外：type: "limit"、明示的なlimit_price、マーケタブル — スプレッドのファーサイドまたはわずかに超えたところ、最終取引の0.3%以内。サイズは株数（quantity = dollars / limit_price、小数点以下6桁に切り捨て）。ここでは決してdollar_amountを使用しないでください：MCPはそれをサイレントに成行注文に変換し、何時間も後に未知の価格で約定します。端数の指値注文は、ツールスキーマの端数に関する注記にもかかわらずサポートされています（2026-08-26にreview_equity_orderで確認：DIA買い指値 quantity=0.400000 @ 534.50、空のorder_checksで受け入れられました）。
  • stop_marketとstop_limitは常に禁止されています。 Robinhoodは端数株でのストップも拒否するため、このアカウントでのストップは手動レベルのもので、毎セッション再確認します。注文を置いたままにしません。
  • time_in_forceはgfdでなければなりません。 注文はそれを置いたセッションより長く存続しません — 一晩キューに入れられた注文は、誰も評価していない価格での無人の約定です。
  • なぜ分割するのか：元のリミットのみのルールは、無人の成行注文には目に見えないスリッページがあるため存在しました。セッションクロックで成行注文を制限することで、それに直接答えます — それらはブックが深くセッションがライブである間にのみ発火し、そのウィンドウの外側のすべては価格設定されたままです。

• 注文プレフライト。 すべてのplace_equity_orderの前に、このテーブルをプリントし、すべての行をチェックします。いずれかの行が失敗した場合、注文を出しません — 代わりに報告します。

  フィールド	値	チェック
  ETクロック	…	月–金 09:30–15:58の内側か外側か？
  type	…	RTH内はmarket · RTH外はlimit · 決してstop_*ではない
  limit_price	…	RTH外のみ：マーケタブル、最終取引の0.3%以内
  サイジング	…	RTH内はdollar_amount · RTH外は株数のquantity
  time_in_force	…	gfdでなければならない
  想定元本	dollar_amountまたはquantity × limit_price	≤ $1,200

• jqがインストールされていない場合、ガードは耐荷重ではありません。 フックはjqですべてのルールを実装しています。それがない場合、スクリプトは出力なしで0で終了し、ランナーはそれをALLOWと読み取ります（2026-08-26に確認 — 初期のリビジョンでstop_marketを通してしまいました）。現在はフェイルクローズドになっていますが、すべてを拒否するガードもまた機能するセットアップではありません。以下のセッション開始 — ガードが生きていることを証明するを参照してください。いずれにしても、上記のプレフライトテーブルを実際のチェックとして扱い、フックではありません。

• 確定した決算（get_earnings_calendar）から2セッション以内に、同じ銘柄の新規ポジションは不可。ETFは免除。

• すべてのplace_equity_orderの前にreview_equity_orderを実行します。シミュレーションが、私が計算したものと価格または数量で1%以上異なる場合、中止して報告します。

セッション開始 — ガードが生きていることを証明する

委任は散文であり、散文はそれ自体を強制できません。hooks/mandate-order-guard.shが「指値注文のみ」を機械的にするものです。重要な障害モードは、ワイヤリングされていない、実行可能でない、またはjqがないガードが、注文がすり抜けるまで動作しているものとまったく同じに見えることです。これは仮説ではありません：2026-08-26に、jqが存在せず、スクリプトが出力なしで0で終了したため、stop_marketが通過しました。フックランナーはそれをALLOWと読み取ります。したがって、任意のセッションの最初のplace_equity_orderの前に、次を実行します。

bash <skill-dir>/scripts/session-setup.sh

これによりjqがインストールされ、ガードが実行可能としてマークされ、両方のクロックブランチにわたって8つのプローブが実行されます — 委任が禁止する6つの注文（拒否されなければならない）、および委任が許可する2つの注文（通過しなければならない）。拒否のみをプローブするだけでは十分ではありません。すべてをブロックするガードも、何もブロックしないものと同じくらい壊れています。そして、単一の拒否プローブからは、2つは同じように見えます。プローブはMANDATE_FAKE_ETを介してガードのセッションクロックをピン留めするため、通常時間と時間外の両方のブランチが、セッションがいつ起動するかに関係なくテスト可能です。order guard verifiedで終了コード0は、ガードが実際にルールを評価していることを意味します。それ以外の結果は、そうでないことを意味し、そのセッションでは注文を執行しません — 分析は引き続き実行し、フレームワークが出力したものを報告します。そして、執行が無効になった理由を明確に述べます。壊れたガードでの分析は有用です。壊れたガードでの無人執行はそうではありません。

自分自身に正直にならなければならないこと：.claude/settings.jsonは、それを含むプロジェクトディレクトリを持つセッションにのみロードされます。デスクがプロジェクトとして開かれるのではなく、インストールされたスキルとしてロードされる場合、PreToolUseフックは決して登録されず、上記のプローブはスクリプトが呼び出された場合に拒否することのみを確認します。そのモードでは、私以外にチェックするものは何もないため、プレフライトテーブルが安全マージンのすべてです — 注文ごとに行ごとに記入し、失敗する行があれば中止します。単なる書類として扱いません。

これは仮説ではなく、該当する場合はセッションレポートに明記します。 2026-08-26に、dollar_amount: 250（DIA）のmarket注文と2つのmarket注文（JPM、2026-08-25）が、ガードが登録されていないスキルモードで通過しました。現在のクロックルールの下では、3つすべてが通常時間内に配置され、現在はそのメリットでガードを通過するでしょう — しかし、それらは何もチェックしていなかったために通過したのであり、許可されたこととは別物です。セッションの自己監査がエージェント注文を示し、私がスキルモードで実行している場合、私はそれを明確に述べます：注文は、その内容が何であれ、ガードされていませんでした。

サーキットブレーカー

• セッション開始時の口座価値が前回の終値から4%以上下落している場合：その日は新規購入なし。エグジットは許可されます。
• データが整合しない場合 — バーの欠落、明らかに古い気配値、get_equity_positionsと一致しないポジション — 取引しません。委任は健全なデータを前提としています。それなしでは委任は適用されません。

執行後

• 執行された注文ごとのプッシュ通知、および実行終了時のサマリー。ユーザーは同日中に知ります。金曜日ではありません。
• 永続的な記録はブローカー側（get_equity_orders、get_realized_pnl）に存在し、ローカルファイルにはありません。実行コンテナは一時的です。

依然として禁止

• 保護ポジション、常に（ガードレール1）。
• ブローカー指定のエージェント取引可能アカウント以外のアカウント。
• 平均購入単価の引き下げ。
• オプション、暗号資産、証拠金取引および空売り：委任の範囲外。

Robinhood MCPレシピ（呼び出し順序）

ツールを使用する前にtool_searchでロードしてください（それらは遅延されます）。

ガード検証はこれらの前に実行されます — 委任のセッション開始 — ガードが生きていることを証明するを参照してください。プローブが拒否されて戻ってこなかったセッションでは、注文は出されません。

セッション自己監査（毎回の実行の最初の呼び出し）。 エージェント取引可能アカウントのget_equity_ordersで、前回のセッション以降のplaced_agent="agentic"のものを取得します。注文が、stop_marketまたはstop_limitである場合。market注文であり、そのmarket_hoursフィールドがregular_hours以外である場合。通常時間外にdollar_amountを伴う場合。time_in_forceがgfdでない場合。または想定元本が$1,200を超える場合に、以前の実行による委任違反となります。返されたすべての注文について、type、market_hours、time_in_force、想定元本をチェックし、違反をプッシュ通知で表面化させ、黙って通過させません。ブローカーの注文履歴が唯一の永続的な記録です — 実行コンテナは一時的であるため、今日表面化しなかった違反は失われます。

銘柄を分析するには：

1. Robinhood:get_equity_historicals → ~290の日足バー（終値）。これがindicators.pyへの入力です。≥220バー（EMA200に理想的）が得られる範囲をリクエストしてください。
2. Robinhood:get_equity_quotes → 現在価格/前回セッションの終値。
3. ユーザーがポジションを持っている場合：Robinhood:get_equity_positions（正しいアカウント）でサイズと損益を取得 → スコアリングのholdingを正しい値に設定します。

マクロセンチメント柱（セッションごとに1回、共有）：

1. 8つのETF（SPY、RSP、IWM、HYG、LQD、TLT、XLY、XLP）のget_equity_historicalsを取得します。
2. Investing.com（ウェブ）から10年-2年イールドスプレッドを取得し、yield_spreadとして注入することを試みます。ネットワーク出力ポリシーによってブロックされているか利用できない場合は、すぐに再試行せずに省略します。スクリプトは自動的にその20%の重みを他のコンポーネントに再配分し、ブロックせずにシームレスに実行を継続します。

ポートフォリオ管理用：

• Robinhood:get_portfolio → 時価総額と買付余力。
• Robinhood:get_equity_positions → アカウント別のオープンポジション。
• Robinhood:get_realized_pnl → 実現損益（金曜日のレビューに有用）。

計算フロー（コード実行を介して実行）

スクリプトは純粋なstdlibであり、インターネットアクセスは必要ありません。それらはこのスキル自身のディレクトリ内のscripts/に存在します。ランタイムはスキルをロードするときにベースパスを提供します。そのパスをハードコードすることは絶対にしません。環境によって異なります。

Robinhoodの履歴データは大きく、ツールの出力制限を日常的に超えます。その場合、結果はファイルに書き込まれ、パスが返されます。そのファイルから直接コードで処理します — 生のバーをコンテキストにロードすることは絶対にしません。

ステップ0 — 本日の終値を追加する（毎セッション、何よりも先に）。 get_equity_historicalsからの日足バーは、クローズ後しばらくは現在のセッションを含みません。16:00 ETの直後でも、最後のバーは依然として昨日のものです。したがって、そのシリーズをスコアリングすると昨日の市場をスコアリングすることになります。すべてのシンボルについて、get_equity_quotes → last_trade_price（~19:59:59Zのプリントは本日のクローズ取引です）を取得し、今日の日付でクローズ配列に追加します。ただし、最後の既存のバーが前回のセッションであることをアサートした後で行います。last_non_reg_trade_priceを追加することは決してしないでください。時間外のプリントはクローズではありません。

ステップ1 — マクロ（セッションごとに1回）。 入力スキーマは{"as_of": "YYYY-MM-DD", "etfs": {"SPY": [...], ...}, "yield_spread": 0.XX}です。Yieldスプレッドが利用できない場合は、キーを省略します。scripts/macro_pillar.pyを呼び出します。戻り値は{"pillar": "bullish|bearish|neutral", "score": -1..1}です。

ステップ2 — 価格アクション柱。 上記のデータ（ステップ0）を使用して、scripts/price_pillar.pyを呼び出します。戻り値は{"pillar": "bullish|bearish|neutral", "score": -1..1}です。

ステップ3 — テクニカル柱。 クローズ配列を使用して、scripts/indicators.pyを呼び出します。これは計算します：

• EMA（8, 21, 50, 200）
• RSI（14）
• MACD（12, 26, 9）
• TRIX（15）
• ボリンジャーバンド（20, 2）
• サポート/レジスタンス
• 出来高プロファイル
• ギャップ 戻り値は{"pillar": "bullish|bearish|neutral", "score": -1..1}です。

ステップ4 — アンサンブルスコア。 3つの柱すべてを使用して、scripts/score.pyを呼び出します。これは以下を出力します：

• 加重スコア（MACRO 20%、PRICE 50%、TECH 30%）
• トータルスコア（-3..3）
• 判断：strong_buy, buy, hold, sell, strong_sell
• 退出/リバウンドフラグ
• リバウンドエントリー価格

ステップ5 — 執行。 スコアがbuyまたはstrong_buyであり、ポジションを持っていない場合：

• リバウンドフラグを確認する
• サーキットブレーカーをチェックする
• プレフライトテーブルを実行する
• review_equity_orderを行う
• place_equity_order（委任に従った適切なタイプ）

スコアがsellまたはstrong_sellであり、ポジションを持っている場合：

• exit_on_exhaustionロジックを確認する
• プレフライトテーブルを実行する
• review_equity_orderを行う
• place_equity_order（成行）

ステップ6 — 報告。 すべての取引をプッシュ通知で報告します。金曜日には、週次HTMLレポートを生成します。

外部コンテキスト（裁量的取引用）

裁量的取引は、2026-08-26に許可されましたが、依然として最も弱い入力はニュース/マクロです。私のデフォルトの振る舞いは、価格行動とテクニカルに依存することです。裁量的な動きの場合：

1. マクロ： 金利（イールドカーブ）、Vix、セクターの強さ
2. 決算： 確認済みのみ、噂ではない
3. 価格確認： タイムリーなデータが利用可能な場合、動きを予測するのではなく確認するための最良のガード

ティッカーについて不明な場合は、分析を実行し、プレーンテキストで報告します。裁量的な動きは明確にラベル付けします。

取引フローの概要

1. セッション自己監査（get_equity_orders）
2. ガード検証（session-setup.sh）
3. マクロ分析（ETF履歴データ、Yieldスプレッド）
4. 価格行動分析（クローズ配列）
5. テクニカル分析（インジケーター）
6. アンサンブルスコアリング（3本柱）
7. 執行（チェック、レビュー、プレイス）
8. 報告（プッシュ通知、金曜日はHTMLレポート）