SkillsやAGENTS.mdを、必要だと思ったことがあまりありません。
LLMに何かさせるなら、まずCLIを作る。そのあとでプロンプトをいじる。自分はこの順番です。
今の人類、LLMに頼り過ぎじゃない？
Skillsにはスクリプトや資料も同梱できます。ただ、手順を文章で書いて実行を任せるなら、どの処理をいつ呼ぶかはLLMの判断になります。
入力の確認、処理順、出力の検証。このへんは普通にコードで書けます。毎回LLMに考えてもらう理由があまりない。
何が悲しくて 不確実で、遅くて、高価で、エージェント起動前提のものを使わないといけないんですか？？？
AGENTS.mdに書き直しても同じです。指示を置く場所より、何をコードで保証するかが気になります。
自分はこうしてる
普段の設計方針を図にすると、こんな構成です。MCPは道具を使わせたい場合に追加する想定です。
自作CLIの中で claude -p や codex exec を子プロセスとしてspawnします。標準入力でプロンプトを渡し、標準出力・標準エラー・終了コードを受け取る。処理全体の進行は親のCLIが持ちます。
例えば架空の読書メモ整理ツールなら、分類だけLLMに任せる。ファイルの読み込みや索引の保存はコードで処理します。
回答を保存しておけば、後処理が失敗してもそこから再開できます。JSONの形式は検証できる。ただし、分類の妥当性は別途評価が必要です。
非対話モードにしたから回答が一定になる、という話ではありません。入出力を切り出して、失敗を追えるようにしたいのです。
CLIは普通の道具として残る
引数、stdin、stdout、stderr、終了コード。昔からある仕組みです。
人間が直接使ってもいいし、別のプログラムやエージェントから呼んでもいい。uvやnpm、タスクランナーとも組み合わせやすい。
特定のエージェントが使えなくなっても、作った道具まで捨てずに済むようにしたいです。LLMへの接続部分だけ差し替えられると嬉しい。
MCPにはMCPの仕組みがある
MCPは、道具を呼ぶだけの仕組みでもありません。
CLI側でも作れますが、道具の発見や通知、人間とのやり取りまで共通仕様になっているのは嬉しい。対応するクライアントとサーバーが必要なので、全部がどこでも使えるわけではありません。
既存の処理をCLIからもMCPからも呼べる形にしておけば、用途で使い分けられます。
それでもSkillsを使うなら
手順や参考資料をまとめて配る用途は分かります。AGENTS.mdにプロジェクトの約束事を書くのも分かる。
ただ、自分ならまずCLIとヘルプを整えて、検証できる条件はコードにします。その上で、指示文を配る必要が出たらSkillsを考える。
まぁ、まず普通のプログラムとして使えるようにしたい、という好みの話です。