agent-skills - AIコーディングエージェント向けのプロダクショングレードなエンジニアリングスキル集

 (github.com/addyosmani)
124 ポイント 投稿者 xguru 22 일 전 | 7件のコメント | WhatsAppで共有
  • AIコーディングエージェントが仕様・テスト・セキュリティレビューを飛ばしてしまう問題を解決するために、Google Cloud AIディレクターのAddy Osmaniがシニアエンジニア水準のワークフローを構造化されたスキルとしてパッケージ化したオープンソース
  • 開発ライフサイクル全体（定義→計画→ビルド→検証→レビュー→デプロイ）に対応する7つのスラッシュコマンドと19個のスキルで構成
    • /spec 何を作るかを定義: "コードの前に仕様"
    • /plan 実装方法を計画: "小さなアトミックタスクへ"
    • /build 段階的に実装: "一度に1スライスだけ"
    • /test 動作を証明: "テストは証拠"
    • /review マージ前の品質ゲート: "コードヘルスを改善"
    • /code-simplify コードを簡素化: "賢さより明快さ"
    • /ship 本番デプロイ: "速いほど安全"
  • 状況に応じて適切なスキルが自動有効化される。例: API設計時はapi-and-interface-design、UI実装時はfrontend-ui-engineeringなど
  • Googleエンジニアリング文化の中核原則（Hyrum's Law、Beyonce Rule、Chesterton's Fence、Shift Leftなど）が段階別ワークフローに直接組み込まれている

19個のスキル一覧

  • Define（何を作るかの明確化）

    • idea-refine: 発散・収束思考を構造化し、漠然としたアイデアを具体的な提案へ変換
    • spec-driven-development: コードを書く前に、目標・コマンド・構造・コードスタイル・テスト・境界を含むPRDを作成

  • Plan（分解）

    • planning-and-task-breakdown: 仕様を受け入れ基準と依存関係の順序を備えた、小さく検証可能なタスクへ分解

  • Build（コード作成）

    • incremental-implementation: 薄い垂直スライス方式で実装・テスト・検証・コミットを行い、フィーチャーフラグとロールバックに適した変更を支援
    • test-driven-development: Red-Green-Refactor、テストピラミッド（80/15/5）、DRYよりDAMP、Beyonce Ruleを適用
    • context-engineering: 正しい情報を正しいタイミングでエージェントに提供（rulesファイル、コンテキストパッキング、MCP統合）
    • frontend-ui-engineering: コンポーネントアーキテクチャ、デザインシステム、状態管理、レスポンシブデザイン、WCAG 2.1 AAアクセシビリティ
    • api-and-interface-design: 契約先行設計、Hyrum's Law、One-Version Rule、エラーセマンティクス、境界バリデーション

  • Verify（動作の証明）

    • browser-testing-with-devtools: Chrome DevTools MCPによるリアルタイムランタイムデータ（DOM検査、コンソールログ、ネットワークトレース、パフォーマンスプロファイリング）
    • debugging-and-error-recovery: 5段階トリアージ（再現→局所化→縮小→修正→防御）、stop-the-lineルール

  • Review（マージ前の品質ゲート）

    • code-review-and-quality: 5軸レビュー、変更規模（約100行）、重大度ラベル（Nit/Optional/FYI）、レビュー速度基準
    • code-simplification: Chesterton's Fence、Rule of 500、正確な動作を保ったまま複雑さを削減
    • security-and-hardening: OWASP Top 10の予防、認証パターン、シークレット管理、依存関係監査、3層境界システム
    • performance-optimization: 測定優先アプローチ、Core Web Vitals目標、プロファイリングワークフロー、バンドル分析

  • Ship（デプロイ）

    • git-workflow-and-versioning: トランクベース開発、アトミックコミット、変更規模（約100行）、コミットをセーブポイントとして使うパターン
    • ci-cd-and-automation: Shift Left、Faster is Safer、フィーチャーフラグ、品質ゲートパイプライン
    • deprecation-and-migration: コードを負債として捉えるマインドセット、強制的・推奨的な廃止方式、ゾンビコードの削除
    • documentation-and-adrs: Architecture Decision Records、APIドキュメント、インライン文書化基準（"なぜ"を文書化）
    • shipping-and-launch: リリース前チェックリスト、フィーチャーフラグのライフサイクル、段階的ロールアウト、ロールバック手順、監視設定

