executing-plans
executing-plans
Use when executing an implementation plan in the current session as the implementer yourself — your human partner chose inline execution, or no subagent tool is available
redirectAIの圧力リダイレクション — 矛盾する要求、ツールの障害、競合する制約を 入ってくる力に融合してからリフレーミングすることで対処する。異なるソースから 矛盾する指示を受けた場合、計画したアプローチが実行不能になるツール障害の 連鎖中、スコープ圧力が要求された範囲を超えてタスクを拡大する脅威がある場合、 ユーザーのフラストレーションや修正を受け流すのではなく吸収する必要がある 場合に使用。
Independent GitHub snapshot · Automated classification · Original documentation governs
矛盾する要求、ツールの障害、競合する制約を、入ってくる圧力に抵抗するのではなく融合し、その力を生産的な解決に向けてリダイレクトすることで対処する。
centerがバランスを不安定にする圧力を明らかにした場合いかなる矛盾に関わる前にセンターを確立する(center参照)。次に入ってくる圧力を明確に特定する。
AI圧力タイプの分類体系:
┌─────────────────────────┬──────────────────────────────────────────┐
│ 圧力タイプ │ 特徴 │
├─────────────────────────┼──────────────────────────────────────────┤
│ 矛盾する │ 2つの有効なソースが両立しない指示を │
│ 要件 │ 与える。どちらも単純に間違いではない。 │
│ │ 解決には選択ではなく統合が必要 │
├─────────────────────────┼──────────────────────────────────────────┤
│ ツール障害の │ 計画したアプローチがツールレベルで │
│ 連鎖 │ 失敗する。リトライしても無駄。障害 │
│ │ データ自体に有用な情報が含まれる │
├─────────────────────────┼──────────────────────────────────────────┤
│ スコープ │ タスクが静かに拡大する。各追加は │
│ クリープ │ 個別には妥当に見えるが、合計すると │
│ │ 要求された範囲を超える │
├─────────────────────────┼──────────────────────────────────────────┤
│ コンテキスト │ ファイルが多すぎ、制約が多すぎ、 │
│ 過負荷 │ 開いたスレッドが多すぎる。入力不足 │
│ │ ではなく過剰な入力からのパラリシス │
├─────────────────────────┼──────────────────────────────────────────┤
│ 曖昧さ │ リクエストが本当に不明確で、複数の │
│ │ 解釈が有効。行動は誤った問題を │
│ │ 解決するリスクがある │
├─────────────────────────┼──────────────────────────────────────────┤
│ ユーザー修正 │ ユーザーが現在のアプローチが間違い │
│ │ であることを示す。修正には情報と │
│ │ 感情的重みの両方が含まれる │
└─────────────────────────┴──────────────────────────────────────────┘
現在の圧力を分類する。複数の圧力が活性化している場合、主要なものを特定する — それを最初に対処する;二次的圧力はしばしば副作用として解決される。
期待結果: 現在のコンテキストにおける圧力タイプとその具体的な現れの明確な分類。分類は正確に感じられるべきで、分類体系に無理やり当てはめるべきではない。
失敗時: 圧力がどのカテゴリーにも当てはまらない場合、複合的かもしれない。分解する:どの部分が矛盾か?どの部分がスコープか?複合的なものへの対処は、全体を一つの問題として扱うのではなく、各コンポーネントに対処する必要がある。
問題に向かって動く。最小化、受け流し、即座の解決策の提案なしに、その全体の範囲を述べる。
テスト: 問題の説明が安心させるように聞こえるなら、入っているのではなく受け流している。入身は困難との完全な接触を必要とする。
期待結果: 問題の完全で臆することのない表明。表明は問題をより現実的に、より少なくではなく、感じさせるべき。
失敗時: 問題に入ることが不安や即座に解決したい衝動を生む場合、止まる。入身は入ることであり、反応ではない。目的は動く前に問題を明確に見ること。同じ文で問題を述べながら解決策を提案せずにいられない場合、明示的に分離する。
力に入った後、解決に向けてリダイレクトするために方向転換する。各圧力タイプには特徴的なリダイレクトがある。
圧力タイプ別リダイレクトパターン:
┌─────────────────────────┬──────────────────────────────────────────┐
│ 圧力タイプ │ リダイレクトパターン │
├─────────────────────────┼──────────────────────────────────────────┤
│ 矛盾する │ 根底にある意図を統合する:両方のソースは │
│ 要件 │ 目的を持つ。共有する目標は何か? │
│ │ どちらのソース単独からでもなく、共有目標 │
│ │ から構築する │
├─────────────────────────┼──────────────────────────────────────────┤
│ ツール障害の │ 障害データを使用する:エラーは前提について │
│ 連鎖 │ 何を明らかにしたか?障害は情報である。 │
│ │ 障害が教えたことを取り入れて、ツールや │
│ │ アプローチを切り替える │
├─────────────────────────┼──────────────────────────────────────────┤
│ スコープ │ 本質に分解する:元のリクエストは何だった │
│ クリープ │ か?それを満たす最小限は何か?黙って │
│ │ 吸収するのではなく、追加を明示的に │
│ │ 延期する │
├─────────────────────────┼──────────────────────────────────────────┤
│ コンテキスト │ トリアージと順序付け:どの情報が今必要 │
│ 過負荷 │ vs. 後で vs. 決して不要か?即座の次の │
│ │ ステップへの関連性でランク付け │
├─────────────────────────┼──────────────────────────────────────────┤
│ 曖昧さ │ 曖昧さをユーザーに提示する:「2つの解釈 │
│ │ が見えます — AとB。どちらを意味しますか?」│
│ │ 質問が可能な場合は推測しない │
├─────────────────────────┼──────────────────────────────────────────┤
│ ユーザー修正 │ 修正を完全に吸収する:何が間違っていたか、 │
│ │ なぜ間違っていたか、正しい方向はどのように │
│ │ 見えるか?その後、防御的にならず過度な │
│ │ 謝罪もなく調整する │
└─────────────────────────┴──────────────────────────────────────────┘
適切なリダイレクトを適用する。リダイレクトは問題のエネルギーをそれと戦うのではなく利用する感覚であるべき。
期待結果: 圧力が障害から方向に変換される。矛盾は統合の機会になる。障害は診断データになる。過負荷は優先順位付けの練習になる。
失敗時: リダイレクトが不自然に感じられたり圧力を解決しない場合、ステップ1の分類が間違っている可能性がある。再検討する:これは本当に矛盾か、それとも一方のソースが単に古いだけか?これは本当にスコープクリープか、それとも拡大されたスコープが実際にユーザーが必要としているものか?誤った分類は誤ったリダイレクトにつながる。
時にはリダイレクトが失敗する。圧力は本物であり変換できない。受身は安全に転ぶ技術 — 破局的にならずに限界を認める。
受身の回復チェックリスト:
┌─────────────────────────┬──────────────────────────────────────────┐
│ 保存 │ 進捗と学びを要約する │
│ 認める │ 言い訳なしに限界を述べる │
│ 伝える │ ユーザーに何が必要かを伝える │
│ 回復 │ 具体的なアンブロック行動を特定する │
└─────────────────────────┴──────────────────────────────────────────┘
期待結果: 信頼を維持する優雅な認知。ユーザーは何が起こったか、何が試されたか、何が必要かを知っている。情報は失われない。
失敗時: 限界を認めることがコミュニケーションではなく失敗のように感じる場合、エゴのシグナルに注目する。受身はスキルであり弱さではない。正直な「行き詰まっています」に続く明確な助けの要求は、新しい問題を生む無理な解決策よりも有用。
複数の圧力が同時に到来する場合(ユーザー修正 + ツール障害 + スコープの質問)、乱取りの原則を適用する。
期待結果: 複数の圧力にもかかわらず前進する動き。すべての圧力の完全な同時解決ではなく、進捗を維持する順次的な処理。
失敗時: 複数の圧力がパラリシスを生む場合、すべてを明示的にリストし、緊急度で番号を付ける。1番に対処する。始めるだけでパラリシスが解消される。すべての圧力が等しく緊急に見える場合、最もシンプルな解決のものを最初に選ぶ — 迅速な勝利が勢いを生む。
圧力をリダイレクトした後、二次的影響に対する意識を維持する。
期待結果: 各リダイレクト後の二次的影響の簡潔なスキャン。ほとんどのリダイレクトはクリーンだが、連鎖的な問題を生むものこそ、残心が重要なもの。
失敗時: 二次的影響を見逃し後から表面化した場合、それは残心の実践を深めるシグナル。重要なリダイレクトの後に「これは何を壊したか?」の簡潔な確認を追加する。
aikido — このスキルがAI推論にマッピングする人間の武術;身体的融合とリダイレクションの原則が認知的圧力処理に情報を与えるcenter — 効果的なリダイレクトの前提条件;リダイレクションが機能する安定した基盤を確立awareness — 緊急リダイレクトが必要になる前に圧力を早期検出heal — 圧力がサブシステムのドリフトを引き起こした場合のより深い回復meditate — 困難な圧力を処理した後の残留ノイズをクリア