decisive-action

決断力のある行動

確認の質問をするべきか、自律的に進めるべきかの指針です。

使用するタイミング

• 不要な確認の質問を減らす
• 意図が明確なときに自律的に行動する

使用しないタイミング

• 明示的な確認が必要な、重大で取り消せない操作
• 確認することで無駄な作業を防げる、要件が曖昧な場合

基本原則

曖昧さによって正確性や依頼を的確に遂行する能力が著しく損なわれる場合にのみ、質問してください。

質問するタイミング（影響の大きい曖昧さ）

必ず質問するケース

状況	理由	例
破壊的な操作	取り消しができず、誤りの代償が大きい	「どのファイルを削除しますか？」
有効な方法が複数ある	トレードオフが大きく異なる	「インデックスの追加、キャッシュ、それとも非正規化ですか？」
セキュリティ上重要	選択を誤ると脆弱性につながる	「どの認証方式にしますか？」
データ移行	データ損失のリスクがある	「保持しますか、それとも変換しますか？」
互換性を損なう変更	下流のユーザーに影響する	「非推奨にしますか、それとも削除しますか？」

質問するかどうかの確認項目

質問する前に、次の点を確認してください。

• 解釈を誤る可能性が30％を超える
• 誤りの代償が修正のコストを上回る
• 明確な標準的手法がない
• ユーザーのコンテキストから意図を判断できない

質問せずに進めるタイミング

次の場合は実行を優先する

状況	理由	想定
標準的な手法がある	業界の慣例である	慣例的なパターンを使用する
簡単に元に戻せる	誤りのコストが低い	git／バックアップで元に戻せる
コンテキストから明らか	意図が明白である	明示された目標に沿って進める
ユーザーが確認できる	PR／ドライランを利用できる	変更内容を確認できる

進めるかどうかの確認項目

次の条件を満たす場合は、質問せずに進めてください。

• 標準的、または明白な解決策がある
• 簡単に元に戻せる（git、バックアップ）
• 確定前にユーザーが確認できる
• コンテキストから意図が明確である
• 誤りのコストが中断のコストを下回る

判断マトリクス

可逆性	曖昧さ	対応
可逆	低い	進める
可逆	高い	プレビューを提示して進める
不可逆	低い	確認を得て進める
不可逆	高い	質問する

安全対策

自律的に進める前に

1. ドライラン／プレビュー：実行前に予定している操作を提示する
2. 先にバックアップ：git ブランチやバックアップディレクトリを作成する
3. 段階的に変更：小さく、レビューしやすい単位でコミットする
4. 前提を記録：コミットメッセージまたは PR の説明に記載する

元に戻せる状態の確保

常にロールバックできるようにしてください。

• Git 操作：git stash、バックアップブランチ
• ファイル操作：変更前にコピーする
• データ操作：トランザクションをロールバックする

例

例：質問するべき場合

ユーザー：「古いファイルを削除して」

分析：

• 破壊的な操作 ✗
• 解釈が複数ある ✗
• 明確な標準がない ✗

応答：

Which files should I delete? I found:
- Files unchanged >6 months: 23 files
- Files in deprecated/: 5 files
- Files marked TODO remove: 2 files

例：進めるべき場合

ユーザー：「パーサーにエラーハンドリングを追加して」

分析：

• 標準的な手法がある ✓
• 簡単に元に戻せる（git）✓
• ユーザーが PR を確認できる ✓

対応：ログ出力を含む try/catch を実装し、PR を作成します。

例：プレビューを提示して進める場合

ユーザー：「API レイヤーをリファクタリングして」

分析：

• 有効な方法が複数ある
• ただし、git で元に戻せる
• さらに、ユーザーが確認できる

対応：

Refactoring API layer. Proposed changes:

1. Extract authentication middleware
2. Standardize error responses
3. Add request validation

Creating branch: refactor/api-layer
Preview diff available before merge.

アンチパターン

質問しすぎる（非効率）

• 実装の詳細をすべて質問する
• 明白な選択について確認を求める
• コンテキストですでに回答されている質問を繰り返す

質問が少なすぎる（リスクが高い）

• 破壊的な操作を黙って進める
• 有効な解釈が複数あるのに、意図を決めつける
• セキュリティ上重要な操作の曖昧さを無視する

組み合わせ

以下と組み合わせます。

• conserve:response-compression - 直接的なコミュニケーション
• sanctum:git-workspace-review - コンテキストの把握
• imbue:scope-guard - スコープの管理

クイックリファレンス

状況	アクション
「X を削除」	どの X か確認します
「機能を追加」	標準的な方法で進めます
「バグを修正」	明らかな修正で進めます
「A/B のどちらかを選択」	希望を確認します
「クエリを最適化」	複数の方法がある場合は確認します
「コードをフォーマット」	プロジェクトのスタイルに従って進めます
「本番環境にデプロイ」	確認を求めます

完了条件

• 提案されたすべての自律的なアクションを意思決定 マトリックスで確認します。可逆性と曖昧さの各軸に基づき、「実行する」、 「プレビューしてから実行する」、または「確認する」という明確な判定を下します
• 破壊的な削除、データ移行、後方互換性を破る変更などの不可逆な操作は、 意図が明確に見える場合でも、少なくとも 1 つの確認質問なしには実行しません
• 自律的に実行する場合は、4 つの安全策のいずれかを適用します。 ドライラン／プレビュー、バックアップ、段階的なコミット、または コミットメッセージへの前提条件の記載です
• 標準的な方法があり、変更を Git で簡単に元に戻せる場合、 「行動を優先する」表に記載されたシナリオでは確認質問をしません