メニュー
ユーザーの要望から実装前の設計書または実装計画を作成する。ユーザーが「設計書を作って」「実装計画を立てて」「plan-create」「方針をまとめて」「AIエージェント向けの実装手順にして」などを依頼したとき、またはコード変更前に安全で検証可能な計画を文書化する必要があるときに使う。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Kaggle MCPでCompetition、Dataset、Model、Notebook出力、Notebookソースを取得し、リポジトリの./input配下へ安全に配置する。ユーザーが「コンペを開始」「COMPETITIONのデータを取得」、またはKaggleのDataset・Model・Notebookを「import」「download」「inputへ追加」するよう依頼したときに使う。
Kaggle MCPのdiscussion/forum系ツールでKaggle Discussion、Competition Solution、コメント、返信を調査し、docs/discussion/*.mdへ根拠付きで要約する。ユーザーが「XXXの1位解法を調査」「YYYの上位解法をまとめて」「参加中コンペの有用Discussionを調査」「このコンペのdiscussionから実装ヒントを拾って」など、Kaggle discussionやsolution writeupの調査・整理を依頼したときに使う。
環境変数COMPETITIONのKaggleコンペを開始するため、参加・データ取得、公式ページと厳密なルールの文書化、Discussionと公開Notebookの動向調査、最高voteのEDA Notebook導入とMarkdownセルの日本語化を統括する。ユーザーが「コンペをオンボーディング」「新しいKaggleコンペを開始」「コンペ情報・ルール・流行手法をまとめて」「EDAまで用意」などを依頼したときに使う。
Kaggle MCPで公開Notebook/Kernelを検索し、fork親子関係、重複、派生、public score、利用データ・モデル・出力物、コード本文を根拠付きで調査してMarkdownにまとめる。ユーザーが「公開ノートブックを調査」「似たNotebookの違いを見たい」「BirdCLEFなど参加中コンペのnotebookから実装ヒントを拾って」「高スコアNotebookの派生元を追って」「Kaggle Notebookの重複・fork・改善点を整理して」などを依頼したときに使う。
現在の Git worktree の変更を確認し、必要なら複数の論理コミットへ分割して安全にコミットする。ユーザーが「commitして」「今の変更をコミット」「何個かに分けてコミット」「とりあえずcommit」「変更を保存して」などを依頼したとき、または作業完了後にローカル変更をレビュー可能な commit にまとめたいときに使う。
現在の Git リポジトリで新しいブランチを安全に作成して切り替える。ユーザーが「新しいブランチ作って」「branch切って」「この作業用ブランチを作成」「featureブランチを作って」などを依頼したとき、または作業開始前に現在地点から専用ブランチへ移りたいときに使う。
| name | plan-create |
| description | ユーザーの要望から実装前の設計書または実装計画を作成する。ユーザーが「設計書を作って」「実装計画を立てて」「plan-create」「方針をまとめて」「AIエージェント向けの実装手順にして」などを依頼したとき、またはコード変更前に安全で検証可能な計画を文書化する必要があるときに使う。 |
ユーザーの要望を、実装担当AIエージェントがそのまま使える設計書に変換する。
設計書は .agents/docs/templates/plan-template.md を必ず参照し、最小変更、安全性、検証可能性、未解決事項を明示する。
設計書を作る前に、リポジトリルートから次を全文読む。
.agents/skills/plan-create/docs/plan-template.mdテンプレートが存在しない場合は、作業を止めてユーザーに知らせる。別形式で勝手に代替しない。
context() MCP が使える環境では resolve_library-id、get-library-docs の順で確認する。使えない場合は公式ドキュメント検索で代替し、代替した事実を設計書に書く。.agents/docs/templates/plan-template.md の章立てを維持し、不要な章は削除せず 該当なし または理由を書く。未解決事項 に書き、必要ならユーザーに確認する。./docs/plans/<YYYYMMDD>-<short-slug>-design.md に書く。最後に次だけを短く報告する。