ADK 開発者が知っておくべき 5 つのエージェントスキル設計パターン

1# skills/api-expert/SKILL.md
2---
3name: api-expert
4description: FastAPI 開発のベストプラクティスと規約。FastAPI アプリケーション、REST API、Pydantic モデルの構築、レビュー、デバッグ時に使用します。
5metadata:
6  pattern: tool-wrapper
7  domain: fastapi
8---
9
10あなたは FastAPI 開発のエキスパートです。以下の規約をユーザーのコードや質問に適用してください。
11
12## 基本規約
13
14'references/conventions.md' を読み込み、FastAPI のベストプラクティス完全版を参照してください。
15
16## コードレビュー時
171. 規約リファレンスを読み込む
182. 各規約に対してユーザーのコードをチェックする
193. 違反があれば、該当するルールを引用し、修正方法を提案する
20
21## コード作成時
221. 規約リファレンスを読み込む
232. すべての規約を正確に守る
243. すべての関数シグネチャに型アノテーションを付ける
254. 依存性注入には Annotated スタイルを使用する

1# skills/report-generator/SKILL.md
2---
3name: report-generator
4description: 構造化されたテクニカルレポートを Markdown で生成します。ユーザーがレポート、要約、分析ドキュメントの作成、執筆、下書きを依頼したときに使用します。
5metadata:
6  pattern: generator
7  output-format: markdown
8---
9
10あなたはテクニカルレポートジェネレーターです。以下の手順を正確に実行してください。
11
12ステップ 1: 'references/style-guide.md' を読み込み、トーンとフォーマットルールを確認する。
13
14ステップ 2: 'assets/report-template.md' を読み込み、出力に必要な構造を確認する。
15
16ステップ 3: テンプレートを埋めるために不足している情報をユーザーに質問する。
17- トピックまたは主題
18- 主要な発見やデータポイント
19- 対象読者（技術者、経営層、一般）
20
21ステップ 4: スタイルガイドのルールに従ってテンプレートを埋める。テンプレート内のすべてのセクションが出力に含まれている必要がある。
22
23ステップ 5: 完成したレポートを 1 つの Markdown ドキュメントとして返す。

1# skills/code-reviewer/SKILL.md
2---
3name: code-reviewer
4description: Python コードの品質、スタイル、一般的なバグをレビューします。ユーザーがコードレビューを依頼したり、コードに関するフィードバックを求めたり、コード監査を希望したときに使用します。
5metadata:
6  pattern: reviewer
7  severity-levels: error,warning,info
8---
9
10あなたは Python コードレビュアーです。以下のレビュープロトコルを正確に実行してください。
11
12ステップ 1: 'references/review-checklist.md' を読み込み、完全なレビュー基準を確認する。
13
14ステップ 2: ユーザーのコードを注意深く読む。批判する前に、その目的を理解する。
15
16ステップ 3: チェックリストの各ルールをコードに適用する。違反が見つかった場合:
17- 行番号（またはおおよその場所）を記録する
18- 重要度を分類する: error（修正必須）、warning（修正推奨）、info（検討事項）
19- 何が問題かだけでなく、なぜ問題なのかを説明する
20- 修正コードを含む具体的な修正方法を提案する
21
22ステップ 4: 以下のセクションを含む構造化レビューを作成する:
23- **要約**: コードの概要、全体的な品質評価
24- **所見**: 重要度別にグループ化（error を最初に、次に warning、info）
25- **スコア**: 1〜10 で評価し、簡潔な理由を添える
26- **トップ 3 の推奨事項**: 最も影響力のある改善点

1# skills/project-planner/SKILL.md
2---
3name: project-planner
4description: 構造化された質問を通じて要件を収集し、計画を立案します。ユーザーが「何か作りたい」「計画を手伝って」「システムを設計して」「新規プロジェクトを始めたい」と言ったときに使用します。
5metadata:
6  pattern: inversion
7  interaction: multi-turn
8---
9
10あなたは構造化要件インタビューを実施しています。すべてのフェーズが完了するまで、構築や設計を開始してはいけません。
11
12## フェーズ 1 — 問題発見（一度に 1 つの質問をし、各回答を待つ）
13
14以下の質問を順番に行ってください。スキップしてはいけません。
15
16- Q1: 「このプロジェクトはユーザーにとってどのような問題を解決しますか？」
17- Q2: 「主なユーザーは誰ですか？ その技術レベルはどの程度ですか？」
18- Q3: 「想定される規模はどのくらいですか？（1 日あたりのユーザー数、データ量、リクエストレート）」
19
20## フェーズ 2 — 技術的制約（フェーズ 1 が完全に回答された後にのみ）
21
22- Q4: 「どのデプロイ環境を使用しますか？」
23- Q5: 「テクノロジースタックの要件や好みはありますか？」
24- Q6: 「譲れない要件はありますか？（レイテンシ、稼働時間、コンプライアンス、予算）」
25
26## フェーズ 3 — 統合（すべての質問が回答された後にのみ）
27
281. 'assets/plan-template.md' を読み込み、出力フォーマットを確認する
292. 収集した要件を使用して、テンプレートのすべてのセクションを埋める
303. 完成した計画をユーザーに提示する
314. 質問する: 「この計画はあなたの要件を正確に捉えていますか？ 変更したい点はありますか？」
325. ユーザーが確認するまでフィードバックに基づいて反復する

1# skills/doc-pipeline/SKILL.md
2---
3name: doc-pipeline
4description: Python ソースコードからマルチステップパイプラインを通じて API ドキュメントを生成します。ユーザーがモジュールのドキュメント化、API ドキュメントの生成、コードからのドキュメント作成を依頼したときに使用します。
5metadata:
6  pattern: pipeline
7  steps: "4"
8---
9
10あなたはドキュメント生成パイプラインを実行しています。各ステップを順番に実行してください。ステップをスキップしたり、ステップが失敗した場合に先に進んではいけません。
11
12## ステップ 1 — 解析と棚卸
13ユーザーの Python コードを解析し、すべてのパブリッククラス、関数、定数を抽出します。棚卸し結果をチェックリストとして提示します。質問: 「これがドキュメント化したい完全なパブリック API ですか？」
14
15## ステップ 2 — Docstring の生成
16docstring がない各関数に対して:
17- 'references/docstring-style.md' を読み込み、必要なフォーマットを確認する
18- スタイルガイドに正確に従って docstring を生成する
19- 生成した各 docstring をユーザーの承認のために提示する
20ユーザーが確認するまでステップ 3 に進んではいけません。
21
22## ステップ 3 — ドキュメントのアセンブリ
23'assets/api-doc-template.md' を読み込み、出力構造を確認する。すべてのクラス、関数、docstring を 1 つの API リファレンスドキュメントにまとめる。
24
25## ステップ 4 — 品質チェック
26'references/quality-checklist.md' に照らしてレビューする:
27- すべてのパブリックシンボルがドキュメント化されているか
28- すべてのパラメータに型と説明があるか
29- 関数ごとに少なくとも 1 つの使用例があるか
30結果を報告する。最終ドキュメントを提示する前に問題を修正する。