investigate
作成者 garrytaninvestigate skill は、壊れた動作、挙動が不安定な不具合、想定外の動作に対して、体系的なデバッグと根本原因分析を進めるためのガイドです。コードレビュー、障害切り分け、バグ修正、そして「昨日までは動いていた」といったケースで、コードを変える前に証拠を集めたいときに使います。investigate、analyze、hypothesize、implement の 4 段階ワークフローに従います。
この skill は 82/100 で、ディレクトリ掲載候補として十分有望です。よくあるデバッグ／根本原因分析の流れを明確にカバーし、きっかけの指示もあるため迷いにくい一方、導入を後押しする補助資料はまだ少なく、採用判断にはやや補完が必要です。
- デバッグや根本原因分析の場面に対する発火条件が明確で、エラー、スタックトレース、「昨日は動いていた」といったケースでも事前に呼び出しやすい。
- 運用フローが investigate、analyze、hypothesize、implement の 4 段階として明示されており、原因特定前に修正しないという強い制約もある。
- hooks と allowed-tools を使っており、単なる説明文ではなく、実際の実行挙動を伴う skill であることが分かる。
- リポジトリにはインストールコマンド、サポートファイル、参照資料、readme がなく、セットアップや適用範囲の理解は主に SKILL.md に頼る必要がある。
- frontmatter にプレースホルダーマーカーが含まれており、主要なワークフロー自体は充実しているものの、一部はまだ調整中の可能性がある。
investigate skillの概要
investigate skillでできること
investigate skill は、壊れている、挙動が不安定、または想定と違う動きをしているときに、体系的にデバッグし、根本原因を突き止めるための skill です。単なる応急処置ではなく、なぜエラーが起きたのか、何が変わったのか、どの修正なら安全かを理解したい場合に向いています。investigate は、その作業を整理して進める助けになります。
どんな人に向いているか
investigate skill は、コードレビュー、障害切り分け、バグ修正、そして「昨日は動いていたのに」といった状況で使うのに適しています。エージェントに推測をやめさせ、証拠を集め、症状から確定した原因へ向かってからコードを変更させたいときに、特に相性が良い skill です。
何が優れているのか
最大の差別化ポイントは、「根本原因が分かるまで修正しない」というルールです。これにより、investigate skill は一般的なデバッグ用プロンプトよりもはるかに筋道立った進め方になります。いきなり編集に入らず、調査、分析、仮説立案、実装という流れに引き込むからです。さらに、エラーやスタックトレースが出た時点で自動的に動かすような proactive なトリガーにも対応しており、エージェントワークフローで使いやすいのも特徴です。
investigate skill の使い方
インストールして呼び出す
investigate skill は次のコマンドでインストールします。
npx skills add garrytan/gstack --skill investigate
スタックトレース、500 エラー、リグレッション、予期しない出力など、明確に失敗状態を示すプロンプトで使うのが基本です。精度を上げるには、症状、発生箇所、そして「正常」とはどう見える状態かを具体的に書いてください。
最初に渡すべき入力をそろえる
investigate skill をうまく使うプロンプトには、次の情報を入れると効果的です。
- 正確なエラーメッセージ、またはログの抜粋
- それを引き起こすコマンド、endpoint、ユーザー操作
- 最近何が変わったか
- すでに確認したこと
- 影響範囲と緊急度
例: 「npm test が最後のマージ以降、CI で失敗するようになった理由を investigate してください。main と HEAD を比較し、auth middleware の最近の変更を調べ、根本原因が確認できるまでコード変更は提案しないでください。」
最初に読むべきファイル
まず SKILL.md を読み、次にテンプレート化された動作やルーティングロジックがあるなら SKILL.md.tmpl を確認します。このリポジトリには rules/、resources/、scripts/ のような分離されたフォルダがないため、主な情報源は skill ファイル本体と、そこに書かれた inline の参照です。Code Review 向けの investigate では、編集に入る前に trigger の文言と、安全に実行できる操作の境界線を特に重視してください。
出力を良くするためのワークフローのコツ
investigate は、自由な雑談ではなく意思決定のワークフローとして扱ってください。エージェントには次の順番で進めさせると効果的です。
- 失敗モードを特定する
- 裏付けとなる証拠を集める
- 1つか2つの検証可能な仮説を立てる
- もっとも可能性の高い原因を確認する
- 最小限で安全な修正を実装する
この1を飛ばすと、analysis 自体は返ってきても、コードレビューやインシデント対応で使える内容にはなりにくくなります。
investigate skill のFAQ
investigate はバグ専用ですか？
いいえ。investigate skill は、リグレッション、デプロイ失敗、連携不具合、原因がはっきりしない挙動変更にも向いています。「なぜこれが起きているのか」を調べたいなら、investigate がたいてい適切な出発点です。
通常のプロンプトと何が違いますか？
通常のプロンプトは、すぐ修正を求めがちです。investigate skill はもっと構造化されていて、先に根本原因を考えさせるため、脆い編集を減らし、最終的な変更をコードレビューで説明しやすくします。
investigate は初心者にも向いていますか？
はい。症状と少しの背景情報を出せるなら、初心者にも向いています。推測を減らせるので恩恵は大きいですが、ログ、再現手順、失敗するコマンドなど、具体的な証拠はやはり必要です。
どんなときに使わないほうがいいですか？
すでに欲しい変更が正確に分かっている場合や、原因究明の必要がない単純なコンテンツ修正では使わないでください。その場合は、もっとシンプルな task prompt のほうが速いです。
investigate skill を改善する方法
不満ではなく証拠を渡す
品質が一番上がるのは、入力を鋭くしたときです。「アプリが壊れている」ではなく、失敗している request、エラー文、file path、環境、最後に正常だった状態を渡してください。investigate skill は、各仮説を観測可能な証拠に結びつけられると最も力を発揮します。
探索範囲を絞る
問題が Code Review にあるなら、怪しい subsystem と変更範囲を先に絞ってください。たとえば「auth に絞る」「直近2件の commit だけを見る」「staging で再現するか確認する」といった指定です。そうすると investigate が広がりすぎず、素早く根本原因にたどり着ける可能性が上がります。
1回目の結果を受けて繰り返す
最初の回答が不十分なら、より広く書き直させるのではなく、調査を絞り直してください。良い追加指示の例は、「上位3つの仮説を確信度つきで並べてください」「それぞれを否定できる証拠を示してください」「入力から出力まで失敗の流れを追って、コード変更の前で止めてください」です。