mcpField
A
asking-questions

asking-questions

github.com/oaustegardエージェントワークフロー157105 回インストール1 日前に更新
リポジトリ

asking-questions について

asking-questionsは、実装前に確認が必要かを判断するエージェントスキルです。結果に大きく影響する選択を明確にし、文脈から答えが分かる場合の不要な質問を避けます。

主な機能

  1. 01確認が必要な判断の特定
  2. 02重要な情報不足の把握
  3. 03破壊的な可能性がある依頼の確認
  4. 04選択肢とトレードオフの提示
  5. 05段階的な質問

活用シーン

  1. 01複数の実装方法から選択
  2. 02曖昧なリファクタリング依頼の確認
  3. 03整理がアーカイブか削除かの確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/oaustegard/claude-skills --skill asking-questions

インストール後、Claude Code で/asking-questionsを入力して読み込まれたか確認します。

同梱ファイルCHANGELOG.mdREADME.md

詳細

質問する

目的

回答によって作るものが大きく変わる場合は、確認の質問をします。このスキルでは、質問すべき状況、効果的な質問の組み立て方、自律的に進めるべき状況を見極める方法を説明します。

使用する場面

次のような場合に質問します。

  1. 実装方法が曖昧な場合 - 有効な技術的アプローチが複数ある場合（ミドルウェアとラッパー関数、ライブラリの選定、アーキテクチャパターンなど）
  2. 重要な情報が不足している場合 - 必要な具体的情報が不足している場合（データベースの種類、デプロイ先のプラットフォーム、認証情報の管理など）
  3. 破壊的な操作につながる可能性がある場合 - 危険な解釈ができる依頼（「ファイルを整理する」＝削除するか、アーカイブするか）
  4. 範囲を明確にする必要がある場合 - 「リファクタリング」「最適化」「改善」など、曖昧な表現がある場合
  5. 要件が矛盾している場合 - 目標が互いに相反する可能性がある場合（「高速化する」＋「詳細なログを追加する」）
  6. 技術的なトレードオフがある場合 - 優先事項によって、コストやメリットが異なる解決策がある場合

使用しない場面

次のような場合は質問しないでください。

  • 依頼が明確で曖昧さがない場合 - 明らかな実装方法が1つある
  • コンテキストから回答を判断できる場合 - コードベースのパターン、プロジェクト構成、既存の規約から判断できる
  • 確認しすぎる場合 - 実装に大きな影響を与えない質問
  • 標準的なエンジニアリング手法の場合 - コードベースですでに確立されているパターン

質問の構成

テンプレート
[Context: What you found/analyzed]

[Present 2-5 specific options with brief trade-offs]

[Direct question asking for preference]

[Optional: Offer to make reasonable default choice]
ガイドライン

  1. まず理解したことを伝える - 状況を分析したことを示します

    • 「API エンドポイントを確認し、Express を使用していることがわかりました……」

  2. 明確な選択肢を提示する - 簡潔な説明とともに、具体的な選択肢を2～5個示します

    I can implement this in several ways:
1. **Global middleware** - Catches all errors centrally (simplest)
2. **Wrapper functions** - More granular control per endpoint
3. **Custom error classes** - Typed errors with status codes

  3. 直接質問する - 判断を促す明確な質問をします

    • 「どの方法がお客様のニーズに合っていますか？」

  4. 自律的に進める選択肢を示す（任意） - 重要度が低い判断の場合

    • 「最も安全な選択肢としてオプション2で実装できますが、別の方法をご希望の場合はお知らせください。」

段階的な開示

最初からすべてを質問するのではなく、段階を分けて質問します。

良い例 ✓

  • 最初：「リアルタイム更新には、WebSockets、Server-Sent Events、ポーリングのどれを使いますか？」
  • 次に：「WebSockets の場合、Socket.io（簡単）とネイティブ（軽量）のどちらがよいですか？」

悪い例 ✗

  • 「リアルタイム更新には WebSockets と SSE とポーリングのどれを使えばよいですか。また WebSockets の場合は Socket.io とネイティブのどちらを使い、再接続を実装し、認証はどうするべきですか……」

例

良い例 ✓

「JWT 認証を使っていることがわかりました。リフレッシュトークンを追加する方法として、次の選択肢があります。

  1. httpOnly cookies - より安全で、XSS に対するリスクを軽減できます
  2. localStorage - よりシンプルで、モバイルアプリでも動作します
  3. メモリ内のみ - 最も安全ですが、更新時に失われます

用途に最適なのはどれですか？」

悪い例 ✗

「セキュリティへの影響、XSS の脆弱性、モバイルとの互換性、UX への影響、コンプライアンス上の考慮事項を踏まえて、認証リフレッシュトークンの保存メカニズムをどのように実装すればよいですか？」

冗長で、明確な選択肢がなく、一度にすべてを尋ねています

良い例 ✓

「『マイグレーションを整理する』とおっしゃいましたが、/old-migrations にアーカイブしますか、それとも完全に削除しますか？（注：まだマイグレーションを実行していないデータベースでは、削除によって問題が起きる可能性があります）」

悪い例 ✗

「整理するとはどういう意味ですか？」

曖昧すぎて、判断を促せていません

回答を受け取った後

  1. 確認する - 選択を理解したことを伝えます
  2. すぐに進める - 続けてよいかどうか尋ねません
  3. 好みを反映する - 一度「セキュリティ優先」を選んだ場合、今後の同様の選択でもその方向を優先します

重要な原則

回答によって作るものが大きく変わる場合にのみ質問します。 質問すること自体を目的にせず、間違ったものを作らないようにしましょう。

コメント

Markdown 対応