skill-debug

ホスト：Codex CLI — このスキルは Claude Code 向けに設計され、Codex 用に調整されています。 相互参照コマンドでは、/octo:* スラッシュコマンドではなく、Codex にインストールされたスキル名を使用します。 現在の Codex シェルとサブエージェントツールを使用してください。現在のセッションで利用可能であることが確認されるまでは、プロバイダー、モデル、またはホストのサブエージェントが利用可能だと断言しないでください。 ホストツールに相当するものについては、skills/blocks/codex-host-adapter.md を参照してください。

デバッグ

インストール済みプラグインの skills/blocks/engineering-method-selection.md を 読み、レビュー受け入れ条件を確認してください。自然言語での依頼と --peer-review は、同じポリシーに従います。ホストに限定した依頼を尊重してください。 リスクがあるというだけで、有料の利用が許可されるわけではありません。

現在のホスト上で調査を実施してください。通常のデバッグでは、追加の プロバイダーディスパッチは発生しません。限定的な外部レビュー担当者を 使用できるのは、--peer-review、明示的な独立レビューの依頼、または既存のリスク ポリシーがある場合に限られます。

症状を再現し、名前を付けた根本原因の仮説を検証するまでは、本番の動作を変更してはなりません。

インストール済みプラグインのルートにある skills/blocks/debug-feedback-loop.md を 読み、適用してください。

ユーザーが観測できる症状から始めてください。症状を再現し、その失敗の特徴を 保ったままシナリオを最小化し、名前を付けた仮説を一度に1つずつ検証して、 修正後に最小再現と元のシナリオの両方を確認してください。近接するヘルパーテストが 成功したことを証明とみなしてはなりません。

競合状態の場合は、同期バリアと固定の実行回数または時間予算を使用してください。本番環境の依存関係が 利用できない場合は、不足している証拠を示して inconclusive を返してください。 完了前に一時的な計測コードを削除し、安定した再現を回帰テストとして残してください。

最終記録はデータであり、実行キューではありません。コマンドは引数の配列として保存し、 プロバイダーが作成したテキストは決して評価しないでください。

制限付きリカバリーと戦略の切り替え

修正に失敗した場合は、3回ルールを適用してください。失敗するたびに証拠に立ち返り、 実質的に異なる仮説を検証してください。失敗が2回連続した場合は、戦略の切り替えが 必須です。根本原因、再現方法、テストが意図した動作を表しているかどうかを再検討してください。 ユーザーの明示的な承認なしに、4回目の修正を試みてはなりません。

自己正当化を防ぐための確認：「これで直るはず」と思ったら、再現と元のシナリオを実行してください。 確信は検証ではありません。

複数回試行するデバッグでは、~/.claude-octopus/loop-config.conf の既定値を使って WTF スコアを報告してください。リバートごとに +15%、無関係なファイルに手を加えた場合は +20% です。スコアが20%を超えた場合は、続行を中止し、先に証拠を提示してください。 再試行ごとに、次の例のようにスコアを記載してください。

Fix attempt 2 | Self-regulation: 15% (1 revert, 0 unrelated files)

スコープ指定のフリーズガード

症状がユーザーの承認を得た単一のモジュールに限定されている場合は、編集前にそのモジュールを物理ディレクトリに解決し、既存のフリーズガードを有効にします。

_OCTO_SESSION_ID="${CLAUDE_CODE_SESSION_ID:-${CLAUDE_SESSION_ID:-}}"
if [[ -z "$_OCTO_SESSION_ID" ]]; then
    printf 'Freeze activation requires a shared Claude session ID; stop before editing.\n' >&2
    exit 1
fi
freeze_dir="$(cd "<module-directory>" 2>/dev/null && pwd -P)" || exit 1
_OCTO_FREEZE_FILE="/tmp/octopus-freeze-${_OCTO_SESSION_ID}.txt"
if [[ -e "$_OCTO_FREEZE_FILE" || -L "$_OCTO_FREEZE_FILE" ]]; then
    if [[ -f "$_OCTO_FREEZE_FILE" && ! -L "$_OCTO_FREEZE_FILE" &&
          -O "$_OCTO_FREEZE_FILE" && -s "$_OCTO_FREEZE_FILE" ]]; then
        printf 'Freeze already active; left unchanged.\n'
    else
        printf 'Unsafe or empty freeze state; stop and inspect it before retrying.\n' >&2
        exit 1
    fi
else
    (umask 077; python3 - "$_OCTO_FREEZE_FILE" "$freeze_dir" <<'PYFREEZE'
import os
import sys

try:
    fd = os.open(sys.argv[1], os.O_WRONLY | os.O_CREAT | os.O_EXCL, 0o600)
    with os.fdopen(fd, "w", encoding="utf-8") as state:
        state.write(sys.argv[2] + "\n")
except OSError:
    raise SystemExit("Freeze activation failed; inspect the state before retrying.")
PYFREEZE
    ) || exit 1
fi

有効化には、空でない CLAUDE_CODE_SESSION_ID または CLAUDE_SESSION_ID が必要です。有効化とフリーズの強制には、いずれも Python 3 が必要です。既存の空の状態、シンボリックリンク、または通常ファイルではない状態は、手動での確認のため拒否されます。この有効化チェックでは、有効な状態の内容を読み取ったり、表示したりすることはありません。排他的な作成により、チェック後に追加された状態パスは拒否されます。

すでに有効になっているフリーズ（/octo:freeze、/octo:guard、または以前のワークフローによるもの）はそのまま維持してください。置き換えたり、デバッグ終了時に解除したりしないでください。現在の境界により、そのスコープ外への編集は引き続きブロックされます。別のモジュールを対象にする場合は、編集前に意識的にフリーズを解除し、新しいスコープをフリーズしてください。根本原因がまだ不明な場合、再現が複数のモジュールにまたがる場合、またはユーザーがオプトアウトした場合は、自動でフリーズしないでください。元のシナリオでの検証後、このワークフローがフリーズを作成し、状態ファイルに現在もこのワークフローが設定したディレクトリが記載されている場合に限り、/octo:unfreeze を実行してください。別のディレクトリが記載されている場合は、その後ユーザーが再度フリーズしたことを意味するため、フリーズを維持してください。

mattpocock/skills の diagnosing-bugs を、MIT ライセンスの下、コミット 3cca18b368ae95cdbdebbff572ccafa662551015 から改変して使用しています。THIRD_PARTY_NOTICES.md を参照してください。