runesleo

PM 做不出钱的人里，有相当一部分不是看不准事件，是不会下单。
具体讲：
Polymarket 用的是限价订单簿（CLOB · central limit order book），不是 AMM（自动做市商）。
你看到的 0.51 是当前最低卖单价，不是"市价"。
按市价吃单 = 一档一档往上扫。
举例：盘口深度 $200 / 0.51，往上还有 0.52 / 0.55 / 0.6……
你下 $1000 进去，平均成交可能在 0.56。
5% 隐性滑点。
事件你看准了，PnL 还是负的——根因不是分析错，是 size 超了盘口深度。
3 个新手最容易栽的：
1. 默认市价单 → 全场扫盘
2. 看 spread（价差）不看 depth（深度）→ 0.51/0.52 看着窄，每档只 $50 你吃不下
3. 不看 taker fee → Polymarket 3 月底全面启用 taker 手续费（吃单方手续费，按品类 0-1.8% 不等），长跑下来吃掉一截边缘
正确做法：
- 流动性好的市场（>$10K 日成交）：限价单挂 best ask（最优卖价）附近，等 maker（撮合方）撮合
- 流动性差的：分批吃，每次只吃当档深度的 50%
- 永远先看 orderbook（订单簿）深度，再决定 size
——
我跑 prediction-trader 早期就栽过：H36 这条策略 3/31

今夜の食事会で、友人が彼のClaudeが封鎖されたと言って、私にClaudeを再開すべきか、それともCodexを試すべきか尋ねた
私の答えは以前ほど断固としていなかった😅

いくつかの戦略バックグラウンドプロセスを走らせて、損をした：
明らかにプロセスは動いていて、データも新しいのに、PM2は停止していると表示。
もしPM2に直接再起動を信じてやると、逆に動いているプロセスを中断してしまう。
後になって理解した：PM2 / launchd / pidファイルは、あくまで監視層が登録した状態を示すだけ —— それがプロセスに記録されているか、実際に動いているかは別の話。
本当に生きているかどうかは、プロセス自身が出力する健康ファイルを見る必要がある —— 最終更新が何分前か + プロセス数が一致しているか = 生存している。
巡回スクリプトを書いた。各プロセスは同時に4つの値を報告：
- プロセスが動いているか（psで確認）
- PM2 / launchdに登録されているか
- 健康ファイルの最終更新からの時間
- これら3つが一致しているか
健康ファイルが新しい場合は、死んだとみなさない。
エンジニアリングの教訓：システムの生死を判断するときは、構築した監視層の言うことを見ずに、システム自身が出力する情報が新しいかどうかを見ろ。

polymarket-toolkit v0.4 リリース。
pUSDの償還後、一般ユーザーは公式アプリだけで十分です。しかし、agent / dashboardの層はずっと空白のままです——あるPolymarketウォレットに償還可能な資金があるか、支払可能な金額はいくらか、資金水位アラートをトリガーすべきか、以前は既存のzero-depツールがありませんでした。
3つのhelperを一度に解決：fetch + summarize + label。秘密鍵不要、署名不要、リレーヤ不要、公開APIの読み取り専用。
公開前にCodexに2回独立レビューを実施し、1回目でデモウォレットが支払可能額$1.84と虚偽報告している重大な欠陥（実際は$0）を発見。修正とテストを終え、2/2から9/9に跳ね上がった。
自分自身を見ていると常に盲点がある。

コミュニティでオープンソースのボットについて議論すると、多くの人の共通認識は一言で言えば：儲かるボットは誰もオープンソースにしない、ということです。
聞けば馬鹿馬鹿しい話に聞こえるかもしれませんが、この常識はAI時代になって鋭くなっています——
以前の護城河は「コードが書けること」でした。今やGitHubにAIを投げれば、数秒で全体の構造を理解できる。書き直すコストは2ヶ月から2時間に縮まりました。
護城河は「コードが書ける」から「戦略を考える」へと変わっています。
このことは私自身も層別に取り組んでいます——
polymarket-toolkitはオープンソースにしています（リポジトリやこの種のツール層のことです。再利用価値が高く、敷居も低い、オープンソースはブランド作りに直結します。
Hシリーズのマーケットメイキング／テイカー戦略は非公開です。そこにはsigmaD1の校正、マーケットメイキングのリプライス閾値、逆選択の実証パラメータが含まれています。これらを公開すると、研究の道筋をそのまま仲間に渡すことになり、エッジが商品化されるともうエッジはなくなります——たとえ元々エッジがあったとしても。
中間には一つのラインがあります：方法論は書いても、具体的なパラメータは書いてはいけない。pm-quantの有料ソースコードパッケージ（戦略＋暗号化ZIP＋1on1展開サポート）です。有料

高品質なClaude Codeスキルのコレクションを見つけた——誰かが自分の日常で使っている23のスキルを直接~/.claude/skills/から抽出して公開している、"教育版"のパッケージはない。
最も印象に残ったのはgrill-me：全文4文で、AIに尋問のように各分岐を突き詰めて合意に達するまで質問し続ける。質問は一つずつ、コード内で見つかるものだけにして他は聞かない。
彼のスキルを読むことはチュートリアルを読むよりも役立つ。エンジニアが本当にAIを脳の拡張として使っているのが見える。Planning系（ドメインモデル／ズームアウト／ユビキタス・ランゲージ）は特に良く、コードを書く前の思考の土台となる。
私はgrill-meを自分のスキルにコピーして、次に新しいアイデアを検証したいときに投げ込んで質問させている 😆
リポジトリ：

今日はPM戦略リポジトリをクラッシュさせてしまった。
私は複数の端末でウィンドウを開いて作業する習慣がある：一つはCodexを使って戦略/データを研究し、もう一つはClaudeを使って他の作業を進め、さらに雑多な作業用にもう一つ開く。徐々にいくつも端末ウィンドウを開くようになった。私はそれぞれが独立していると思っていた。結果は、両方が同じ.tsを編集していて、gitの状態が大混乱になり、2時間かけて修正した。
みんなはマルチエージェントの協調について話している。gitレベルでのそれについてはあまり話されていない。
2つのエージェントはgitの目には＝2人の私。同じファイルを互いに踏みつけ合い、ブランチの状態が衝突する。修正方法はpromptではなく、リポジトリの構造にある。
新たな鉄則を立てた、4つのポイント：
1. 高リスクのリポジトリはメインリポジトリを直接編集禁止、メインリポジトリはクリーンな土台とする
2. 各タスクは独立したワークツリーに、slug＝戦略番号＋アクション（h12-cancel-sync / pnl-script-v8）
3. active-tasksのJSONにworktree_pathフィールドを追加、二つ目のウィンドウを開く前にgrepで重複防止
4. 完了したらメインリポジトリに戻し、ワークツリーとブランチを削除
まず単一プロジェクトで一日試験運用し

AIを使えば使うほど性格が悪くなった
できることが増えるほど、結果に対する要求も高まる。
もっと良くなるはずだと思っているので、うまくいかないと本当に怒ってしまう。😠