bhardwajaditya/trader-in-broker

trader-in-broker は何をしますか？

Order Executorは、このパックの中で実際の注文につながる可能性がある唯一のスキルであるため、最も厳格です。注文が市場に届くのは、毎回、すべての注文に対して、以下のゲートを通過した場合のみです。

1. trader-in-riskが本日、この正確な注文を承認した（フィンガープリントで照合。trader-in-risk/check.pyと同じORDER_FIELDSとハッシュ）。
2. trader-in/config.jsonで"paper": false。ペーパーモード（デフォルト）では何も送信されず、約定はローカルのシミュレーション元帳に記録されます。
3. ユーザーがチャットでこの注文に対して明示的な承諾を入力した。
4. ユーザーがClaudeの許可カードで「Allow once」をクリックした（place_order呼び出しごとに）。これは、注文ツールが「承認が必要」に設定されているためです。

承諾がなければ、注文は発行されません。承諾は1つのチケット（その買い注文、およびストップ注文とターゲット注文のレッグ）をカバーし、バッチでは扱いません。

${CLAUDE_SKILL_DIR} はこのスキルのフォルダ（このSKILL.mdがある場所）です。

python3 "${CLAUDE_SKILL_DIR}/ticket.py" show                      # すべてのチケットを表示（READYかどうかに関わらず）
python3 "${CLAUDE_SKILL_DIR}/ticket.py" approve --index 1 --reply "yes"
python3 "${CLAUDE_SKILL_DIR}/ticket.py" paper-fill --index 1 --price 1196.30           # ペーパーモード：買い
python3 "${CLAUDE_SKILL_DIR}/ticket.py" paper-fill --symbol RELIANCE --side sell --qty 12 --price 1212.70 --leg target
python3 "${CLAUDE_SKILL_DIR}/ticket.py" paper                     # ペーパー元帳と損益を表示
python3 "${CLAUDE_SKILL_DIR}/ticket.py" result --index 1 --leg entry --status placed --broker-id ID --filled-qty 12 --filled-price 1196.30
python3 "${CLAUDE_SKILL_DIR}/ticket.py" result --index 1 --leg stop --status placed --broker-id ID
python3 "${CLAUDE_SKILL_DIR}/ticket.py" fill --symbol RELIANCE --side sell --qty 12 --price 1212.70 --leg target
python3 "${CLAUDE_SKILL_DIR}/ticket.py" flatten --symbol RELIANCE --qty 12
python3 "${CLAUDE_SKILL_DIR}/ticket.py" log

ticket.pyはブローカーと通信しません。チケットをレンダリングし、返信がその注文に対する実際の承諾であるかどうかを確認し、ペーパー元帳を管理し、フラットンチケットを作成し、ログをtrader-in/state/broker.jsonに保持します。--now "2026-10-27 10:15"（または単に10:15）でISTの時刻を固定できます。シンボルはRELIANCE、RELIANCE.NS、NSE:RELIANCE、M&M、BSE:500325、500325.BOとして受け入れられます。

読み取りと書き込みの対象

ファイル	内容
trader-in/orders.json	提案された注文（trader-in-budgetが書き込み、flattenが置き換えます）
trader-in/config.json	broker（kiteまたはupstox）、paper、product、flat_by、costs、capital_inr
trader-in/state/risk.json	trader-in-riskの判定結果。本日のPASSのみがREADY
trader-in/state/broker.json	すべての承諾、拒否、発注、レッグ発注および約定。各エントリの最大損失（コスト込み）を含む
trader-in/state/paper.json	ペーパー元帳：現金、オープンポジション、クローズドトレード、推定コスト控除後の実現損益
trader-in/portfolio.json	現金と株式（ポジションはRELIANCE.NSのようなsymbolでキー付けされ、exchangeを含む）
trader-in/plan.json	flattenのためのフラットバイ時間
trader-in/universe.json	（Upstox用）スキャナーからのISIN（存在する場合）
trader-in/state/EQUITY_L.csv	（Upstox用）NSEの株式リスト。ISINが必要なときに一度ダウンロードされます

1トレード、3つの注文（ブレケット注文を読む前に毎回確認）

trader-in-budgetは1つの「ブレケット」（エントリー、ストップ、ターゲット）を書き込みます。ZerodhaとUpstoxはこれに対してブレケット注文を提供しなくなったため、チケットはそれを以下のように変換します。

