Agent Skills
(addyosmani.com)- Agent Skills は、AIコーディングエージェントが仕様、テスト、レビュー可能なPR、信頼境界のレビューといった シニアエンジニアリングの手順 を飛ばせないよう、ワークフローとして強制するためのスキャフォールディング
- スキル(skill) は frontmatter を持つ Markdown ファイルで、参照ドキュメントというより、手順の順序、チェックポイントの証拠、終了条件を持つ ワークフロー に近い
- リポジトリの20個のスキルは、Define、Plan、Build、Verify、Review、Ship の6つのライフサイクル段階と、
/spec、/plan、/build、/test、/review、/ship、/code-simplifyの7つの slash command で構成される - 中核原則は 散文よりプロセス、反合理化テーブル、検証を終了条件にすること、段階的開示、スコープ規律であり、
using-agent-skillsが作業に合ったスキルだけを有効化する - Claude Code marketplace でのインストール、Cursor の
.cursor/rules/、Gemini CLI、Codex、Aider、Windsurf、OpenCode などのツールに Markdown を入れる形で利用でき、MIT ライセンスで公開されている
目的と問題意識
- Agent Skills は、AIコーディングエージェントがデフォルトで飛ばしがちな シニアエンジニアリングの手順 を、ワークフローとして強制するためのスキャフォールディング
- AIコーディングエージェントは機能を依頼されると、たいてい最短経路で実装を終えようとし、仕様作成、テスト先行、信頼境界のレビュー、レビュー可能なPRの構成といった手順を標準では行わない
- シニアエンジニアの仕事には、diff に現れない部分が多い
- 前提を明示する
- 仕様を書く
- レビュー可能な単位に作業を分割する
- 退屈でも安全な設計を選ぶ
- 結果が正しいという証拠を残す
- 人が実際にレビューできる大きさに変更を制限する
- エージェントがこうした段階を飛ばす理由はジュニアエンジニアに似ていて、報酬シグナルが「作業完了」に合わせられており、「仕様書まで存在する形での作業完了」には合わせられていないため
- Agent Skills リポジトリは 26K stars を超えており、README を超えて、設計判断の理由、標準的な SDLC や Google の公開エンジニアリング慣行との対応、インストールしなくても持ち帰れるパターンまで扱っている
スキルの実際の意味
- スキル(skill) は、状況に応じてエージェントのコンテキストに注入される frontmatter 付きの Markdown ファイルで、システムプロンプトの断片とランブックの中間に近い形
- スキルは参照ドキュメントではなく、「テストについて知っておくべきすべて」のような知識集でもない
- 有用なスキルとは、エージェントが従う ワークフロー である
- 手順の順序がある
- チェックポイントで証拠を生成する
- 明確な終了条件で終わる
- テストのベストプラクティスに関する 2,000 語のエッセイをコンテキストに入れると、エージェントはもっともらしい文章を生成し、実際のテストは飛ばせてしまう
- 一方で、まず失敗するテストを書き、実行して失敗を確認し、通すために必要最小限の実装を書き、通過を確認し、リファクタリングするワークフローを入れれば、エージェントには実行すべき作業が生まれ、人間も検証できる
- 重要な区別は 散文よりプロセス、参照よりワークフロー、終了条件のないエッセイより終了条件のある手順という点
- 多くの「AI rules」リポジトリが実際には効かないのは、ルールがワークフローではなくエッセイにとどまっているから
SDLC と slash command の構造
- リポジトリの20個のスキルは6つのライフサイクル段階で構成され、その上に7つの slash command が置かれている
-
段階とコマンド
/spec: 何を作るかを決める Define 段階/plan: 作業を分解する Plan 段階/build: 垂直スライスで実装する Build 段階/test: 動作を証明する Verify 段階/review: 取りこぼした問題を見つける Review 段階/ship: ユーザーに安全に届ける Ship 段階/code-simplify: 全体の流れを横断して適用される簡素化コマンド- この構造は、正常に機能するエンジニアリング組織の SDLC と同じ流れであり、組織ごとに語彙が違うだけ
- Google では design doc → review → implementation → readability review → launch checklist という流れで、Amazon では working-backwards memo や bar raiser のような形で現れる
- AIコーディングエージェントの新しい問題は、ほとんどのエージェントがこれらの段階の大半をデフォルトで飛ばしてしまうことにある
- 機能を依頼すると実装だけが返り、仕様、計画、テスト、レビュー、リリースチェックリストは実行されない
- スキルは、シニアエンジニアが自らに強制する段階をエージェントにも通過させるもので、そうした手順なしにコードをデプロイすると障害につながる
- 複雑な機能では11個のスキルが順次有効化されることがあり、小さなバグ修正なら3個だけ使うこともある
using-agent-skillsルーターが現在の作業にどのスキルを適用するかを決め、ワークフローは想定された範囲ではなく実際のスコープに合わせて拡張される
動作を支える原則
-
1. 散文よりプロセス
- ワークフローはエージェントが行動に移せるが、エッセイはそうではない
- 同じ原理は人間のチームにも当てはまる
- チームハンドブックが 200 ページあるなら、プレッシャー下では読まれないが、チェックポイント付きの小さなワークフローなら実行される可能性が高い
-
2. 反合理化テーブル
- Agent Skills でもっとも独特で、他チームも持ち帰るべき設計判断は 反合理化テーブル(anti-rationalization tables)
- 各スキルには、エージェントや疲れたエンジニアがワークフローを飛ばすために使いがちな定番の言い訳と、それに対する事前に書かれた反論が含まれている
- 例は次のとおり
- 「この作業は単純すぎるので仕様は不要」 → 受け入れ基準は依然として必要。5行ならよいが、0行はだめ
- 「テストはあとで書く」 → 問題の本質は「あとで」。あとでは来ない。先に失敗するテストを書くべき
- 「テストは通ったのでデプロイしよう」 → 通過したテストは証拠であって証明ではない。ランタイムを確認したか、ユーザーに見える動作を検証したか、人が diff を読んだかを確認すべき
- LLM は合理化が得意で、特定の作業には仕様が不要だとか、特定の変更はレビューなしでマージしてよいといった、もっともらしい段落を作れてしまう
- 反合理化テーブルは、エージェントがまだ口にしていない嘘に対する 事前に書かれた反論 である
- このパターンは人間のチームにも有効
- エンジニアリング品質の低下は、たいてい誰かが悪いことをしようと決めたからではなく、やりたくない手順を飛ばすもっともらしい正当化を受け入れることで起こる
-
3. 検証は交渉不可
- すべてのスキルは具体的な証拠で終わる
- テスト通過、クリーンなビルド出力、期待した動作を示すランタイム trace、レビュアーの承認といったものが終了条件になる
- 「もっともらしく見える」では不十分
- これは Anthropic の harness が失敗から回復し、Cursor の planner/worker/judge 分離が実際にバグを見つけ、long-running agent が回復可能になる原理と同じ
- エージェントは生成器なので、作業完了を判断するための別のシグナルが必要であり、スキルはそのシグナルを各ワークフローに組み込む
-
4. 段階的開示
- セッション開始時に20個すべてのスキルをコンテキストへ入れるわけではない
- 現在の段階に応じて必要なスキルだけを有効化する
- 小さなメタスキルである
using-agent-skillsが、現在の作業に合うスキルを決めるルーターとして機能する - これは harness engineering の教訓をスキル単位に適用したもの
- コンテキストに読み込まれるあらゆるトークンはどこかで性能を下げるため、関連するものだけをロードし、残りはディスクに置いておくべき
- 段階的開示 は、20個のスキルライブラリを 5K-token スロットに収めつつ、全体のコンテキストを汚染しないための方法
-
5. スコープ規律
- メタスキルは「依頼されたことだけを触る」という交渉不可能な原則をエンコードしている
- 隣接システムをリファクタリングせず、完全に理解していないコードを削除せず、TODO を見てファイル全体を書き直すと決めないようにする
- エージェントはバグを1つ直すつもりで、無関係な3ファイルを近代化しようとすることがある
- スコープ規律 は、エージェントの PR がマージ可能か、それとも差し戻すべきかを分ける最大の決定要因
- これは、1つの PR が複数の仕事をしているとレビュアーが止められる Google のコードレビュー規範ともよく合う
Google のエンジニアリング慣行との接続
- Agent Skills には Software Engineering at Google と Google の公開エンジニアリング文化から来た慣行が多く反映されている
- Google 規模のソフトウェアを機能させる多くの要素は公開文書として残っており、まさにその部分をエージェントがもっとも頻繁に飛ばす
-
スキルと慣行の対応
api-and-interface-design: Hyrum’s Law を反映。API の観測可能なあらゆる動作には最終的に誰かが依存するため、それを考慮して設計すべきtest-driven-development: テストピラミッド~80/15/5と Beyoncé Rule を反映。「好きならテストを書いたはずだ」という原則で、インフラ変更ではなくテストがバグを捕まえる- テストにおける DAMP over DRY: Google のテスト哲学では、テストコードは多少重複しても仕様のように読めるべきとされる。過度に抽象化されたテストは既知のアンチパターン
code-review-and-quality:~100-line PRのサイズと、Critical / Nit / Optional / FYI の深刻度ラベルを反映。大きな PR は実際にはレビューされず、形式的に承認されがちcode-simplification: Chesterton’s Fence を反映。なぜそれがそこにあるのか理解する前に取り除くべきではないgit-workflow-and-versioning: trunk-based development と atomic commits を反映ci-cd-and-automation: Shift Left と feature flags を反映。問題は可能な限り早く見つけ、デプロイとリリースは分離すべきdeprecation-and-migration: code-as-liability を反映。維持するすべての行は永遠に管理対象になるため、より小さい表面積を好むべき- これらの概念は新しいものではないが、エージェントには標準搭載されていない
- frontier model が学習データで “Hyrum’s Law” という言葉を読んでいたとしても、深夜3時に API を設計するとき自動的に適用するわけではない
- スキルは、こうした慣行をエージェントが実作業の中で適用できるようにする
実際の使い方
-
方法 1: marketplace でインストール
- Claude Code を使っているなら、次のコマンドでインストールする
/plugin marketplace add addyosmani/agent-skills /plugin install agent-skills@addy-agent-skills- インストールすると
/spec、/plan、/build、/test、/review、/ship、/code-simplifyの slash command を使える - エージェントがコンテキストに応じて関連スキルを自動で有効化する
- ほとんどのユーザーには、この方法から始めることが推奨される
-
方法 2: 好きなツールに Markdown を入れる
- スキルは frontmatter 付きの通常の Markdown ファイル
- Cursor ユーザーは
.cursor/rules/に入れられる - Gemini CLI には独自のインストールパスがある
- Codex、Aider、Windsurf、OpenCode、システムプロンプトを受け取れるその他のツールでも読める
- 重要なのはツールそのものより、その下にあるワークフロー
-
方法 3: 仕様書のように読む
- 何もインストールしなくても、スキルは AI エージェントと共に良いエンジニアリングを行う方法を文書化した説明として読める
code-review-and-quality.mdを読んで、5軸フレームワークをチームのレビュー工程に適用できるtest-driven-development.mdを読んで、「先にテストを書くべきか」といった議論に活用できる- メタスキルを読んで、5つの交渉不可能な原則を自分の
AGENTS.mdに持ち込める - 現在もっとも痛い問題に近いスキルを4〜5個選び、強制したいワークフローを決めたうえで、ランタイムを導入するか自作して強制する流れが出発点になりうる
インストールしなくても持ち帰れるパターン
-
反合理化をチーム慣行にする
- チームが自分たちに対してつく嘘を書き出すべき
- 例としては「リリース後にテストを直す」「この変更は小さすぎて設計書は不要」「監視があるから大丈夫」といった文
- 各文に反論を添えて
AGENTS.mdやエンジニアリング wiki に入れれば、議論を減らし、金曜午後の疲れた近道を防げる
-
内部文書は散文よりプロセスで書く
- 「私たちは X にどう取り組むか」という 2,000 語の文書を書いているなら、それは参照資料を書いているにすぎない
- それをチェックポイント付きのワークフローに変えれば、文書は 400 語に縮み、実際に実行される可能性が高まる
- この原則はオンボーディングガイド、ランブック、エージェントスキルすべてに当てはまる
-
検証を強固な終了条件にする
- すべての作業の最後の段階は「証拠の生成」であるべき
- エージェント、エンジニア、個人作業のいずれにも当てはまる
- 証拠とは、グリーンのテスト実行、スクリーンショット、ログ、レビュー承認のように、作業が終わったことを示せるものならよい
- 証拠がなければ作業は終わっておらず、「もっともらしく見える」ではループを閉じられない
-
あらゆるルール集に段階的開示を適用する
- 50ページのハンドブックを書くのではなく、状況に応じた小さな章へ送る小さなルーターを書くべき
- これは
AGENTS.md、ランブック、障害対応プレイブック、プレッシャー下で読むあらゆる文書に当てはまる
-
AGENTS.mdに入れるべき5つの交渉不可能な原則- 構築前に前提を明示しなければならない。黙って維持された誤った前提は、もっとも一般的な失敗モード
- 要件が衝突したら止まって尋ねるべき。推測してはならない
- 必要なときは反対すべき。エージェントもエンジニアもイエスマンではない
- 退屈で明快な解法を優先すべき。賢さは高くつく
- 依頼されたことだけを触るべき
harness の中での位置づけ
- スキルは、より大きな視点では agent harness engineering の1レイヤー
- harness はモデルとその周囲に構築したすべてを含み、スキルはシステムプロンプトに段階的に開示される再利用可能なワークフロー断片
- スキルは
AGENTS.md、hooks、tools、session log と並ぶAGENTS.md: 継続的に更新されるルール集の役割- hooks: 決定論的な強制レイヤー
- tools: エージェントが実行できる行動
- session log: 継続するメモリ
- skills: シニアエンジニアリングのプロセスを担う
- スキルはチャット型エージェントよりも long-running agents でより重要になる
- 長時間実行は、あらゆる近道を増幅する
- 10分のセッションでテストを飛ばしたエージェントは、1つのバグを作るかもしれない
- 30時間のセッションでテストを飛ばしたエージェントは、実行の終わりには元の意図を誰も覚えていないデバッグ考古学を生みかねない
- 実行時間が長いほど、シニアエンジニアリングのスキャフォールディングは提案ではなく強制として適用されるべき
- スキル形式の移植性も重要
- 同じ
SKILL.mdファイルは Claude Code、rules を使う Cursor、Gemini CLI、Codex、システムプロンプトのコンテンツを受け取れる他の harness で使える - ワークフローを一度書けば、ランタイムがそれを強制でき、これが bespoke prompt engineering と違って Markdown-with-frontmatter 形式がもたらす利点
結論
- AIコーディングエージェントは、diff に現れない仕事への勘を持たない、非常に有能なジュニアエンジニアのように振る舞う
- 前提の明示、変更サイズの調整、仕様作成、証拠の記録、レビュー不能な変更のマージ拒否といったシニアエンジニアリングの仕事は、エージェントが飛ばせないようにしなければ飛ばされる可能性が高い
- 今後ますます重要になるのは、こうした規律をエージェントが言葉で言い逃れできない形にエンコードすること
- スキルはその1つの形であり、反合理化テーブル、段階的開示、散文よりプロセス、終了条件としての検証、そしてすでに機能している Google の慣行を移植可能にした構造が中核にある
- Agent Skills リポジトリ は MIT ライセンスで公開されており、より広いスキャフォールディングの視点は Agent Harness Engineering と Long-running Agents に続いている
1件のコメント
Hacker News のコメント
いかがわしい万能薬に近い。読む価値はあるしもっともらしく見えるが、それでも結局はいかがわしい万能薬だ
理由は、スロットマシンのようなモデルが
AGENTS.md、memory.md、数十個のスキル用Markdownに書かれた必須要件をいつでも落としうるし、事実上そうなることが保証されているからだこうしたハーネス的アプローチは、LLMが厳格かつ完璧にルールに従い、問題はルールを十分に明確に、十分な量だけ書けていないことにすぎないかのように扱っている。これはLLMの動作原理に対する根本的な認識の誤りだ
結局のところ信頼できるわけではなく、比較的まだ信頼できる選択肢は人間によるレビューと監督だけで、できれば2回連続でやることだ
それ以外は全部いかがわしい万能薬で、その段階まで来ると約束された生産性向上も同じだと気づく。コードを読んで頭の中にモデルを作ることは、すでに頭の中にモデルがある状態でそれをコードに落とすことより、はるかに難しいからだ
コードリーディングはどんなコードかによるが、ほかのスキルと同じで練習すれば楽になる。昔から存在する巨大で複雑なコードベースを扱うときのように、書くコードより読むコードのほうがずっと多い状況ではよくあることだ
さらに楽になるのは、ドキュメントや過去の経験、同僚に聞くことなどを通じて、すでにコードに関する頭の中のモデルを持っている場合だ
エージェントでもこれは可能だ。普通はAIにプロンプトを入れる前にすでにコード構造をよく把握していて、作業を注意深く分割すれば生成されたコードのレビューはとても簡単になる。すでに読んだ本を読み返すような感じで、まれに何かが間違っていてもすぐ目につくので初期段階で大半を捕まえられる。どちらにせよ速度向上は大きい
でもこの数か月、spec-kit のようなこういうAIの使い方を試してきて、実際には驚くほど良かった。素晴らしいものを作れているし、仮定として挙げられている問題にはまだ遭遇していない。いつか起きるかもしれないので、そのために注意はしている
それでもある程度長く自分で使ってみた後では、単なるいかがわしい万能薬として片づけることはできない。30年以上プログラマとして働いてきたが、何が機能して何が機能しないかはかなり見極められるつもりだ
これからは「依頼する」ハーネスではなく「要求する」ハーネスを見たい。計画モードにいろと言ったのに、決められた計画手順に従わないエージェントは殺す、というようなものだ。完璧でなくても、人間が介在する今の方式よりはましなはずだ
「スキルは、状況に応じてエージェントのコンテキストに注入される frontmatter 付きのMarkdownファイル」だというが、その状況かどうかを判断するのはLLMだ
「エージェントが従う一連のステップで、証拠を作るチェックポイントがあり、明確な終了条件で終わる」とあるが、そのステップに従うかどうかを決められるのもLLMだ
$my-skillでスキルを直接呼び出せて、その場合は実際にそのスキルがコンテキストへ注入される。その後は、LLMがプロンプトや指示、コンテキストのほかの部分に従うのと同じ程度に、そのスキルにも従うみんなが1年以上エージェントをいじくり回した末に、感じていたのは偽の生産性だけだったと気づく日が来るのが楽しみだ
自分の実体験とはまったく一致しない。AIコーディングの必然的な没落をそこまで確信するに至った経験が何なのか知りたい。AIが道徳的に悪いという哲学的信念なのか、それとも実際にAIで何かを作り、十分に試したうえで強い結論に至ったのかを知りたい
30年以上ほぼ毎日コードを書いていて、20年以上それを仕事にしてきた。流行が来ては消えるのも見てきたし、働き方を本当に変えた進歩も何度も見てきた。AIでより多くのプロジェクトを作るほど、これはソフトウェアの作り方とコンピュータの使い方における持続的で根本的な変化だという確信が強くなる
AIが良くなっていくのも見てきたし、実際の仕事を終わらせることに自分がより熟達していくのも見てきた。その作業はすでに現実世界の本番負荷で検証されている。起きていることが嫌いだったり、AIと働く感覚が嫌いだったりはするだろうが、だからといってそれが人々に実際の価値を与え、実際の仕事をしていないという意味にはならない
こちらは9月ごろから Claude Code に全面的に移行していて、改善をきちんと追跡できている。実際に本番で使われる機能をデプロイしている。インフラ側も、ビジネスロジックの実装も、フロントエンドもバックエンドも同様だ
みんながそんなふうに時間を無駄にしているとは思わない。ただ、こういう投稿の大半はたわごとだという点には同意するし、これもその一つだ。それでもAI開発は世界中の多くの会社ですでに起きている
エージェント型ワークフローはまだそこまで到達していないと思うが、手動で呼び出してAIと並走する形で使うスキル実装は確かにかなり良い。うちの会社では最近、サンドボックス化と安全なスキルにかなり力を入れている
機能開発はまだうまく捉えられていないと思うが、書いてあるレビュー用スキルとGrafana スキルはかなりしっかりしていた
以前、もっと大きなエージェント用スキルの詰め合わせを使ってみたが、やろうとすることが多すぎて時間の無駄に感じた。Vim のようにスキルをIDEごと丸ごと導入するより、コミュニティから必要なものを選んで使うほうがよいことが多い
スキルは開発者やチームごとに違うので、あまりに個人的だ。他人の設定を大量に入れるより、自分の設定を作るための参考資料として扱うほうがいい
検索最適化やLLM最適化の観点で見ると、名前を変えない限りこうしたスキルの発見可能性は厳しそうだ: https://agentskills.io/
Addy が見ていたら、これを Superpowers と比べてどう説明するのか気になる: https://github.com/obra/superpowers
superpowers より前からエージェント開発をやっていたが、自分で作ったプロセスの50%以上が今では superpowers でカバーされているように見えて不安になる
もう GitHub スターは信用していない。誰か教えてほしい。superpowers は今や本当に採用されているのか？ 本当に価値があるなら、なぜ Boris はまだその概念を統合していないのだろう？
「やっていることにそのスキルが適用される可能性が1%でもあると思うなら、そのスキルを必ず呼び出さなければならない」
なぜみんな自分の仕事をなくすことにそんなに乗り気なのかわからない
こういうものや、何らかの“スキル”が本当にそうするわけではないにしても、原理的にはそうだ。これは労働からの疎外が大規模に進んでいるように見える
人類は追跡可能な限りずっと、一定の産出を得るのに必要な労働を減らしてきた。それが文明だ。使う労働を最大化するために、鍬で手作業の農業をしていた時代に戻るべきなのか？ 街灯を一本ずつ点けていた時代に戻るべきなのか？
自動化で遅れた社会はより貧しくなり、最終的には死ぬ。その場所に生まれた人でさえ、生産性の高い場所へ去っていくからだ。東欧でも、Amish でも、移民が発生する貧しい社会ならどこでも起きてきた。より少ないものでより多くを成すことは常に面白いことだった
作るすべての自動化について、こう感じるのか気になる。昔ながらのシステム管理者の中には、インフラ自動化の発展をこう見る人たちもいて、以前は手作業だったことをスクリプトやシステムに任せるのを嫌がっていた
うちのチームはある職場で3万台のサーバーに自動でパッチを当て、本番から自動で外して戻す自動パッチシステムを作った。全工程が手離れし、以前はその工程を手動で回す専任チームがいた。自動化で彼らの仕事を奪ったのか？
ある意味ではそうだが、ほかにやるべき仕事はあり、いまではそれができるようになった
プログラミングやコンピュータや技術が好きな理由は、まさに自分たちの代わりに仕事をしてくれるからだ。私のユートピアは、ロボットがつらい仕事をすべてやって、人間は自分のやりたいことをできる世界だ。AIはその方向へさらに一歩進ませてくれている。人間が望んでもいない仕事をして忙しくしていられるだけの仕事を残すことよりも、ロボットが仕事を奪う恩恵を裕福な所有者だけでなく世界中が享受できる方法に集中したい
今はすべてがどの方向に進化するのか明確ではないので、人々は自分のデータをランダムなエージェントに渡してみたり、コンテキストを保存してアクセスする方法を探したり、プロンプトを再利用したり、この技術を扱うためのさまざまな試みをしている
この大半は、1年後には次世代モデルに深く統合されて無用になるかもしれない。それでも進歩に追いつくことは、この分野で働く楽しさの一部だった
長期データが、平均的には生産性向上が限定的であり、最先端の高性能モデルに支援されても質の高いソフトウェアを作るには依然として細心さと人間の注意が必要だと示せば、賛成派も反対派も少し驚くだろうと思う
やっていることは同じで、ドライバーの代わりに電動ドリルを持つようになっただけだ。何百年も持つ家を建てる人もいれば、そうでない人もいる
最近こういう話をよく聞く。開発者チームの管理に効くことは、LLMの管理にも効くという話だ
良いテストケース、明確で簡潔なドキュメント、CI/CD、ベストプラクティス、オンボーディング資料がそれに当たる
LLMを管理することは、だんだん人間のチームを管理することに近づいている
これが spec-kit と比べて何がより良いのか、あるいは何が違うのか気になる。思想はかなり似て見えるし、一緒に使えるのかも気になる。あるいは単なる重複なのだろうか？
https://github.com/github/spec-kit
いくつかのスキルがこんなに長いことに驚いた。表やチェックボックスの一覧、コード例などで何ページにもわたっている
これがどれくらい一般的なのか気になる。こういうのが数個あるだけでも、かなりコンテキストを埋めそうだ
面白い実験がある。LLMに漠然と見覚えのあるものを書かせればいい。たとえば「write a fib」と頼むと、ほぼすべてのLLMはコードで微調整されているので、非プログラマにとっては「たわいない嘘を書け」という意味かもしれないのに、フィボナッチ数列のアルゴリズムで返してくる
つまり圧縮が起きている。フィボナッチ数列が正確に何かを詳しく説明しなくても、曖昧な3トークンだけで結果を表現できる
だからプロンプトの長さは重要ではないとわかる。重要なのは正しい単語、その頻度、順序だ。2ページのプロンプトと2文のプロンプトが同じ結果を出すこともある
今のところは短くて焦点の定まったスキルでうまくいっている。再利用可能なコンテキスト断片のように扱いつつ、小さく保っている。たとえば、自分のプロジェクトで Python をどう使い、ユニットテストをどう実行するかについて数段落書いた程度だ
また、エージェントに指示を出すのではなく、必要に応じて引き上げられる有用なコンテキスト情報だけを入れた短い “info” スキルもいくつかある
スキルが多すぎるのも問題になりうる。スキル名と説明の一覧が、結局はある時点でコンテキストに入るからだ
小さめのLLMコンテキストである128kでも約10%程度で、大きなモデルの1Mコンテキストウィンドウならほとんど目立たない
もしかすると私はここでは保守的すぎるのかもしれない。まだ探る余地がある
「シニアエンジニアの仕事の大半は diff に現れない部分だ」
Agent Skills は Addy がその仕事まで消し去ろうとする試みだ。乾杯、Addy :P