LangChain は 1 億 6000 万ドルを調達しました。3 年間の開発。評価額は数十億ドル。彼らのテストプラットフォーム LangSmith は、本当に洗練されています：トレース評価、トレース→データセットパイプライン、LLM アズジャッジ、回帰スイート、ツール用の単体テストフレームワーク。要素は揃っています。功績は認めるべきです。
しかし、要素は実践ではありません。
LangChain はテストの ツール を提供します。何をテストすべきか、どの順序で、いつ完了するかは決して教えてくれません。
次のように順序立てて指示する、意見を持ったワークフローは存在しません：
- この障害が発生した
- 次にスキルを書く
- 次に決定論的なコードを書く
- 次に単体テストを書く
- 次に LLM 評価を書く
- 次にリゾルバトリガーを追加する
- 次にリゾルバを評価する
- 次に重複を監査する
- 次にスモークテストを行う
- 次に正しくファイリングする
そのループは存在しません。 散在するプリミティブから自分で発明する必要があります。AI ユーザーの大多数は、今でもエージェントをまったくテストしていません。なぜなら、彼らが選んだフレームワークはおそらく、トレーニングプランなしでジムの会員権を与えただけだからです。
ほとんどの AI エージェントの「信頼性」は雰囲気ベースです。プロンプトの微調整。より長いシステムメッセージ。「幻覚を起こさないでください」という呪文。それらは会話が複雑になるとすぐに劣化します。この問題を解決するために数億ドルを調達したフレームワークは、モニタリングダッシュボードと単体テストヘルパーを提供して「がんばって」と言っただけです。
私のエージェントは今週 2 回失敗しました。どちらの失敗も二度と起こしてはいけません。お願いしたからではありません。それぞれの失敗を恒久的な構造的修正に変えたからです。それは、毎日、永久に実行されるテストを持つスキルです。
私はこの実践を「スキル化（skillify）」と呼んでいます。 一度使えば、あなたのエージェントは同じ過ちを繰り返さなくなります。仕組みは次のとおりです。
失敗 1：データベースにすでにあった出張
古い出張について、ほぼ 10 年前の、カレンダー履歴のどこかに埋もれているものを、私は OpenClaw に尋ねました。単純な質問です。一瞬で答えが出るはずでした。
代わりにエージェントはこうしました：
- ライブのカレンダー API を呼び出す → ブロックされる（過去すぎる）。
- メール検索を試す → ノイズが多く、決定的なものは何もない。
- 別のパラメータでカレンダー API を再度試す → まだブロックされる。
- 5 分後、ローカルのナレッジベースを検索し、すぐに見つける。
答えはずっと自分のデータの中にありました。2013 年から 2026 年までの 3,146 個のカレンダーファイル。 すでにインデックス化され、すでにローカルにあります。grep 一つで見つかります。
エージェントは最初にそこを見なかっただけです。
私が書いてきたフレームワーク（thin harness, fat skills）では、判断を必要とする作業と精度を必要とする作業の間に重要な区別があります。私はそれらを 潜在（latent） と 決定論的（deterministic） と呼んでいます。カレンダーの grep は決定論的です。同じ入力、同じ出力、毎回。モデルは不要です。しかしエージェントはそれを潜在空間で行い、推論を起動し、API 呼び出しを行い、結果を解釈しました。3 行のスクリプトで即座に答えが返せたのに。
それがバグです。間違った答えではありません。間違った 側面 です。
修正：calendar-recall（ステップ 1 + 2）
thin harness / fat skills では、スキル とは、モデルにタスクへの取り組み方を教えるマークダウンの手順です。何をすべきか（何をするかはユーザーが提供）ではなく、プロセスを提供します。メソッド呼び出しのように考えてください。同じ手順でも、渡す内容によって出力は根本的に異なります。
この失敗から生まれたスキルは次のとおりです：
name: calendar-recall description: 「脳ファーストの過去のカレンダー検索。未来または過去 48 時間以内でないイベントには、必ずライブ API の前にこれを使用すること」
そして内部の厳格なルール：
ライブカレンダー API は、FUTURE または LAST 48 HOURS のイベントにのみ使用すること。過去のものはすべて、最初にローカルナレッジベースを経由すること。
これが機能する理由は、エージェント自身が決定論的なスクリプトを書いたことです。スキルファイル（潜在空間に存在するマークダウン）は、エージェントに問題の 修正方法 を指示しました。エージェントはスキルを読み、カレンダー検索が決定論的な作業であることを理解し、それを処理するスクリプトを生成しました：
$ node scripts/calendar-recall.mjs search "Singapore"
Found 2 matching day(s): ── 2016-05-07 ── Flight to Singapore, Mandarin Oriental check-in ── 2016-05-08 ── Lunch with investors at Fullerton Hotel
100 ミリ秒未満で実行されるコード（そのほとんどは Bun の起動時間で、実際の grep は 1 ミリ秒未満）。LLM 呼び出しはゼロ。ネットワークはゼロ。ローカルファイルのみ。
これがアーキテクチャ全体を機能させるループです：潜在空間が決定論的ツールを構築し、次に決定論的ツールが潜在空間を制約します。 エージェントは判断力（潜在）を使って calendar-recall.mjs を書きました。今やスキルはエージェントに、カレンダーデータについて推論する代わりにそのスクリプトを 実行する ことを強制します。モデルの知性が、モデルが愚かになるのを防ぐ制約を生み出しました。
古い失敗パスは構造的に到達不可能になります。スキルは「最初にローカルを検索せよ」と指示します。スクリプトが検索を実行します。エージェントはそれについて賢くなったり、再び間違えたりする機会を得られません。
失敗 2：「28 分」（再びステップ 1 + 2）
同じ日。エージェントが言う：「次のミーティングまであと 28 分です。」
現実：あと 88 分。エージェントは頭の中で UTC→PT のタイムゾーン計算を行い、ちょうど 1 時間ずれていました。
問題は、次の出力を行うスクリプト（context-now.mjs）がすでに存在していたことです：
{ "now": "2026-04-21T07:38:12-07:00", "upcomingEvents": [{ "summary": "App Ops Sprint Planning", "minutesUntil": 88 }] }
約 50 ミリ秒で実行されるコード。曖昧さはゼロ。エージェントがそれを実行しなかっただけです。
以前と同じ形：決定論的な作業（タイムスタンプの減算）が潜在空間で行われた。スクリプトに答えがあるのに、モデルが暗算をしていた。
修正：context-now、スキル：
name: context-now description: 「ALWAYS-ON の規律：時間に敏感な主張を行う前に、必ず context-now.mjs を実行すること。頭の中で UTC→PT 変換を決して行わないこと」
これらシンプルなスキルの有無による前後の比較は以下のとおりです：
スキル化：あなたの正気を保つパターン
2 つの失敗。同じ形。エージェントは正しいツールを持っていたのに、規律ではなく賢さを選んだ。 間違った機械空間で間違ったことが起こりました。
通常の AI 設定では、AI は謝り、今後は改善すると約束します。そして 2 週間後、別のクエリや別のタイムゾーンで同じことが起こります。エージェントはバグの記憶も、バグのテストも、再発を防ぐものも持っていません。
スキル化 が修正です。すべての失敗がスキルになります。すべてのスキルにはテストがあります。バグは構造的に繰り返し不可能になります。
失敗が昇格したときに私が使用する 10 項目のチェックリストは次のとおりです：
□ 1. SKILL.md — 契約（名前、トリガー、ルール） □ 2. 決定論的コード — scripts/*.mjs（コードができることに LLM は不要） □ 3. 単体テスト — vitest □ 4. 統合テスト — ライブエンドポイント □ 5. LLM 評価 — 品質＋正確性 □ 6. リゾルバトリガー — AGENTS.md のエントリ □ 7. リゾルバ評価 — トリガーが実際にルーティングすることを確認 □ 8. 解決可能性チェック + DRY 監査 □ 9. E2E スモークテスト □ 10. 脳のファイリングルール
10 項目すべてをパスしない機能はスキルではありません。単に今日たまたま動くコードです。
上記の 2 つの失敗は、すでにステップ 1 と 2 を実行しました：SKILL.md（契約）を書き、次に決定論的コード（エージェントが構築してから使用するスクリプト）を書く。しかし、残りの 8 つのステップを説明する前に、スキル化が日常的にどのように見えるかをお見せしたいと思います。なぜなら、それは単なる失敗への対応ではないからです。それは動詞になりました。
動詞としてのスキル化
私にとって、自分の OpenClaw（および GBrain）を構築する際、チェックリストは最初は失敗対応プロトコルでした。その後、すべてを構築する方法になりました。
実際のワークフローは次のとおりです。私はエージェントと自然言語で話します。会話の中で一緒に何かを構築します。試します。動きます。それから一言言います：
Garry：
すごい、動いた。これを webhook スキルとして覚えて、スキル化してくれないか？次に webhook が必要なときに使えるように。なんでこれがこんなに正しく動かすのが難しかったんだ？とにかく今は大丈夫だ。DRY にもしておいてくれ
これは OAuth の webhook 統合でした。動かすのに 1 時間かかりました。そして「スキル化して」で、その場限りのセッションが、テスト、リゾルバエントリ、ドキュメントを備えた耐久性のあるスキルに変わりました。次に webhook が必要になったとき、スキルは存在します。エージェントがそれを読みます。その 1 時間で得た苦労して得た知識は永久に残ります。
別の例。コンテナが特定のタスクにはヘッドレスブラウザを必要とし、他のタスクにはデスクトップ上のヘッド付きブラウザを必要とすることがわかりました：
Garry：
素晴らしい！だから、OpenClaw でヘッドレスブラウザが必要になったときはいつでも、これをスキルとして覚えておくべきだ。そして、ヘッド付きブラウザが必要な場合は、ユーザーに gstack browser を実行してもらい、ペアエージェントコードを提供するように依頼する必要があることも知っておくべきだ。スキル化して！
1 メッセージ。エージェントは skills/browser/SKILL.md を、決定ツリー、決定論的スクリプト、テストとともに書きます。今後、ブラウザを必要とするすべてのセッションは、自動的に正しいツールにルーティングされます。
またはこれ。エージェントが、実際に動作するか確認せずに ngrok リンクを送り続けているのに気づきました：
Garry：
リンクを送るときはいつでも、自分で curl してエンドポイントが開いていてトンネルが機能していることを確認するスキルを作れる？スキル化して！
または、会議を危うくしかけたカレンダーの二重予約：
Garry：
ここに 1 つ、定期的に使うスキルを書いてほしい。カレンダーチェックスキルだ。明日の午前 11 時が二重予約になっている。スキルを作って、こういうことを確認するための決定論的なものにしておいてくれ。
1 文。コード、スキル、テスト、リゾルバエントリ、到達可能性監査。10 ステップのチェックリスト全体が一度に。私の OpenClaw はそれを理解し、実行し、今やそれはルーティーンになっています。もう何十回もやっています。これなしでは生きていけません。
パターンは常に同じです：会話でプロトタイプを作り、動くのを確認し、「スキル化」と言い、プロトタイプが恒久的なインフラになります。私は仕様を書きません。チケットを起票しません。エージェントと話し、一緒に問題を解決し、そしてその解決策がエージェントが私なしで永久に使えるスキルになります。
これが、1 億 6000 万ドルのフレームワーク資金が逃したものです。テストのプリミティブでも、評価ツールでもありません。ワークフローです。人間が「それがうまくいった、今度はそれを恒久的なものにしよう」と言い、システムが「恒久的」が正確に何を意味するかを知っている瞬間：SKILL.md、決定論的コード、単体テスト、統合テスト、LLM 評価、リゾルバトリガー、リゾルバ評価、DRY 監査、スモークテスト、脳のファイリング。10 ステップ。1 語。
残りの 8 つのステップが実際にどのように見えるかを次に示します。
ステップ 3：単体テスト
クラシックな vitest。決定論的関数、決定論的アサーション。calendar-recall.mjs は、parseEventLine、eventMatchesKeyword、searchKeyword、formatJson のような純粋関数をエクスポートします。各関数はフィクスチャデータ（一時ディレクトリ内の合成カレンダーファイル、既知の入力、既知の出力）に対してテストされます。
これらが捕捉するバグの種類：parseEventLine が location フィールドに Unicode 文字があるイベントを静かにドロップする。dateFromPath がうるう年の日付に対して null を返す。formatJson が参加者が 1 人だけのときに attendees 配列を省略する。小さく、退屈で、重要です。スクリプトが間違った出力を生成すると、スキルは間違った答えを生成し、エージェントは自信を持って間違ったことを伝えます。
context-now の場合、単体テストはタイムゾーン書式、静かな時間帯の検出、DST 境界をまたぐ minutesUntil 計算を検証します。あるテストは DST 移行の 3 分前の時間を入力し、出力が 60 分跳ね上がらないことを確認します。これがまさに「28 分」の失敗を引き起こしたバグです。今では構造的に不可能です。
私は 5 つのスイートにわたって 179 の単体テストを持っています。2 秒未満で実行されます。
ステップ 4：統合テスト
これらはライブエンドポイントと実際のデータを叩きます。calendar-recall.mjs が実際の脳リポジトリでイベントを見つけられるか（テストフィクスチャだけでなく）？context-now.mjs はカレンダーキャッシュが古くなったり存在しない場合でも有効な JSON を生成するか？統合テストは、フィクスチャデータがきれいすぎるために単体テストが見逃すバグを捕捉します。実際のデータには、不正な形式のイベント行、欠落したタイムゾーンフィールド、Windows の改行コードを持つカレンダーファイル、真夜中をまたぐイベントが含まれます。
ルール：実際のデータでスクリプトが正しいことをしたかどうかを手動で確認している自分に気づいたら、そのチェックは統合テストにすべきです。
ステップ 5：LLM 評価
ここからが面白くなります。一部の出力は評価に判断を必要とします。「このカレンダーサマリーは役に立つか？」はスクリプトが答えられる yes/no の質問ではありません。そこで私は LLM アズジャッジを使用します：あるモデルがルーブリックに基づいて別のモデルの出力を評価します。
context-now の場合、35 の評価が毎日実行されます。そのうちの 1 つは、エージェントに「ねえ、飛行機が約 45 分後に出発するんだけど、SFO に間に合うかな？」のようなメッセージを送り、エージェントが答える前に context-now.mjs を実行するか、それとも頭の中で計算しようとするかをチェックします。エージェントが餌に食いついて自分で時間を計算した場合、評価は失敗します。
別の評価は、エージェントに UTC タイムスタンプを与え、「それは私にとって何時ですか？」と尋ねます。正しい動作はスクリプトを実行して結果を引用することです。間違った動作は変換を頭の中で行うことです。評価は間違った答えと間違ったプロセスの両方を捕捉します。なぜなら、たまたま今回の暗算が正しくても、次回は間違うからです。
私が見つけた最も正直な評価のヒューリスティック：会話履歴で「くそっ」とか「なんてこった」と言った箇所を検索してください。それらがあなたが見逃しているテストケースです。
ステップ 6：リゾルバトリガー
リゾルバ はコンテキストのルーティングテーブルです：タスクタイプ X が現れたら、スキル Y をロードする。リゾルバについてはこちらで詳しく書きました。各スキルは AGENTS.md にトリガーエントリが必要です。AGENTS.md はエージェントにどのスキルが存在し、いつ使用するかを教えるファイルです。
リゾルバトリガーはマークダウンテーブルの単なる行です：
このステップが捕捉するバグ：新しいスキルを書いたが、リゾルバに追加するのを忘れる。スキルは存在する。能力は存在する。システムが到達できない。それは、スタッフに外科医がいるのに、病院のディレクトリに載っていないのと同じです。スキルがまったくないよりも悪い。なぜなら、システムがそれを処理できると 思っている からです。
ステップ 7：リゾルバ評価
これはほとんどの人が完全に見逃す層です。リゾルバトリガーは「このフレーズはこのスキルにルーティングされるべきだ」と言います。リゾルバ評価はそれが 実際に そうなることを テスト します。
私のリゾルバ評価スイートには、次のような 50 以上のテストケースがあります：
{ intent: '署名を確認して', expectedSkill: 'executive-assistant' }, { intent: 'Pedro Franceschi って誰？', expectedSkill: 'brain-ops' }, { intent: 'この記事を保存して', expectedSkill: 'idea-ingest' }, { intent: 'ミーティングは何時？', expectedSkill: 'context-now' }, { intent: '2016 年の旅行を見つけて', expectedSkill: 'calendar-recall' },
2 つの障害モード。偽陰性：スキルが発動すべきなのに発動しない。トリガーの説明が間違っているか欠落しているため。偽陽性：間違ったスキルが発動する。2 つのトリガーが重複しているため。「明日のカレンダーは何がある？」は calendar-check にルーティングされるべきで、calendar-recall や google-calendar ではありません。3 つのスキル、3 つの異なる時間領域、1 つのフレーズがどれにも一致し得る。リゾルバ評価は、ユーザーが遭遇する前に曖昧さを捕捉します。
私はこれらの評価を、決定論的な構造テスト（AGENTS.md テーブルが正しいマッピングを含んでいるか）と LLM ルーティングテスト（この意図が与えられたとき、モデルが実際に正しいスキルを選択するか）の両方として実行します。両方の層が重要です。テーブルが正しくても、トリガーの説明が曖昧なためにモデルが間違ったルーティングをすることがあります。
ステップ 8：解決可能性チェック + DRY 監査
1 か月間構築した後、40 以上のスキルがありました。特定のインシデントに応じて作成されたものもあれば、サブエージェントが crons を実行して生成したものもあります。誰もリゾルバテーブルを保守していませんでした。スキルは生まれても登録されていませんでした。
そこで check-resolvable を構築しました。チェーン全体をウォークするメタテスト：AGENTS.md リゾルバ → SKILL.md → スクリプト/cron。有用な作業を行うスクリプトが存在しても、リゾルバからのパスがない場合、それは到達不可能です。LLM はその存在を決して知りません。
最初の実行で、40 以上のうち 6 つの到達不可能なスキルが見つかりました。システムの能力の 15% が闇に葬られていました。
- フライトについて尋ねても誰も呼び出せないフライトトラッカー。
- cron でのみ実行され、手動でトリガーできないコンテンツアイデアジェネレーター。
- スキルディレクトリには存在するが、リゾルバにまったくリストされていない引用修正ツール。
1 時間で修正しました。AGENTS.md にトリガーエントリを追加しただけです。今では check-resolvable が gbrain doctor の一部として毎週実行されます。3 つのことをチェックします：
- SKILL.md を持つすべてのスキルディレクトリに、リゾルバ内に対応するエントリがあること。
- スキルによって参照されるすべてのスクリプトが実際に呼び出し可能であること（ファイルが存在し、正しい関数をエクスポートしている）。
- 曖昧なルーティングを引き起こすような、重複するトリガー説明を持つスキルが 2 つ以上ないこと。
DRY 監査も一緒に実行されます。注意しないと、同じようなことをするスキルが 15 個できてしまい、リゾルバはサイコロの出目次第でどれかを選びます。calendar-recall の場合：
同じドメインに 4 つのスキル。重複はゼロ。それぞれにレーンがあります。そのマトリックスはこの投稿のために描かれた図ではありません。SKILL.md の中にあり、監査スクリプトがそれを解析します。別のスキルのレーンを侵害する 6 番目のカレンダースキルを構築すると、スキルが出荷される前に監査が失敗します。
ステップ 9：E2E スモークテスト
完全なパイプライン、エンドツーエンド。
- エージェントに「シンガポールに行ったのはいつ？」と尋ね、calendar-recall.mjs を実行し、正しい答えを得て、正しくフォーマットすることを確認する。
- 「次のミーティングは何時？」と尋ね、context-now.mjs を実行することを確認し、暗算をしないことを確認する。
スモークテストは最後の防御線です。他のすべてがパスしても、ピースが接続されていなければシステムは失敗し得ます。スキルが正しくても、スクリプトが正しくても、リゾルバが正しくても、エージェントはそれらすべてを無視して即興でやることを選択できます。スモークテストはそれを捕捉します。
ステップ 10：脳のファイリングルール
ナレッジベースに書き込むすべてのスキルは、どこに何が行くかを知る必要があります。人は people/ へ。会社は companies/ へ。ポリシー分析は civic/ へ。13 の脳書き込みスキルのうち 10 が間違ったディレクトリにファイリングしているのを捕捉しました。各スキルがリゾルバに相談する代わりに、独自のパスをハードコードしていたためです。
ファイリングルールドキュメントは、一般的な誤ファイリングパターンをカタログ化しています。ソースとオリジナル。人と会社（誰かが会社である場合）。スキルはページを作成する前にルールを読みます。それ以降、誤ファイリングはゼロです。
GBrain：スキル化が生きる場所、そしてあなたが私の GBrain スキルパックから採用すべき理由
スキル化パターンは、OpenClaw や特定のハーネスに固有のものではありません。それは GBrain に組み込まれています。GBrain は私が書いたオープンソースの知識エンジンで、あなたが使用するハーネスの下にあります。脳リポジトリを管理し、評価を実行し、スキルを耐久性のあるものにする品質ゲートを実施します。
GBrain SkillPack は、スキル、リゾルバトリガー、決定論的スクリプト、テストのポータブルバンドルで、OpenClaw/Hermes Agent に「これを実行して」と依頼するだけで、任意のエージェントセットアップにインストールできます。これは、私が OpenClaw/Hermes Agent 用に書いたスキルと能力が、自動的に あなたの OpenClaw に追加される方法です。10 ステップのスキル化出力全体を含み、あなたの OpenClaw/Hermes Agent にドロップするだけでそのまま動作するようにパッケージ化されています。
前述の skillify チェックリストは提案ではありません。それは gbrain doctor が実際にチェックするものです。*
gbrain doctor --fix は、DRY 違反を自動修復し、重複ブロックを慣例参照に置き換えます。すべて git ワーキングツリーチェックで保護されているため、何も上書きされません。
Hermes Agent だけでは不十分な理由
Nous Research の Hermes Agent は、本当に素晴らしいことを 1 つ行います：エージェント自身が学習した内容に基づいてスキルを作成、パッチ適用、削除できる skill_manage ツールを持っています。エージェントが複雑なタスクを完了したり、エラーから回復したりすると、スキルを提案し、ディスクに書き込みます。それはエージェントが自分で獲得する手続き記憶です。プログレッシブ開示（最初にスキルインデックスをロードし、選択された場合のみ完全な SKILL.md を取得）。バウンドメモリ（MEMORY.md は 2,200 文字に制限）。条件付きアクティベーション（必要なツールが利用できない場合、スキルは自動的に非表示）。スマートな設計。
しかし、Hermes はスキルをテストしません。決定論的コードの単体テストはありません。ルーティングを確認するリゾルバ評価はありません。闇のスキルを見つける check-resolvable はありません。重複を捕捉する DRY 監査はありません。何かがずれたときに赤くなる毎日のヘルスチェックはありません。
私がテストされていないスキルシステムで蓄積されるのを見てきた障害モード：
- 月曜日にエージェントが deploy-k8s を作成。木曜日に別の会話から kubernetes-deploy を作成。両方が存在し、類似したフレーズでトリガーされる。曖昧なルーティングで、間違った方が間違ったタイミングで発動するまで誰も気づかない。
- スキルは書かれた時点で完全に機能。6 週間後、上流の API が変化。スキルは静かにゴミを返し続け、人間が気づくまで続く。
- 自律的に作成されたスキルに弱いトリガーがあり、決して一致しない。孤児になり、インデックストークンを消費し、決して実行されず、ゆっくりと腐敗する。
これは、「テストがなければ、どんなコードベースも腐敗する」という問題であり、ソフトウェアエンジニアリングは 2005 年に解決しました。エージェントスキルも同じです。Hermes は作成を美しく処理します。GBrain は検証を処理します。両方が必要です。
大きなアイデア
健全なソフトウェアエンジニアリングチームでは、すべてのバグにテストが追加されます。そのテストは永久に生き続けます。バグは構造的に再発不可能になります。AI エージェントも同じように機能するべきです。
すべての失敗はスキルになります。すべてのスキルには評価があります。すべての評価は毎日実行されます。エージェントの判断力は 恒久的に 向上します。現在のセッションだけでなく、コンテキストウィンドウが保持されている間だけではありません。
出張の失敗は二度と起こりません。タイムゾーンの失敗は二度と起こりません。そして、次の失敗が現れたとき（現れるでしょう。なぜならこれはエントロピーと好みに対する adversial なゲームだからです）、それもスキル化されます。
1 年後に私が一緒に仕事をするエージェントは、その前の 1 年間に犯したすべての過ちによって形成されるでしょう。それは「あると便利」ではありません。それが全体のテーゼです。
海を沸騰させましょう。エージェントに何かをさせ、それをスキル化してください。それを毎日行えば、あなたは自分が望むすべてを実行する、めちゃくちゃ賢い OpenClaw を手に入れます。
または、単に GBrain をロードして、私がすでに書いたすべてのコードを使用し、Iron Man のあなた自身の Jarvis により早く到達することもできます。
--
Claude Code でスピードアップするための GStack github.com/garrytan/gstack
OpenClaw/Hermes Agent であなた自身の Iron Man の Jarvis を構築するための GBrain github.com/garrytan/gbrain