レッグ	注文	タイミング
1	エントリー価格での買い指値（または成行）、MISまたはCNC	今
2	SL-Mでの売り、trigger_price = ストップ価格	レッグ1が約定した後のみ
3	ターゲット価格での指値売り	レッグ1が約定した後のみ

レッグ2と3はリンクされていません（OCOではありません）。 一方が約定しても、もう一方は有効のままです。すぐにキャンセルしないと、ユーザーが空売り状態になる（MISの場合）か、注文が拒否される（CNCの場合）可能性があります。/trader-in-alertsはストップとターゲットの価格レベルを監視し、いずれかに達したときに警告を発します。レッグ1が約定する前に発注された場合、レッグ2と3は単なる売り注文となり、空売りを開始する可能性があります。

すべてのチケットは、推定コスト（仕様§6：MISのレッグごとの手数料 min(₹20, 0.03%)、STT、取引所手数料、SEBI手数料、印紙税、18% GST）と、ストップ時の最大損失（往復コストを含む） を表示します。同じ数値は、trader-in-riskの日次損失制限のために記録されます。コストは常に推定値です。実際のコストは契約通知書に記載されています。

ペーパートレーディング（デフォルト）

インドのブローカーにはペーパー口座がないため、ペーパートレーディングはtrader-in/state/paper.jsonのローカル元帳で行われます。どこにも送信されません。

1. ticket.py showでREADYなチケットを表示し、ユーザーが承諾し、ticket.py approveを実行します。
2. エントリー価格で取引が成立したら、ticket.py paper-fill --index N（指値価格）または--price Pを実行します。買い指値は、その指値以上では約定しません。
3. ストップまたはターゲットで取引が成立したら、その1つの売りを記録します：paper-fill --symbol RELIANCE --side sell --qty 12 --price 1188.10 --leg stop。元帳は総損益、推定往復コスト、および純損益を記録します。
4. ticket.py paperは現金、オープンポジション、および実現損益を表示します。

ペーパーエントリはplacedとして記録され（"paper": true）、trader-in-riskはそれをライブ取引とまったく同じように、1日あたりのトレード数と日次損失制限に対してカウントします。

セットアップA: Zerodha Kite（公式MCPサーバー）— デフォルト

Zerodhaのサーバーは github.com/zerodha/kite-mcp-server（MITライセンス、Go）です。2026-10-27時点のソースとREADME（最新コミット5e044dc、タグv0.4.0-dev24）で確認済みです。

ホスト型サーバーは注文を発注できません。 READMEには、ホスト型のhttps://mcp.kite.trade/mcpは「セキュリティ上の理由から、破壊的な取引操作を除外している」と記載されており、Zerodha自身のページでは読み取り専用と説明されています（1つのZ-Connectの投稿ではGTT注文が例外であるとされていますが、スコープは時間の経過とともに変更されているため、接続後にClaudeのツールリストで確認してください）。無料でAPIキーは不要です。loginツールはKiteのリンクを返し、ユーザーは自分のKiteパスワードと2FAを使用してブラウザでログインします。チャットでログインすることはありません。

ホスト型、読み取り専用（相場、保有銘柄、ポジション、証拠金、注文、履歴）：

• Claude Desktop: 設定 > 開発者 > 設定を編集 で、claude_desktop_config.example.jsonから"kite"ブロックを追加します（npx mcp-remote https://mcp.kite.trade/mcpを実行します。Node.jsが必要です）。再起動します。
• Claude Code: claude mcp add --transport http kite https://mcp.kite.trade/mcp（または同じnpx mcp-remoteコマンドをstdioサーバーとして：claude mcp add kite -- npx mcp-remote https://mcp.kite.trade/mcp）。

Claudeを介して注文を発注するには、ユーザーは自身のコピーのサーバーを自身のKite Connectアプリで実行する必要があります。

