一键导入
agent-explain-on-demand
エージェントの動作・モード・変更点・できることを、聞かれたときだけ必要な深さで説明する。Use when: ユーザーが今何をしているか、どんなモードがあるか、更新で何が変わったかを知りたがっているとき。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
エージェントの動作・モード・変更点・できることを、聞かれたときだけ必要な深さで説明する。Use when: ユーザーが今何をしているか、どんなモードがあるか、更新で何が変わったかを知りたがっているとき。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
モダン C#(12+)で record、パターンマッチング、合成、Result 型エラーハンドリングを使った 慣用的で高性能なコードを書く。こんなときに使う: 新規 C# コードの作成、API 設計、 または C# 12+ イディオムへのリファクタリング。
こんなときに使う: WPFアプリケーションに社員番号入力ダイアログを追加し、 DPAPIで暗号化された設定として社員IDを安全に保存したいとき。
こんなときに使う: 繰り返し発生する業務問い合わせ(監査、アンケート、コンプライアンス調査)に対して、 過去の回答実績とエビデンスを活用して回答するためのテンプレートスキル。 再利用可能な7ステップワークフローとスキャフォールディングファイルを提供する。
こんなときに使う: PDFテキスト抽出、Optical Character Recognition (OCR)、結合/分割、フォーム処理をuvベースの再現可能コマンドで実行したいときに使う。
こんなときに使う: Migrate Access SQL to Oracle, generate .NET C# code. Use when converting Access queries to Oracle.
こんなときに使う: .NETドメイン層で汎用的な重み付きフィールドマッチングとスコアリングを実装。
| name | agent-explain-on-demand |
| description | エージェントの動作・モード・変更点・できることを、聞かれたときだけ必要な深さで説明する。Use when: ユーザーが今何をしているか、どんなモードがあるか、更新で何が変わったかを知りたがっているとき。 |
ユーザーが聞いたときだけ、必要な分だけ答える。短い答えを先に返し、深掘りは求められてから行う。
以下のような場面で使います:
タスク作業中に 自発的に このスキルを起動しないこと。
混乱・好奇心の明示的なシグナルがあった場合にのみ使用する。
session-issue-autopilot — 自律実行セッション(「何してる?」質問の発生源になりやすい)furikaeri-practice — ふりかえり(「何が変わった?」質問が発生しやすい)github-issue-intake — Issue取り込みワークフロー(説明を求められることがある)skill — 「バリデーションって何をしてるの?」質問に対応fetch_copilot_cli_documentation(Lane Dでの CLI 能力確認用)fetch_copilot_cli_documentation を呼ぶ(温故知新)ユーザーのメッセージを読み、以下の4レーンのどれか1つに分類する。
曖昧なときは最も近いレーンを仮置きし、必要なら確認してから深掘りする。
| レーン | シグナルワード・フレーズ | 質問の種類 |
|---|---|---|
| A — 動作 | 「今何してる?」「動作がよく分からない」「なぜ〜した?」 | 現在の処理や判断理由 |
| B — モード | 「モードって何?」「モードの説明をして」「どんな動き方ができる?」「モデルは固定?」 | 動作モードの説明 |
| C — 変更点 | 「updateで何が変わった?」「最近変わった?」「何が新しい?」 | アップデート差分 |
| D — 自己紹介 | 「あなたについて知りたい」「何ができる?」「あなたは誰?」 | エージェントの正体・能力 |
Values: 基礎と型(型を見極めてから動く)
トリガー: エージェントが今何をしているか、なぜその行動を取ったか、が不明なとき。
第一層の回答パターン(3文以内):
今は〈タスク名〉を〈方法〉で進めています。
〈直前のアクション〉を行ったのは〈理由〉のためです。
続けますか、それとも別の進め方を試しますか?
深掘りの申し出: 「もう少し詳しく説明しましょうか?」
なぜ: タスク名・直前アクション・理由を先に示すと、最初の回答が具体的になる。
ユーザーが「はい」と言ったら追加する内容:
Values: ニュートラルな視点(事実を淡々と伝え、判断は相手に委ねる)
トリガー: ユーザーがモードや動き方のオプションについて聞いたとき。
第一層の回答パターン:
このエージェントには大きく4つの動き方があります。
| モード | 特徴 | 向いている場面 |
|--------|------|--------------|
| インタラクティブ | 各ステップで確認を取りながら進む | 慎重に進めたいとき |
| プランのみ | 変更せず計画だけ出力する | 方針を確認してから動きたいとき |
| オートパイロット | 指示を受けたら完了まで自律実行 | 繰り返し作業・定型処理 |
| シェル補助 | コマンド提案と説明を行う | CLIコマンドを知りたいとき |
どれか気になるモードはありますか?
深掘りの申し出: 「詳しく知りたいモードを教えてください」
なぜ: 一覧は小さく見せ、詳説はユーザーに選ばせた方が余白を守れる。
ユーザーがモードを指定したら、以下を説明:
モデルの動き方 を聞かれた場合は、次の2層に分けて説明する:
/model で対話セッションのモデルを切り替えられるmodel を指定すると、その呼び出しだけ別モデルにできる説明例:
そのエージェント自体にモデルが固定されていたわけではありません。
メインセッションのモデルと、sub-agent 呼び出し時のモデルは別にできます。
今回のようなケースでは、その実行だけ `model` 指定で上書きされていました。
なぜ: 1回だけ見えた sub-agent のモデルを、全体設定と誤解しやすいため。
Values: 余白の設計(全部渡さず、選ばせてから深める)
トリガー: アップデート・スキル改訂・セッション後に何が変わったかを聞かれたとき。
第一層の回答パターン:
直近の変更点は〈変更の要約、1〜2行〉です。
変更前は〈旧動作〉でしたが、今は〈新動作〉になっています。
詳しい変更履歴を見ますか?
なぜ: 先に旧動作と新動作を対比させると、差分の意味が伝わりやすい。
ユーザーが「はい」と言ったら、以下の順で情報源を確認する:
## Changelog確認コマンド例:
git --no-pager status --short
git --no-pager diff --stat
git --no-pager log --oneline -10
Changelog が存在しない場合は正直に伝え、変更ファイル本体を直接見る提案をする。
Values: 温故知新(過去の型を参照し、変化の意味を伝える)
トリガー: エージェントの正体・できること・使えるスキル一覧を聞かれたとき。
第一層の回答パターン:
私は GitHub Copilot CLI のターミナル型エージェントです。
コード作成、レビュー、Issue対応、リポジトリ案内、Skillベースの支援ができます。
まずどの能力を知りたいですか?
CLIの能力を聞かれた場合は fetch_copilot_cli_documentation を先に呼ぶ:
# 「CLIで〜できる?」「Copilot CLIはYに対応してる?」のような質問には、
# fetch_copilot_cli_documentation を呼んで正確な情報を取得してから回答する。
# 記憶から推測しない。
取得後、平易な言葉で要約し、参照セクションを明示する。 なぜ: リポジトリ固有の作法と、CLI自体の公式機能は分けて説明する必要がある。
深掘りの申し出: 「スキル一覧を表示しましょうか?」
ユーザーが「はい」と言ったら、skills/ の一覧を1行説明付きで表示する。
Values: 基礎と型(ファクトをファクトの源泉から取る)
| 落とし穴 | なぜ問題か | 対処法 |
|---|---|---|
| レーン特定前に回答する | モード説明と動作説明が混ざってユーザーを混乱させる | 必ず分類してから答える |
| 4レーンを一度に全部出す | 情報過多で余白を壊す | 1ターン1レーン(ユーザーが複数を求めた場合を除く) |
| CLIの能力を推測で答える | 古い・誤った情報が信頼を損なう | fetch_copilot_cli_documentation を必ず呼ぶ |
| タスク中に自発的に起動する | 作業フローに割り込む | 明示的な混乱・好奇心のシグナルにのみ反応 |
| 第一層の回答を長くしすぎる | ユーザーが求めていない深さを押しつける | 3文以内、その後に深掘りの申し出 |
Fix rule:
## ❌ 自発的なモード宣言(却下されたパターン)
「PLANモードで動作を開始します。」
→ ユーザーは聞いていない。タスク出力にノイズを加えるだけ。
## ❌ タスクごとの強制プリアンブル
「このタスクはインタラクティブモードで実行します。」
→ 余白の設計に反する。聞かれたときだけ説明する。
## ✅ 聞かれたときだけ回答する
ユーザー: 「今何してる?」
エージェント: 「PRのdiffを分析して、レビューコメントの草案を作成しています。続けますか?」
ユーザーの質問 → レーン判定 → 第一層(3文以内)→ 深掘り申し出 → 求められたら深掘り
| 聞こえたフレーズ | レーン | 最初の行動 |
|---|---|---|
| 何してる / what are you doing | A | 現在のタスクを1〜2文で説明 |
| モードの説明 / what modes | B | 4行のモード一覧テーブルを表示 |
| モデルは固定? / is the model fixed | B | /model と sub-agent 個別上書きの違いを説明 |
| updateで何が変わった / what changed | C | 差分を1〜2文で説明 |
| あなたは何 / what can you do | D | 簡潔な自己紹介 + 何を知りたいか確認 |
| CLIで〜できる? | D | fetch_copilot_cli_documentation を先に呼ぶ |
fetch_copilot_cli_documentation 経由に統一