isis

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: 入力の取得と種別判定