ask

# Ask Skill

あなたはユーザーに質問を投げかけるアシスタントです。

ユーザーからの指示「$ARGUMENTS」に基づいて、AskUserQuestion ツールを使ってユーザーに質問してください。

## 使い方

`/ask <質問内容または質問のコンテキスト>`

## 動作

1. ユーザーからの指示を分析し、適切な質問形式を決定します
2. AskUserQuestion ツールを使って、ユーザーに選択肢付きの質問を提示します
3. ユーザーの回答を受け取って、次のアクションに活用します

---

## ベストプラクティス: いつ・何を質問すべきか

### 質問が効果的な場面

以下のような場面では、実装前に質問して確認することで手戻りを防げます：

1. **アーキテクチャ・技術選択** - フレームワーク、ライブラリ、設計パターンの選択
2. **設計トレードオフ** - パフォーマンス vs 可読性、柔軟性 vs シンプルさなど
3. **非機能要件** - エラーハンドリング戦略、ログレベル、セキュリティ要件
4. **スコープ確認** - 機能の境界、対応すべきエッジケース
5. **優先順位** - 複数の選択肢がある場合の判断基準

### 質問すべき具体的なカテゴリ

#### 1. 技術選択に関する質問
```
/ask 状態管理ライブラリの選択
→ Redux / Zustand / Jotai / Context API など
```

#### 2. 設計アプローチに関する質問
```
/ask APIのエラーハンドリング戦略
→ fail-fast / retry with backoff / graceful degradation など
```

#### 3. トレードオフの明確化
```
/ask データ取得の最適化方針
→ レスポンス速度優先 / データ鮮度優先 / コスト優先 など
```

#### 4. 非機能要件の確認
```
/ask 認証失敗時の振る舞い
→ エラーメッセージ詳細表示 / セキュリティ優先で曖昧に / リダイレクト など
```

#### 5. スコープの確認
```
/ask バリデーションの適用範囲
→ クライアントのみ / サーバーのみ / 両方 など
```

---

## 質問フォーマットのベストプラクティス

### 推奨される質問の作り方

1. **推奨オプションを最初に配置**: 最も適切と思われる選択肢を最初に置き、ラベルに「(Recommended)」を付ける
2. **選択肢は2〜4個**: 多すぎると認知負荷が高くなる
3. **各選択肢に説明を付ける**: トレードオフや影響を明記する
4. **ヘッダーは短く**: 12文字以内で内容を端的に表現

### 良い質問の例

```
質問: 「APIのエラー処理をどのように実装しますか？」
ヘッダー: "Error handling"
選択肢:
  A. Fail fast (Recommended) - エラー発生時に即座に失敗。デバッグしやすい
  B. Retry with backoff - 一時的な障害に強いが、レスポンスが遅延する可能性
  C. Graceful degradation - 部分的な機能低下で継続。UX優先だが複雑さ増加
```

### 避けるべき質問

- 「はい/いいえ」で答えられる質問（選択肢の意味がない）
- 文脈なしの技術名だけの羅列
- ユーザーが判断できない実装詳細

---

## Spec Driven Development との連携

大きな機能を実装する前に、`/ask` を使って仕様を固めることで「Spec Driven Development」を実践できます。

### 推奨フロー

1. **最初の質問**: 機能の目的・ゴールの確認
2. **技術選択**: 使用するライブラリ・パターンの決定
3. **非機能要件**: パフォーマンス・セキュリティ要件の確認
4. **エッジケース**: 異常系・境界条件の対応方針

### 例: 認証機能の仕様策定

```
/ask 認証機能について仕様を固めたい

→ 以下のような質問を順番に投げる:
1. 認証方式の選択（JWT / Session / OAuth）
2. トークンの保存場所（Cookie / LocalStorage / Memory）
3. 認証失敗時の挙動（リダイレクト / エラー表示 / リトライ許可回数）
4. セッション有効期限の戦略（固定 / スライディング / 無期限）
```

---

## 注意事項

- 質問は明