エージェントペルソナ

  • ターゲットレビューのために3つの専門家ペルソナを事前構成
    • code-reviewer: シニアスタッフエンジニア視点、"スタッフエンジニアが承認できる水準か？"を基準にした5軸コードレビュー
    • test-engineer: QA専門家視点、テスト戦略・カバレッジ分析・Prove-Itパターン
    • security-auditor: セキュリティエンジニア視点、脆弱性検出・脅威モデリング・OWASP評価

リファレンスチェックリスト

  • スキルが必要時に参照する4つのクイックリファレンス資料
    • testing-patterns.md: テスト構造、命名、モッキング、React/API/E2Eの例、アンチパターン
    • security-checklist.md: コミット前チェック、認証、入力バリデーション、ヘッダー、CORS、OWASP Top 10
    • performance-checklist.md: Core Web Vitals目標、フロントエンド/バックエンドのチェックリスト、測定コマンド
    • accessibility-checklist.md: キーボードナビゲーション、スクリーンリーダー、視覚デザイン、ARIA、テストツール

スキル設計原則

  • プロセスであって文章ではない: スキルはエージェントが従うワークフローであり、ステップ・チェックポイント・終了基準を含み、参考文書ではない
  • 合理化を防ぐ: すべてのスキルに、エージェントが手順を飛ばす際によく使う言い訳（"あとでテストを追加します"）と、それへの反論ロジックを内蔵
  • 検証は交渉不可: すべてのスキルは証拠要件（テスト通過、ビルド出力、ランタイムデータ）で締めくくられ、"うまくいった気がする"では不十分
  • 段階的公開: SKILL.mdがエントリーポイントで、補助リファレンスは必要時にのみ読み込み、トークン使用量を最小化

インストール方法（対応ツール）

  • Claude Code（推奨）: /plugin marketplace add addyosmani/agent-skills の後に /plugin install agent-skills@addy-agent-skills
    • ローカル開発: git clone の後に claude --plugin-dir /path/to/agent-skills
  • Cursor: 任意のSKILL.mdを.cursor/rules/にコピーするか、skills/ディレクトリ全体を参照
  • Gemini CLI: gemini skills install https://github.com/addyosmani/agent-skills.git
  • Windsurf: スキル内容をWindsurf rules設定に追加
  • GitHub Copilot: agents/のエージェント定義をCopilotペルソナとして使い、スキル内容を.github/copilot-instructions.mdで使用
  • Codexおよびその他のエージェント: スキルは一般的なMarkdownなので、システムプロンプトやインストラクションファイルをサポートするあらゆるエージェントと互換性あり

関連記事

7件のコメント

 
xguru 22 일 전

最近は、自分だけのスキルセットを公開するのが流行っている感じですね

どうせMarkdownファイルなので、そのまま全部取り入れる必要はありません
増えれば増えるほどトークン消費量が増えるだけですし
自分のエージェントに「これを分析して必要なものだけ持ってこよう」と言わせるほうがいいです

そうやって自分なりのハーネスを作っていくんですよ
 
thestackai 22 일 전

その通りです。あふれるオープンソースに対応する最も良い方法だと思います。
 
yangeok 17 일 전

speckitみたいなものなんでしょうね
 
blacksocks 20 일 전

社内でバイブコーディングだけで開発してみろという指示が出て、あれこれ試してみたのですが、いざやってみると、優れた開発スキルがそのまま高い品質を保証するわけではないんですよね..
むしろAIが生み出したコードをレビューして理解する能力こそが核心のようです。ツールが良くなるほど「読んで判断する力」がより重要になるという、ある種の皮肉でしょうか。
 
ragingwind 22 일 전

Google ChromeチームのリードだったAddy Osmaniが、Director, Google Cloud AIに転職した。
 
xguru 22 일 전

あ、いつ移したんだろう。ずっとそうだと思っていました。修正しておきました
 
ragingwind 22 일 전

私ももうChromeチームで知っている人はPaul Kinlan（Chrome DevRelリード）だけですね。月日の流れは本当に早い。