diagnose-fix-loop

診断・修正ループ

単一のデバッグ作業ではなく、改善の一連のループを実行するには、このスキルを使用してください。

開始する前に、$diagnose を読み込み、その指示に従ってください。各パスでは $diagnose を証拠を集める仕組みとして扱います。このスキルが追加するのは、計画、実装、診断の再実行、継続するかどうかの判断を行う外側のループだけです。

明示的に実行すると、$diagnose の使用が許可され、対象を限定したローカル修正と検証が認められます。証拠によって信頼できる原因と修正が裏付けられたら、このスキルが実装を担当します。

選択したインストール方法では、依存関係は自動的にインストールされません。$diagnose がインストールされていない、または利用できない場合は、変更を加える前に停止してください。次のコマンドでインストールするようユーザーに伝えてください。

npx skills add LegendApp/legend-skills --skill diagnose

その後、インストールが完了してから再試行するよう依頼してください。

ループ

1. 目標とする結果を示します。 ユーザーが示した症状、パフォーマンス目標、失敗するテスト、UX の不具合、リグレッション、またはコード品質に関する懸念をループの基準にします。ユーザーが具体的な基準を示していない場合は、まず最短で結果を確認できるフィードバックループを作成します。

2. $diagnose を実行します。 原因を示す証拠と、修正後に再実行する正確な検証シグナルを記録します。対象を限定した修正を正当化できる Proven または Supported の証拠が得られたら、次に進みます。証拠が Incomplete のままなら、利用可能な有効な調査を続けます。信頼できる修正を行うのに必要な証拠が得られない場合は停止し、不足している情報を報告します。 ユーザーが委任を依頼した場合は、このパス内の範囲を限定した証拠収集にのみ使用します。ボトルネックの優先順位付け、修正の選択、コード編集、最終的な解釈はメインのループで行います。

3. 優先順位を付けた修正計画を立てます。 一度に実施する、最小限で信頼できる修正を優先します。計画には次の内容を含めます。

   • 変更を裏付ける証拠
   • 変更するファイルまたは境界
   • 改善するはずの検証項目
   • 計画が誤りだと判断できる条件

4. 計画の最上位項目だけを実装します。 変更範囲は、証拠によって裏付けられた原因の境界内にとどめます。診断によって同じ不具合の一部だと示されていない限り、推測に基づくクリーンアップ、広範なリファクタリング、隣接する改善を重ねないでください。

5. 元のシグナルを使って検証します。 ステップ 2 で使った再現手順または測定を再実行し、その後に対象を絞ったリグレッションテストを行い、変更範囲に応じてより広範なチェックも実施します。

6. $diagnose を再実行します。 変更の意図ではなく、新たに得られた証拠に基づいて現在の状態を診断します。次の点を確認します。

   • 元の症状がまだ発生する
   • 近接した箇所に残る不具合
   • 修正によって生じたリグレッション
   • 最初の修正によって明らかになった、より大きな次のボトルネック
   • 実際の接続点におけるテストカバレッジの不足

7. 続行するかどうかを判断します。 信頼できる次の修正が証拠によって特定され、その次の作業を安全に実施できる場合は続行します。反復するたびに、前回よりも明確な目標を設定してください。

反復時の規律

作業中は、短い進捗ログを記録します。

• 反復番号
• 現在の証拠
• 選択した修正
• 検証結果
• 次に対処する問題または停止理由

実験に失敗した場合は、独立して有用であり、意図的に残す場合を除き、元に戻してください。診断を絞り込めていない失敗した実験を、進捗として数えないでください。

2 回の反復で測定可能な改善がなく、証拠も明確にならない場合は、実装を一時停止してください。さらに変更を加える前に、フィードバックループ自体を再診断します。

停止ルール

次のいずれかに該当する場合にのみ停止します。

• 利用可能なコード、ツール、成果物では、$diagnose が信頼できるフィードバックループを構築または実行できない
• 次の作業に、ユーザーの入力、アクセスできない外部状態、認証情報、本番環境へのアクセス、または破壊的な操作が必要となる
• ユーザーが読み取り専用の診断を依頼しており、次の有効な手順でファイルの編集が必要となる
• 検証に問題がなく、新たに実行した $diagnose でも、修正すべき信頼できる不具合が見つからない
• 残る改善が推測に基づくもの、見た目だけのもの、またはユーザーの目標範囲外である

停止時は、最終状態、検証で得られた証拠、既知の残存リスク、作業がブロックされている場合は続行に必要な最小限のユーザー操作または成果物を報告します。