1. developers.kite.tradeでKite Connectアプリを作成します（現在の価格はそこで確認してください）。リダイレクトURLはローカルサーバーのコールバックを指す必要があります。サーバーソースでは、コールバックパスはAPP_HOST:APP_PORT（デフォルトはhttp://localhost:8080/callback）上の/callbackです。このエンドツーエンドのテストは行っていません。
2. 2026年4月1日以降、Zerodhaのサポートページによると、APIによる注文発注にはZerodhaにホワイトリスト登録された静的IPが必要です（NSE/SEBIのリテールアルゴルール）。静的IPのない自宅の接続では、注文が拒否される可能性があります。ライブで使用する前に、Zerodhaの現在のルールを確認してください。
3. ビルド：git clone https://github.com/zerodha/kite-mcp-server && cd kite-mcp-server && go build -o kite-mcp-server（Go 1.21以上）。
4. claude_desktop_config.example.jsonから"kite-orders"ブロックを追加します。バイナリへのフルパス、APP_MODE stdio、そしてユーザーはKITE_API_KEYとKITE_API_SECRETをそのファイル自体に入力します。Claude Codeの場合：claude mcp add kite-orders -e APP_MODE=stdio -e KITE_API_KEY="$KITE_API_KEY" -e KITE_API_SECRET="$KITE_API_SECRET" -- /full/path/to/kite-mcp-server。値は事前にユーザー自身のシェルでエクスポートしておきます。両方が必要でない場合は、kite / kite-ordersのいずれか1つだけを保持します。
5. 再起動し、Claudeにloginを呼び出すよう依頼します。ユーザーはリンクを開いてログインします。Kiteセッションは毎日期限切れになります（Kite Connectアクセストークンは翌朝まで有効）。したがって、毎取引日に再ログインすることを想定してください。

キーとトークンはチャットに入力しないでください。 それらを要求したり、設定ファイルを会話に読み戻したりしないでください。ユーザーがキーやトークンを貼り付けた場合は、そのメッセージを削除し、developers.kite.tradeで再生成するように指示してください。

ツールの権限。 カスタマイズ > コネクタ（Claude Desktop）で、Kiteサーバーを開き、以下を設定します。

• place_order、modify_order、cancel_order、place_gtt_order、modify_gtt_order、delete_gtt_order：承認が必要。常に許可しないでください。
• 読み取り専用ツール（get_profile、get_margins、get_holdings、get_positions、get_orders、get_order_history、get_order_trades、get_trades、get_gtts、get_quotes、get_ltp、get_ohlc、get_historical_data、search_instruments、login）：常に許可で問題ありません。
• Claude Codeでは、.claude/settings.jsonでそれらをaskに保持します："permissions": {"ask": ["mcp__kite-orders__place_order", "mcp__kite-orders__modify_order", "mcp__kite-orders__cancel_order"]}。注文ツールをallowに入れないでください。サーバーは読み取り専用コピーとしてEXCLUDED_TOOLS=place_order,modify_order,cancel_orderも受け入れます。

place_orderの引数（サーバーソースから）：variety（regular）、exchange（NSE/BSE）、tradingsymbol、transaction_type（BUY/SELL）、quantity（整数）、product（MIS/CNC）、order_type（MARKET/LIMIT/SL/SL-M）、price（LIMIT、SL）、trigger_price（SL、SL-M）、validity（DAY）、オプションのtag（≤ 20文字。チケットはtrin + フィンガープリントの16進数12文字を追加して、後で注文を見つけられるようにします）。サーバーのツールにはmarket_protection引数はありません。NSEは現在、APIのMARKETおよびSL-M注文にマーケットプロテクションを適用しているため、成行注文はブローカーによって保護された指値注文に変換される場合があります。指値エントリーはこれを回避します。BSEの場合、Kiteのtradingsymbolはスクリプト名であり、数値コードではありません。search_instrumentsで検索してください。

セットアップB: Upstox（"broker": "upstox"）

• Upstoxの公式MCPサーバー（https://mcp.upstox.com/mcp、upstox/upstox-plugin-marketplaceプラグインのupstox-mcpからインストール）は読み取り専用です。Upstoxのページでは、これを介して注文を発注することはできないとされています。接続は毎日期限切れになります（ブラウザでのOAuth同意）。
• Upstoxの公式エージェントスキル（/plugin install upstox-skill@upstox-plugins-official（Claude Codeで。事前に/plugin marketplace add upstox/upstox-plugin-marketplaceを実行））は、v3注文APIで注文を発注できます。これは、UPSTOX_ACCESS_TOKEN環境変数（ユーザーが自分のシェルで設定し、チャットでは決して設定しない）から日次アクセストークンを読み取り、独自のプレビューを表示し、確認を待ちます。Upstoxは、プレーンなClaude Desktopチャットでは実行されないと述べています。
• または、ユーザーはチケットからUpstoxアプリで注文を発注します。

