「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
「生成AIを活用したプログラミング」ページ中で紹介したコーディング・エージェントは、
「Master Vibe Coding with AI Coding Agents：Claude Code...」にあるように使用する。
つまり...
詳細 †
共通 †
プロダクトごとに共通
MDファイル †
- 一般的には、AGENTS.mdとPLAN.mdがある。
その他にも、SPEC.mdなど、任意のMDファイルがあっても良い。
- 実行前には、読む必要のあるMDファイルをエージェントに通知する。
- 「AGENTS.mdを参照し、SPEC.mdを生成して下さい。」（DOCフォワード）
- 「AGENTS.md、SPEC.mdを参照し、PLAN.mdを生成して下さい。」（プランニング）
- 「AGENTS.md、SPEC.mdを参照し、PLAN.mdを参照し、PLAN の Phase N を実行してください。」（コーディング）
- ファイルの配置場所
- プロジェクトに適用されるMDファイルはリポジトリ内に配置する。
- 階層が深い場合、サブ・プロジェクトのサブ・フォルダ毎に配置しても良い。
- 個人に適用されるMDファイルはユーザ・ディレクトリの.プロダクト名フォルダに配置する。
- 一般的には、AGENTS.md、PLAN.mdだが、
- Claude Codeの場合は、CLAUDE.md＝AGENTS.mdなので、
- CLAUDE.mdからAGENTS.mdをリンクするなどとすると共通化出来る。
- リンクには、MD記法（相対パスが必要）と「@」メンション（プロダクト依存）の２つがある。
- ユーザ・ディレクトリの.プロダクト名フォルダ名は
- Cursor：.cursor
- GitHub Copilot：.copilot
- Claude Code：.claude
- OpenAI Codex：.codex
- Antigravity：.agents
- コーディング基準は、
CODE_GUIDELINES.md（OSSではCONTRIBUTING.md）
- 実装ガイドは、以下の様にするのが良い。
- 概要をMDファイルをIMPLEMENTATION_GUIDE.md
- 必要に応じて詳細をスキルとして実装
タスク †
- DOCフォワード：
- 内容：
- プロンプト：「AGENTS.mdを参照し、SPEC.mdを生成して下さい。」
- プランニング：
- 内容：
- プロンプト：「AGENTS.md、SPEC.mdを参照し、PLAN.mdを生成して下さい。」
- コーディング：
- 内容：
- プロンプト：「AGENTS.md、SPEC.mdを参照し、PLAN.mdを参照し、PLAN の Phase N を実行してください。」
YOLO †
YOLOモードは、確認無しにドンドン実装が進むオートパイロット的なモード。
- レアだが危険な操作がされる可能性があるので、サンド・ボックスで実行するのが一般的。
- CLAUDE.md＝AGENTS.mdのみで、SPECやPLANはエージェントに立案させるケースが多い。
- 受入者も未知の技術を使用しPoC、MVPを実装させるケースで有用（コントロールは弱いが、シェフにお任せ的な期待ができる）。
プロ †
プロ・モードはYOLOモードでなく、都度確認を行う。
- フェーズやステップ毎に実装を細切れに実行させ、都度作業内容を検収（Gitコミット）する。
- ちなみに、SPECやPLANのブレークダウンをエージェントの助けを受けながら行っても良い。
- エンプラ開発のウォーターフォールや、サービス開発のアジャイルのプロセス中の任意の作業単位毎に実行する。
Chat †
利用の流れ †
- AGENTS.md、PLAN.md、SPEC.mdなどを与えると別途計画を立ててから実装を実行する（エージェントが別のPLAN.mdを生成する）。
- 細かくフェーズやステップを分ける場合、「PLANn.md、SPECn.mdを参照し、PLANn.mdのxフェーズ、yステップを実行してください。」などと指示すると良い。
- エージェントが生成したPLAN.mdに問題がなければ実装を実行する。計画を見るのが面倒なら実行結果を見て問題があったら、PLAN.mdにフィードバックするでも良い。
使える機能 †
CLIと同じ。ただし、CLIの「-」コマンドは使用できない。
CLI †
Chatと同じ。違いは、指示がし易い点。
- 何気に、ChatもGUIと見せかけて文字列ベースなので、その差は、一般的な GUI vs CUI と言う程でもない。
- 両方文字列ベースのI/Fだと、機能差は無くとも、CLI風のI/Fの方が柔軟性が高い（詳しくは「利用の流れ」で）。
利用の流れ †
- 基本は、Chatと同じだが、以下の点で、CLIが優れている。
- 「/」コマンドの活用
- /status：実行にあたっての様々な状態を一望できる。
- /context、/compact、/clear：などでコンテキスト管理が容易
- 実はインタラクティブ性能もCLIの方が高い。
- Chatだと基本は文字列になる。一部、Chatでの対応もされている。
- しかし、近年のCLIは「Chatでの対応」より優れたインタラクティブ機能がサポートされている。
- 疑似タブ切り替え（Tabs）
- セレクトボックス（Select / List Prompt）
- マルチセレクト / チェックボックス（Checkbox / Multi-select）
- トグル / トグルスイッチ（Toggle / Confirm）
使える機能 †
各種機能が利用可能
- MDファイル、ツール、MCP、Slashコマンド、スキル、フック、プラグイン
- フック、プラグインはClaude Code発だった。
- 今となっては、GHCのチャットUIからも機能する。
- ただし、コマンドはCLIのモノと、LLMのモノとで内容が異なる。
- CLIの「-」コマンドは所謂、CLIのコマンドとして機能する。
- LLMの「/」コマンドは、プロンプト・フローの動作に影響を与える。
機能 †
ツール †
- メイン・エージェントで使用可能なMCPサーバを追加する。
- セキュアに大規模なSaaS（GitHubやAtlassian）機能を活用する...的な文脈で使用
- 認証が必要で再認証しないとエラーになったりすることが多い（/mcp → Re-authenticateが作法"笑"）。
- 最小限のものであれば、MDファイル１つで定義可能。
- 定義中に、外部スクリプトファイルなどを含めても良い。
カスタムSlashコマンド †
以前はcommandsに実装していたが、現在はskillsに実装するようになってきている。
- この際、name属性をcommandとして利用可能な文字列にする。
- つまり、スキル ≒ カスタムSlashコマンドだが、
- skillsはcommand的に実行できない（LLMの判断による）点が異なる。
- 逆にskills的に実装したcommand（つまり適切なname属性でdescription属性がある）はLLM判断で利用される。
サブ・エージェント †
- 別のコンテキスト・ウィンドウで実行する。
- メイン・エージェントと並列で動作させることができる。
- 使用するLLM、ツール、システム・プロンプトを追加する。
- 単純作業を廉価なLLMで実行したりすると良い。
フック †
- あまり使用されない。
- イベント発生時に自動的に処理を実行するなどの目的で使用する。
参考 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
