実装が一段落したら、PR本文を課題・解決策・テスト結果・レビュー観点の 形に整形して下書きし、承認を取ってからGitHubへ投稿する。「PRを作って」と 頼まれたときに使う。
plan
機能追加や仕様変更の要件を確認し、設計・テスト・実装順を含むプランを作る。プラン作成や実装前の設計を依頼されたときに使う。
含まれるファイル(1)
- SKILL.md2.7 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
変更プランを作る
依頼文と後続工程はagents/prompts/workflow.mdを参照する。
1. 変更の前提を調べる
AGENTS.md、agents/README.md、該当ルールを読む。関連する要件、既存の入口、業務処理、データ操作、テストを確認する。
調査した事実と、まだ確認できていないことを分ける。「新規ファイルだから影響なし」と判断せず、既存の呼び出し元と共有データも確認する。
2. 合格条件と範囲を決める
目的、受け入れ条件、スコープ外を整理する。正常系に加え、境界値、異常系、権限による違いを確認する。
プランを書き始める前に、技術面・エッジケース・トレードオフの質問をユーザーへ行う。例えば「ファイルを取り込む」だけでは、不正な行を含むときの処理が決まらない。「全件拒否」か「不正な行だけ拒否」かを確認する。実装の選択を左右する未確定事項はユーザーへ確認する。
3. プランを保存する
agents/plans/template.mdをコピーし、変更内容がわかる名前で同じフォルダへ保存する。概要、背景、詳細設計、既存テストへの影響、新規テスト、実装順、検証コマンド、スコープ外を記入する。
変更するファイルと責務を具体化する。要件IDと詳細設計・テスト・実装順を対応づける。機能要件と、今回に関係する非機能要件を確認する。実装順は依存関係と、小さく検証できる単位で決める。各タスクをどのモデル・サブエージェントに任せるかも記載する。単独で進める場合もその旨を明示する。
4. 自己確認して報告する
受け入れ条件の実装漏れ、範囲外の混入、テストの欠落を照合する。プランの保存先、主要な判断、要確認事項を報告する。
完了条件は、実装者がプランから変更と検証を開始でき、未確定の判断を識別できることである。プラン作成だけの依頼では実装を始めない。別セッションによるプランレビューと、テスト網羅の確認へ渡す。自己確認だけでレビュー済みとは扱わない。
エラー時
資料の取得や調査に失敗したら、不足する情報と影響を報告する。存在しない構成やコマンドを補作しない。ユーザーの判断が必要な仕様は、候補と影響を示して確認する。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
PRを出す前に、自分のgit diffをGoogle Engineering Practicesの チェックリストでセルフレビューする。実装が一段落して、commit・push・PRの 直前に使う。
実装差分を要件・プラン・開発ルールと照合してレビューする。コードレビューや実装レビューを依頼されたときに使う。
Sentryのイシューを調査して修正する。リンク・ID・検索でイシューを 特定し、スタックトレース・ブレッドクラム・トレース・ログの全コンテキストを 取得し、根本原因を特定して修正・解決する。
テスト駆動開発で機能追加・バグ修正を実装する。テストリストから 1件ずつRed、最小のGreen、Refactorを回す。ユーザーがTDD・テスト駆動・ Red-Green-Refactorを指定したときに使う。テストの後付けだけの依頼には使わない。