チケットは、POST https://api-hft.upstox.com/v3/order/place（v2の/v2/order/placeは非推奨とされています。sliceを除いて同じフィールドを受け入れます）の本文を出力します：quantity（整数）、product（I イントラデイ = MIS、D デリバリー = CNC）、validity DAY、price（MARKET / SL-Mの場合は0）、instrument_token、order_type、transaction_type、disclosed_quantity 0、trigger_price（SL / SL-M以外は0）、is_amo false（Upstoxは無視します）、tag、およびmarket_protection: -1（自動）。MARKETおよびSL-Mの場合。APIの成行注文では0は拒否されるためです。

instrument_tokenはNSE_EQ|<ISIN>（またはBSE_EQ|<ISIN>）です。ISINは、優先順に、--isin、注文内のisin、trader-in/universe.json（スキャナーから）、またはNSEのEQUITY_L.csv（一度ブラウザのUser-Agentを使用してtrader-in/state/EQUITY_L.csvにダウンロード。archives.、次にnsearchives.）から取得されます。 BSEの制限： NSEリストはNSEシンボルのみをマッピングします。500325.BOのようなBSEスクリプトコードはマッピングできないため、--isinを渡してください。.BO名のシンボルの場合、NSEリストのISINが使用されます（同じ会社）。ただし、確認してください。ここではUpstoxのインストゥルメントファイル形式を検証していません。ISINがない場合、ライブのUpstoxチケットはREADYになりません。ペーパーチケットにはISINは必要ありません。

手順：エントリー

1. ticket.py showを実行します。READYなチケットのみがユーザーに表示されます。READYでもBLOCKEDでもないチケットは、/trader-in-riskに戻されます（broker JSONがありません）。
2. 1つのチケットを表示し、OCOではないという警告を含めて、「この注文を発注しますか？「はい」または「いいえ」で答えてください。」と尋ねます。質問ごとに1つの注文です。「すべてにはい」を提供しないでください。
3. ticket.py approve --index N --reply "<ユーザーの返信を一字一句そのまま>"を実行します。「記録されませんでした」は、返信がこの注文に対する明示的な承諾ではなかったことを意味します（「もちろん」、「ハーン」、「すべてにはい」、別の銘柄や数量を指定した承諾など）。再度尋ねてください。決して自分で返信を承諾に変換しないでください。
4. ペーパーモード： 上記のようにpaper-fillを実行します。ライブ、Kite： レッグ1のJSONを正確に使用してplace_orderを呼び出します。ユーザーはAllow onceをクリックします。約定を確認し（get_order_history / get_positions）、次にレッグ2のplace_order、次にレッグ3を、それぞれ独自のAllow onceとともに行います。ライブ、Upstox： 同じ順序で、1レッグずつ、本文をUpstoxエージェントスキルまたはアプリに渡します。
5. 各ライブレッグを記録します：ticket.py result --index N --leg entry|stop|target --status placed|denied|failed --broker-id <id>（エントリーには--filled-qty、--filled-price）。エントリーのみがtrader-in-riskの注文としてカウントされます。レッグはleg_placedとして記録されます。失敗した注文は、新しいチェックと新しい承諾なしには再試行されません。

手順：オープン中、およびflat_byまでに決済

• /trader-in-alertsはストップ、ターゲット、およびフラットバイ時間を監視します。
• ストップまたはターゲットが約定した場合：ライブでは、ticket.py fill ... --leg stop（他のレッグを今すぐキャンセルするように促します。get_orders、次にcancel_order、承認が必要）。ペーパーモードでは、paper-fill ... --leg stopを実行します。
• flat_by（デフォルト15:10 IST）までに、まだオープンしているものはすべて決済されます。ブローカーは約15:20 ISTからオープンなMISポジションを自動スクエアオフし、それに対して手数料を請求します（Zerodhaは1注文あたり₹50 + GSTとしています）。そのため、彼らに任せないでください。
  1. ライブ：ブローカーに何株保有しているか尋ねます：get_positions（読み取り専用）。
  2. ticket.py flatten --symbol RELIANCE --qty 12は、MARKET売り（同じ商品）をtrader-in/orders.jsonに書き込みます。

...（以下省略）