この記事は、著者の Agent Skills プロジェクトの設計思想を説明するものである。AI コーディングエージェントはデフォルトで「完了」への最短経路をとり、diff には現れないシニアエンジニアの仕事、すなわち仕様を書くこと、テストを先に書くこと、レビューしやすい大きさに変更を分けること、検証できないものを出荷しないことを省略してしまう、と論じる。記事は Agent Skills を、その規律をエージェントに後付けで組み込むための足場として位置づけ、プロジェクトの土台となる 5 つの設計原則を順に解説し、そのうちいくつかを Software Engineering at Google に記録されたプラクティスに対応づけている。
記事は「スキル」をリファレンスドキュメントと区別する。スキルとは、エージェントが実際に従うことのできる、チェックポイントと明確に定義された終了条件を備えたワークフローであり、モデルが読んだうえで、根底にある作業を行わないままもっともらしい文章を生成してしまうような論説ではない。
要点
- スキルはリファレンスドキュメントではなく、チェックポイントと終了条件を備えたワークフローとして定義される。記事は、この「散文よりプロセス」という区別こそが、役に立つスキルと、実際には何も変えない Markdown ファイルとを分けるものだと論じる。
- プロジェクトは 20 のスキルを 6 つの SDLC フェーズ（define、plan、build、verify、review、ship）に沿って編成し、7 つのスラッシュコマンドを備える。ルータースキルが、あるタスクにどのスキルを適用するかを決定するため、小さな修正では複雑な機能よりも少ないスキルしか起動されない。
- 反正当化テーブル、すなわちエージェントがワークフローの手順を飛ばすために使いそうな言い訳を並べ、それぞれに文章で反論を添えた表が、プロジェクトの最も特徴的な設計上の選択として示される。これは、作業を省略するためのもっともらしい正当化を生み出すという LLM の傾向を狙ったものである。
- すべてのスキルは、「正しそうに見える」ことを十分とはみなさず、具体的な証拠（テストの成功、クリーンなビルド出力、ランタイムトレース、レビュアーの承認）で終わるとされる。
- スキルは段階的開示によって読み込まれる。すなわち、セッション開始時にすべてをコンテキストに読み込むのではなく、ルータースキルを通じてタスクのフェーズに応じて起動される。これは、使われない指示によって性能が低下するのを避けるためである。
- 交渉の余地のないスコープの規律のルール（「頼まれたものだけに手を触れる」）が、エージェントの PR を差し戻さずにマージできるかどうかに最も大きく影響するプラクティスとして示される。
- 記事は、特定のスキルを公開されている特定の Google のエンジニアリングプラクティスに対応づける。たとえば、
api-and-interface-designにおけるハイラムの法則、test-driven-developmentにおけるテストピラミッドとビヨンセ・ルール、code-review-and-qualityにおける約 100 行という PR サイズと重大度ラベル、code-simplificationにおけるチェスタトンのフェンスなどである。 - 執筆時点でプロジェクトは GitHub スターが 27,000 を超えたと報告されており、MIT ライセンスであるとされている。
背景
記事は自らを、プロジェクトの README では十分に扱われていない説明、すなわちインストール方法ではなく各設計上の選択がなぜ存在するのかの説明として位置づけている。そして Agent Skills を、著者のより広い ハーネスエンジニアリング の枠組みにおける 1 つのレイヤーとして位置づけ、AGENTS.md、フック、ツールと並んで、それぞれ固有の役割を持つ構成要素の 1 つとしている。