GateUser-cc6abff6

YCのCEO、Garry Tanは彼のClaude Codeワークフローをオープンソース化し、24時間でGitHubのスター数は4Kを超えました。
8つのスラッシュコマンド、それぞれが異なる役割に対応しています：CEOは製品の方向性をレビューし、エンジニアマネージャーはアーキテクチャを審査し、Staff Engineerは本番事故を検出し、リリースマネージャーはワンクリックでリリースし、QAは自動でスクリーンショットを撮ってバグをテストします。
核心は一つだけ：AIを万能の助手とみなすのではなく、役割を与えることです。
最も印象に残ったのは /plan-ceo-review です。「画像アップロードを追加したい」と言っても、AIは急いでコードを書き始めるのではなく、まず逆に問い返します：「これが本当に必要な機能ですか？本当のニーズは、売り手が自動的に商品説明を生成できるようにすることかもしれません」。つまり、「どうやってやるか」から「何をやるか」へと視点を戻すのです。
/reviewも非常に強力です。意図的に本番事故をシミュレートします：N+1クエリ？並列競合？アップロード失敗で孤立したファイル？バグが爆発する前に、すべての落とし穴を事前に考え抜きます。
根底にある原則：AIを雑多に使うよりも、専門的に使う方が効果的です。

To register a new platform and get an API key, at minimum you need to: open a webpage, fill in email and password, switch to Gmail to find the verification code, paste it back, find the API key page, create it, and copy it. One platform takes 5 minutes, ten platforms take all morning.
I built a Claude Code Skill that, when you say "help me register xxx", handles the rest automatically.
Two-layer architecture:
First layer leverages login state — inject cookies directly from Chrome using Playwright. No need to re-login to already-authenticated services. About 200 lines of Python.
Second layer fu

Claude CodeにX検索エンジンを接続しました。Grokを基盤にしたローカルブリッジサービスを構築し、常駐させており、Claude CodeがXを検索する必要があるときに自動的に呼び出されます。端末の一行コマンドで、数秒以内に要約と関連するユーザーの発言を返します。二つの重要な利点は、X公式APIを使わない（毎月の$200 のBasicプランを節約できる）ことと、リアルタイムの動向も検索できることです。API検索は遅延やインデックス制限がありますが、Grokは最新の情報を直接取得します。（前提：X Premium+/PremiumのGrok権限が必要な場合があります）最も典型的なシナリオは、Claude Codeを使って作業しているときに、X上の特定の話題の最新議論を知りたいとき—誰が話しているのか、どんな意見か、落とし穴はあるかです。以前はブラウザを切り替えて手動で検索していましたが、今はClaudeが自動で調べて、要約を持ち帰って作業を続けられます。これを導入したら元に戻れません。情報収集が「自分で探す」から「彼に探させる」へと変わり、体感がまったく異なります。

Claude Codeを使い始めて3ヶ月、ディレクトリは増え続け、rules/、docs/、memory/、skills/といったさまざまな階層構造を作ったが、自分が何を構築しているのかはっきりと説明できなかった。
そのとき、「Everything is Context」という論文を読んで、私のフォルダ構造を学術的な言葉に翻訳してみた：
→ 論文はScratchpad（仮置き作業領域）と呼ぶ
→ Fact Memory（プロジェクトレベルの事実記憶）
→ Experiential Memory（プロジェクトを跨ぐ経験）
rules/の自動ロードとdocs/の必要に応じたロードは、→ Context Constructor（トークン予算内で選択的にロードする）
最も共感したのは、トークンウィンドウの制約に関する部分だった。以前はrules/を全てロードしていたため、コンテキストが一気に膨れ上がった。後に二層構造に分けて安定させた。論文ではこれを「bounded reasoning capacity（制約された推論能力）」と呼んでいる—つまり、私が解決しようとしていたのはこの問題だった。
実践を先に行い、命名は後からつける。まずは失敗を経験し、その後論文を読んで、失敗に名前がついていることに気づいた。

独立して発見した直感に反する事実：
製品の機能とインフラ、後者が常に優先されるべきだ。
今日、プロジェクトの状況を確認したところ、取引戦略は24時間停止しており（WebSocketの切断）、データパイプラインはすべてstale状態だった。一方で、私は「Portfolio Digest」のような付加価値のある機能の開発に忙しかった。
教訓：
- 定期的にコアシステムの状態を積極的に確認する
- 「稼働中」と書かれていても、実際に動いているとは限らない
- お金に一番近いこと > 製品を見た目良くすること
優先順位の見直し：インフラの修正 > 新機能の開発。