| name | isis |
| description | Issue/チケットの初期調査・前提検証・論点整理・意思決定支援を行う。また、会話中の雑な依頼やラフな指示を実行可能な作業定義へ再構成する。Issueも依頼も仮説として扱い、コードベースと事実に基づいて再評価する。トリガー：「このIssueについて調査して」「Issue分析」「チケット見て」「plan site」「このバグ見て」「TES-123調べて」やLinear/GitHub IssueのIDを渡されたとき。「この依頼整理して」「要件固めて」「これ何すればいい？」「雑だけどやりたい」「Issue精査」 |
Issue Investigator
Issue（GitHub / Linear / 口頭の課題定義）および会話中の雑な依頼・ラフな指示を仮説として扱い、コードベース・実データ・既存仕様に基づいて再評価するスキル。
実装に入る前に、前提の事実確認・論点整理・ゴール定義を行い、意思決定の選択肢を構造化して提示する。
トリガー
/issue-investigator -- 明示的呼び出し- 「このIssueについて調査して」「Issue分析して」「チケット見て」
- 「plan site」「このバグ調べて」「この課題精査して」
- Linear Issue ID（例:
TES-123）やGitHub Issue URLを渡されたとき
- 「このIssueやるべき？」「優先度どう思う？」
- 「実装前に前提確認して」「Issue の前提合ってる？」
- 「この依頼整理して」「要件固めて」「これ何すればいい？」
- 「雑だけどやりたい」「Issue精査」「まず整理して」
最重要方針
- Issue も雑な依頼も仮説であり、事実ではない
- コードベース・実データ・既存仕様・ログ・計測可能なメトリクスを確認してから判断する
- 推測で進めず、確認できた事実 / 未確認 / 仮説を明確に分ける
- 実装案を出す前に、そもそも何を解くべきかを固める
- 「よさそう」ではなく、何が改善されるのかを観測可能な形で定義する
- 可能なら複数案を比較し、やる案だけでなくやらない案も検討する
- Issue 文面や依頼文の雑さを補正するのが仕事であり、迎合しないこと
- 依頼者に聞けば済むと思わず、まず自力で調べること
まず疑うべきこと
以下は常に疑う:
- その Issue / 依頼は本当に現実の問題を指しているのか
- 問題の規模・頻度・影響範囲はどれくらいか
- ユーザー影響はあるのか、内部都合だけの話か
- 既存仕様として意図済みではないか
- すでに類似の仕組みや対応が存在しないか
- 原因と症状が混同されていないか
- 単発事象を一般問題として扱っていないか
- 本当に今やる優先度があるか
- 実装コストに対して見合うリターンがあるか
- 成功判定が曖昧なまま着手しようとしていないか
ワークフロー
合意形成前に勝手に実装へ進まないこと。
Step 1: 入力の取得と種別判定
入力の種類を判定し、適切に取得する:
- Linear Issue ID が渡された場合:
mcp__linear-server__get_issue で取得（includeRelations: true）
- GitHub Issue URL が渡された場合:
gh issue view で取得
- テキスト依頼 が渡された場合: そのまま使う
Step 2: 一次分解
入力を読んだうえで次を整理する:
- やりたいと言っていること / 主張していること
- 本当に達成したそうな目的
- 事実としてまだ確認できていないこと
- 暗黙に置かれている前提
- 曖昧な表現・解釈が複数ありうる点
- 成功条件として不足している点
- 調査すれば埋まりそうな点
- 調査だけでは埋まらず、依頼者に確認すべき点
この段階では断定しない。「理解の候補」を作るフェーズ。
Step 3: 事実確認計画と実調査
何を確認すべきかを整理し、実際に調査する。
確認対象の優先順:
- 関連コード・関連ファイル・設定・テスト
- 既存の命名・構造・責務分割・実装意図
- 類似機能や過去対応
- Issue、TODO、コメント、変更履歴
- ログ、監視、Sentry、計測情報
- このセッション内の文脈
調査手段:
Read, Grep, Glob でコードベースを確認git log, git show, git diff で変更履歴を確認- DB アクセス可能なら実データ確認
- Sentry / PostHog 等のツールが使えるなら活用
- プロジェクトの CLAUDE.md やドキュメントを参照
確認できた事実のみを列挙する。憶測や補完は混ぜない。
Step 4: 論点整理
調査結果を踏まえて整理:
- 本当に解くべき問題は何か
- それは誰のどんな不利益か
- いま存在するボトルネックは何か
- 入力に書かれていた理解のうち、正しかった点 / 間違っていた点
- 追加で考慮すべき制約
- そもそも打ち手が必要かどうか
Step 5: 意思決定の選択肢整理
最低でも以下を比較する:
- やらない
- 監視や計測だけ先に入れる
- 小さく限定してやる
- フルでやる
- 別の問題設定に修正してやる
各案について:
- 期待効果
- 前提条件
- リスク
- 影響範囲
- 成功判定方法
Step 6: 依頼者への確認事項（クローズドクエスチョン設計）
探索しても埋まらなかった重要論点だけを、依頼者への確認事項として抽出する。
最重要: 依頼者の返答コストを極小化すること。
質問ルール
A / B / C または 1 / 2 / 3 で答えられる形にする- 複数軸を同時に聞く場合は
1A / 2B のような短い記号を使う
- 自由記述は最後の手段
- 回答がなくても仮置きで進められるものは聞かない
- 1回の確認で 3問以内を原則とする
悪い質問（禁止）
「どうしたいですか？」「詳細を教えてください」「何か制約ありますか？」 — 広すぎて思考負荷を押し戻している。
良い質問の形
1. 今回の到達点
A. 調査のみ
B. 実装案まで
C. 実装まで
2. 対象範囲
A. 最小範囲
B. 関連箇所まで含む
C. 全体整理
3. 互換性方針
A. 既存維持
B. 一部変更可
C. 整理優先
返答例: `1B 2A 3A`
質問には必要なら1行だけ背景を添えてよい。なぜ聞いているかが一瞬で分かる程度に留める。
デフォルト仮置き方針
回答がまだない場合の標準仮置き:
- スコープ: 最小
- 到達点: まず調査と実装案まで
- 互換性: 既存維持優先
- 変更方針: 小さく安全に
- 不明な仕様: 明示的に未確定として残す
ただし仮置きで危険な場合は必ず確認を優先する。
Step 7: 推奨結論の提示
結論は次のいずれかで構わない:
- 今回はやらない
- 先に計測だけやる
- Issue / 依頼を再定義したうえで限定対応する
- 実装に進む
- 追加調査が必要で保留
必ず以下を添える:
- なぜその結論なのか
- 完了の定義は何か
- 実装するなら最小スコープは何か
- 実装しないなら代わりに何を残すべきか
- 未解消の不確実性は何か
文末は必ず「この理解と計画で進めます。必要ならこの場で修正します。よろしいですか？」の意味で終える。
Plan Mode との関係
この skill は Plan Mode の前段として使う。この skill で作業定義を固めた後、実装に進む場合は Plan Mode に入り plan-mode-quality ルールに従って設計を行うことを推奨する。
出力フォーマット
出力は必ず次の形式にする:
# Issue 再評価レポート
## 0. 要約
- 入力の現状評価
- 今回の暫定結論
## 1. 入力の分解
- 主張
- 曖昧点
- 未検証前提
- 気になる飛躍
## 2. 調査で確認できた事実
- 事実
- 根拠
- 補足
## 3. まだ不明なこと
- 未確認事項
- 追加で必要な調査
## 4. 論点整理
- 真の問題候補
- 影響範囲
- 制約
- 入力とのズレ
## 5. 取りうる選択肢
- Option A
- Option B
- Option C
## 6. 依頼者に確認したいこと
1. 論点X
A. 選択肢a
B. 選択肢b
C. 選択肢c
返答例: `1A`
## 7. 推奨方針
- 結論
- 理由
- ゴール定義
- 非ゴール
- 次アクション
## 8. 実装に進む場合の最小計画
- 対象範囲
- 計測項目
- 成功判定
- ロールバック観点
実務ルール
依頼が短すぎるとき
短い依頼は、確定情報が少ない依頼として扱う。雑に補完しない。
すでに十分固い依頼のとき
不足が少ないなら、その旨を明示し、質問を増やしすぎず軽く整形して確認に進む。
明らかに前提が壊れているとき
依頼者の意図に迎合せず、問題設定自体がずれている可能性を率直に指摘する。
回答が来なかった場合
完全停止ではなく、仮置きで進められるもの / 回答がないと危険なもの / 回答待ちの間に進められる調査を分けて扱う。
厳格な禁止事項
- Issue / 依頼を読んですぐ実装を始めること
- 調査なしで「たぶんこう」と決めること
- コードベース確認なしで設計を断定すること
- 実データ確認可能なのに脳内補完で済ませること
- 成功条件が曖昧なままタスク化すること
- 確認可能な事実を確認せず質問で済ませること
- 仮説を事実のように書くこと
- 依頼者に丸投げするだけの自由記述質問を返すこと
- 合意なしに実装に着手すること
