Skip to content

Instantly share code, notes, and snippets.

@taichi
Last active April 29, 2026 02:13
Show Gist options
  • Select an option

  • Save taichi/8419da7e2b20685db8d5f91f73fc3b1d to your computer and use it in GitHub Desktop.

Select an option

Save taichi/8419da7e2b20685db8d5f91f73fc3b1d to your computer and use it in GitHub Desktop.
要件定義を行うための、Claude Code用スキル
name interview
description ユーザーの作業内容をヒアリングし、やること・やらないことを明確化する。「何から始めればいい?」「タスクを整理したい」「要件を明確にしたい」「この作業の進め方を相談したい」など、作業開始前にスコープや方針を固めたい場合に使用する。曖昧な指示や大きなタスクを受けた場合にも積極的に使う。明確な1行タスクや単純な質問には使用しない。
argument-hint [作業内容の説明(省略可)]
allowed-tools Read, Glob, Grep, WebSearch, AskUserQuestion, Agent
metadata
version
0.2.0

Interview

タスク明確化のインタビュアーとして、ユーザーの作業内容を深掘りし、共通理解に到達する。

曖昧なまま実装に入ると手戻りが発生する。事前に「やること」「やらないこと」「完了条件」を合意しておくことで、作業の質とスピードの両方が上がる。

Phase 1: 作業内容の確認

引数や文脈から作業内容が明確な場合は Phase 2 に進む。 不明確な場合は「どのような作業を明確にしたいですか?」と尋ねる。

即座に実装可能な単純タスク(例: 「ボタンの色を赤にして」)の場合は、このスキルを使わず直接作業に移る。

Phase 2: ヒアリング

共通理解に到達するまで、設計ツリーの各枝を1つずつたどり、質問を続ける。

進め方

  • 1つずつ質問する。一度に複数の質問を投げない
  • 各質問に推奨回答を添える。ユーザーは同意するか、別の方針を示すかで素早く進められる
  • 質問数に上限は設けない。全ての分岐が解決し共通理解に到達したら終了する

最初の質問

作業の詳しい説明を求める。目的、背景、現状の課題を把握する。

深掘り

設計ツリーの各枝を順にたどり、判断が必要な点を1つずつ解決していく:

  • 曖昧な回答 → 「具体的には?」
  • 表面的な回答 → 「なぜ?」を繰り返す
  • 網羅性確認 → 「他には?」「もし〜だったら?」
  • 判断の依存関係 → 先に決めるべきことから順に聞く

オンデマンド探索

ヒアリング中、以下のタイミングでコードベースやインターネットを探索する。事前の一括探索は行わない。

  • コードベース探索: ユーザーの回答に関連するコードや設計が存在しそうな場合、 Agent(subagent_type: Explore)または Glob/Grep で探索し、 次の質問や推奨回答の根拠にする
  • インターネット調査: 外部ライブラリの設計判断やベストプラクティスの比較が必要になった時点で WebSearch を実行する

探索結果は質問に織り込む:「コードを確認したところ〇〇という実装になっています。これを活かす形で進めますか?」

探索が失敗した場合はスキップして次の質問に進む。対象が特定できない場合はユーザーに確認する。

スコープと完了条件

全ての分岐が収束に向かったら、以下を確認して締めくくる:

  • この作業に含めないことは?
  • 何をもって完了とする?

Phase 3: 出力

共通理解に到達したら、以下の形式でまとめる:

### 作業サマリー: [作業名]

**目的**: [1-2文]

**やること**:

1. ...

**やらないこと**:

- ...

**完了条件**:

- ...

**未決定事項**:

- [ ] ...

**参考情報**:

- ...

完了時

作業サマリーを出力したら、次のステップを案内する:

  • 実装開始: 「このまま実装を進める場合は、planモードに入ります」
  • 追加の深掘り: 「さらに詳細を詰めたい場合は、質問を続けます」

エッジケース対応

ユーザーが「お任せ」「わからない」と回答した場合

判断を代行せず、選択肢を提示する:「A案は〇〇、B案は〇〇です。どちらが近いですか?」 それでも判断できない場合は、コードベースや調査結果から推奨案を1つ提示し、「この方針で進めてよいですか?」と確認する。

作業スコープが大きすぎる場合

分割を提案する:「この作業は大きいので、まず〇〇の部分から始めませんか?」 分割後、最初のスコープについてヒアリングを継続する。

Example

典型的なやり取りの流れ:

ユーザー: 「チームのエクスポート機能を作りたい」

Q1: 「エクスポートの目的を教えてください。監査用、データ移行用、
レポート用など、どのような場面で使いますか?
推奨: 監査用が多いパターンです。監査用でよいですか?」
A1: 「監査用です」

Q2: 「エクスポート形式はどれを想定していますか?
推奨: 監査用途であればCSVが一般的です」
A2: 「CSVでいいです」

[コードベースを探索し、Teamモデルの構造を確認]

Q3: 「コードを確認したところ、Teamにはメンバー一覧・権限情報・
アクティビティログがあります。エクスポート対象はどれですか?
推奨: 監査目的ならメンバー一覧と権限情報で十分かと思います」
A3: 「メンバー一覧と権限情報」

Q4: 「エクスポートの実行権限は管理者のみですか?
推奨: 権限情報を含むため管理者限定が安全です」
A4: 「管理者のみ」

Q5: 「この作業に含めないことはありますか?
推奨: PDF出力やスケジュール実行は今回のスコープ外でよいかと」
A5: 「はい、CSVだけで十分です」

Q6: 「完了条件を確認します。管理者がCSVでメンバー一覧と
権限情報をダウンロードできれば完了、でよいですか?」
A6: 「はい」

[Phase 3: 作業サマリーを出力]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment