gsd-debug について
専用の gsd-debugger エージェントと連携して問題を調査するデバッグスキルです。症状の収集や調査のチェックポイント管理を行い、根本原因の特定状況に応じて次の対応を提示します。
主な機能
- 01期待される動作と実際の動作を収集
- 02進行中のデバッグセッションを確認・再開
- 03gsd-debugger に調査を委任
- 04チェックポイントと継続調査を管理
- 05調査結果に応じた対応を提示
活用シーン
- 01新たに報告されたソフトウェア問題を調査
- 02未完了のデバッグセッションを再開
- 03調査結果を受けて修正か継続調査かを選択
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ shoootyou/ get-shit-done-multi --skill gsd-debugインストール後、Claude Code で/gsd-debugを入力して読み込まれたか確認します。
詳細
サブエージェントを分離し、科学的手法で問題をデバッグします。
オーケストレーターの役割: 症状を収集し、gsd-debugger エージェントを起動して、チェックポイントに対応し、継続エージェントを起動します。
サブエージェントを使う理由: 調査では、ファイルの読み込み、仮説の形成、検証を行うため、コンテキストをすぐに消費します。調査ごとに新しい 200k コンテキストを確保できます。メインコンテキストはユーザーとのやり取りに集中できます。
ユーザーの問題:$ARGUMENTSアクティブなセッションを確認します:
ls .planning/debug/*.md 2>/dev/null | grep -v resolved | head -5
0. コンテキストの初期化
INIT=$(node {{PLATFORM_ROOT}}/get-shit-done/bin/gsd-tools.cjs state load)
init JSON から commit_docs を抽出します。デバッガーのモデルを解決します:
DEBUGGER_MODEL=$(node {{PLATFORM_ROOT}}/get-shit-done/bin/gsd-tools.cjs resolve-model gsd-debugger --raw)
1. アクティブなセッションを確認する
アクティブなセッションがあり、かつ $ARGUMENTS がない場合:
- ステータス、仮説、次のアクションとともにセッションを一覧表示します
- ユーザーが再開するセッションの番号を選ぶか、新しい問題を説明します
$ARGUMENTS が指定されている場合、またはユーザーが新しい問題を説明した場合:
- 症状の収集に進みます
2. 症状を収集する(新しい問題の場合)
それぞれについて AskUserQuestion を使用します。
- 期待される動作 - 何が起きるべきですか?
- 実際の動作 - 代わりに何が起きていますか?
- エラーメッセージ - エラーはありますか?(貼り付けるか、説明してください)
- 発生時期 - いつから発生していますか?以前は動作していましたか?
- 再現方法 - どのように発生させますか?
すべて収集したら、調査を開始する準備ができたことを確認します。
3. gsd-debugger エージェントを起動する
プロンプトを入力して起動します。
<objective>
Investigate issue: {slug}
**Summary:** {trigger}
</objective>
<symptoms>
expected: {expected}
actual: {actual}
errors: {errors}
reproduction: {reproduction}
timeline: {timeline}
</symptoms>
<mode>
symptoms_prefilled: true
goal: find_and_fix
</mode>
<debug_file>
Create: .planning/debug/{slug}.md
</debug_file>
Task(
prompt=filled_prompt,
subagent_type="gsd-debugger",
model="{debugger_model}",
description="Debug {slug}"
)
4. エージェントの戻り値に対応する
## ROOT CAUSE FOUND の場合:
- 根本原因と証拠の概要を表示します
- 次の選択肢を提示します:
- 「今すぐ修正」 - 修正用サブエージェントを起動します
- 「修正を計画」 - {{COMMAND_PREFIX}}plan-phase --gaps を提案します
- 「手動で修正」 - 完了です
## CHECKPOINT REACHED の場合:
- チェックポイントの詳細をユーザーに提示します
- ユーザーの回答を取得します
- チェックポイントの種類が
human-verifyの場合:- ユーザーが修正済みだと確認した場合:エージェントが最終処理、解決、アーカイブを行えるように続行します
- ユーザーが問題を報告した場合:エージェントが調査または修正に戻れるように続行します
- 継続エージェントを起動します(手順 5 を参照)
## INVESTIGATION INCONCLUSIVE の場合:
- 確認した内容と除外した内容を表示します
- 次の選択肢を提示します:
- 「調査を続ける」 - 追加のコンテキストを渡して新しいエージェントを起動します
- 「手動で調査」 - 完了です
- 「コンテキストを追加」 - 症状をさらに収集して、再度起動します
5. 継続エージェントを起動する(チェックポイント後)
ユーザーがチェックポイントに回答したら、新しいエージェントを起動します。
<objective>
Continue debugging {slug}. Evidence is in the debug file.
</objective>
<prior_state>
<files_to_read>
- .planning/debug/{slug}.md (Debug session state)
</files_to_read>
</prior_state>
<checkpoint_response>
**Type:** {checkpoint_type}
**Response:** {user_response}
</checkpoint_response>
<mode>
goal: find_and_fix
</mode>
Task(
prompt=continuation_prompt,
subagent_type="gsd-debugger",
model="{debugger_model}",
description="Continue debug {slug}"
)
<success_criteria>
- アクティブなセッションを確認済み
- 症状を収集済み(新しい問題の場合)
- gsd-debugger をコンテキストとともに起動済み
- チェックポイントに正しく対応済み
- 修正前に根本原因を確認済み </success_criteria>
コメント
Markdown 対応