mcpField
G
gsd-debug

gsd-debug

github.com/shoootyou開発22115 回インストール32 週間前に更新
リポジトリ

gsd-debug について

専用の gsd-debugger エージェントと連携して問題を調査するデバッグスキルです。症状の収集や調査のチェックポイント管理を行い、根本原因の特定状況に応じて次の対応を提示します。

主な機能

  1. 01期待される動作と実際の動作を収集
  2. 02進行中のデバッグセッションを確認・再開
  3. 03gsd-debugger に調査を委任
  4. 04チェックポイントと継続調査を管理
  5. 05調査結果に応じた対応を提示

活用シーン

  1. 01新たに報告されたソフトウェア問題を調査
  2. 02未完了のデバッグセッションを再開
  3. 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 を使用します。

  1. 期待される動作 - 何が起きるべきですか?
  2. 実際の動作 - 代わりに何が起きていますか?
  3. エラーメッセージ - エラーはありますか?(貼り付けるか、説明してください)
  4. 発生時期 - いつから発生していますか?以前は動作していましたか?
  5. 再現方法 - どのように発生させますか?

すべて収集したら、調査を開始する準備ができたことを確認します。

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>

コメント