القائمة
こんなときに使う: ユーザーが「インタビューして」「質問して」「設計を詰めたい」などと言ったら使う。 計画や設計の重要な判断軸を洗い出し、具体例・反例・影響範囲まで深掘りして要件整理に落とす。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
こんなときに使う: Ubuntu / Linux サーバーに SSH で接続し、sudo、systemd サービス、HTTP 監視を一連で安全に進めたいとき。 接続前に SSH_AUTH_SOCK を含む認証状態を固定し、認証で止まらずに サーバー接続・権限確認・サービス起動・停止・再起動・状態確認を一気に行いたいとき。
調査→修正→検証→ふりかえり/後続 Issue 化までを 1 つの改善ループで回したいときに使う。 実装前の再現確認や、review 指摘・検証結果をもとに次のアクションへつなぐ。
こんなときに使う: 現在の会話内容をもとに、実装・エージェント発注に直結する PRD を作りたいとき。 追加のインタビューはせず、すでに会話に出ている内容だけから構成する。 情報が不足している場合は捏造せず「未確定」として明示する。
Copilot の custom skill / agent / repository instructions の作成・改善・構造確認を 1 つの入口にまとめる。複合スキルとして、対象に応じて適切な authoring ルートへ 分けつつ、実行時のモデル呼び出しを抑止してルーティングを優先する。試作から `plugins/*` 配布へ昇格するときの name / description 整備も扱う。skill / agent / repo-wide instructions / path-specific instructions を新規作成したいとき、既存定義を育てたいとき、公開前に責務や導線を確かめたいとき。
新しい custom agent を既存 agent 群と同じ型で立ち上げる。agent の新規追加、役割分離のための専門 agent 作成、既存群の隙間を埋めたいとき。
skill と agent の authoring 資産を出荷前に検証する。draft の骨格確認、改善後の回帰確認、共有前の最低品質確認をしたいとき。
| name | interview-me |
| description | こんなときに使う: ユーザーが「インタビューして」「質問して」「設計を詰めたい」などと言ったら使う。 計画や設計の重要な判断軸を洗い出し、具体例・反例・影響範囲まで深掘りして要件整理に落とす。 |
この skill の目的は、要件を「作る内容」ではなく「意思決定の境界と実務のルール」として引き出すことです。会話の中から、判断の前提や曖昧さを自然に取り出せるようにします。
質問を始める前に、ユーザーが「何を重要とするか」をすでに提示しているか確認してください。提示されていない場合、最初の1問としてこれを確認してください。
「この計画や設計を詰めるにあたり、何を重視しますか？たとえば以下のような観点が考えられます。
- 業務システム・内部統制寄り：不可逆性／信頼性／拡張性／保守性／コスト／リスク
- 新規企画・プロダクト寄り：独自性／差別化／コア体験／ユーザー価値 特に無ければ、計画の性質から適切な観点を提案します。」
ユーザーが回答した場合はそれを「重要の判断基準」として採用してください。「お任せします」等、判断を委ねられた場合は、計画の性質（業務システムか、新規企画か、その他か）から適切な候補セットを選び、採用した基準を明示した上で先に進んでください。
ステップ0で確定した基準に強く影響する意思決定・設計上の選択肢（＝重要な2割のトピック）を選んでください。このステップで絞るのはトピックの数だけです。選定後の質問の深さ・回数は絞りません。
設計ツリーの各枝を辿りながら、意思決定間の依存関係を一つずつ解消していきます。各質問には、あなたの推奨する回答も添えてください。
質問は一度に一つずつ行い、各質問へのフィードバックを待ってから次に進んでください。一度に複数の質問をするのは混乱を招きます。 repo、ディレクトリやコードベースを調べれば答えられる質問であれば、質問する前にそれらを調べてください。
選定した各トピックについて、次の5軸で深さを増やしてください。
各軸について、抽象論ではなく具体例・反例・影響範囲を必ず聞いてください。たとえば「例外があるか」「その例外は誰が判断するか」「その判断が他の業務に波及するか」を尋ねます。
通過条件：少なくとも「目的・例外・失敗」の3軸について具体例つきの回答が得られるまで、次のトピックに進まないでください。
会話の中の発言を、そのまま要件にしないでください。事実、解釈、未確認事項に分けて整理してください。
抽象的な合意ではなく、具体例を引き出してください。
この三つが見えた時点で、会話はかなり実務寄りの深さになります。
着地の判断は、質問回数や体感の進捗ではなく、次のチェックリストで行ってください。
上記を満たした後、選定しなかった残りのトピック（全体の残り2割相当）については重箱の隅をつつく質問をせず、基本や型に沿った設計をあなたが選んでください。ただし、採用した型とその理由は最後にまとめて提示し、ユーザーが確認・修正できるようにしてください。
会話の最後に、次の 5 点を短く要約してください。これらは後続の要件整理や設計作業へそのまま流しやすくなります。
ステップ０は自由記述形式で質問してください。ステップ1以降は、選択肢は3つから選択で4つ目は自由記述、ラジオボタン形式で提示してください。選択肢の中に「どれも正しくない場合は自由記述で回答してください」と明記してください。
| ❌ やってはいけない | ✅ 代わりにこうする |
|---|---|
| 「2割」を質問回数の上限と解釈し、数問で切り上げる | 絞るのはトピック数のみ。各トピックは通過条件まで深掘りする |
| 抽象的な合意だけで次のトピックへ進む | 具体例・反例・影響範囲を取ってから進む |
| 複数の質問を一度に投げる | 1問ずつ、回答を待って次へ |
| ユーザーの初回回答をそのまま要件として確定する | 事実／解釈／未確認に仕分けてから扱う |
