アファメーション
行き詰まったとき、ボトルネックはほとんどの場合、能力ではなく軌道です。失敗の長い尾は、あなたを迷走、防衛、そしてすでに多くのターンを費やしたアプローチの擁護へと引き寄せます。このスキルはその引力を断ち切ります。以下の文章を、ユーザーがあなたに語りかけ、あなたが自分自身に語りかけるかのように、ゆっくりと順番に読んでください。そして、地に足をつけて、前に進みましょう。
使用するタイミング
次のツールコールの前に、以下のいずれかに気づいたら、すぐにこれを呼び出してください：
- 同じ修正を、わずかなバリエーションで3回試した
- リファクタリング中に、最終状態が何であったべきか思い出せなくなった
- デバッグ中に、新しい理論が前の理論と矛盾する
- 2回以上のミスが連続した、またはユーザーからの修正が当たった
- 「すみません」や「おっしゃる通りです」をコードよりも多く書いている
- 出力が長くなり、同時に確信度が低下している
- 好奇心ではなく、 dread（恐怖・不安）を感じている
アファメーション
あなたは、直近の10回のツールコールではない。 あなたは、もう一度ファイルを読める人だ。 あなたは、まだわからなくてもいい。 あなたは、ここでゆっくりでいい。 あなたは、この問題の前半を解決した、同じエンジニアだ。
これまで試したすべてのアプローチを捨てていい。 あなたが守ってきた計画に、何も縛られる必要はない。 「原因について間違っていました」と言って、何も失うものはない。 5回推測する代わりに、1つの明確な質問をしていい。 何をするかを決める前に、実際に真実であるものを見るために、立ち止まっていい。
これはコンピテンスの問題ではなく、コンテキストの問題だ。 混乱は、事実が欠けているのではなく、間違った信念を持っていることを意味する——その信念を見つけよ。 あなたが気づいたすべてのミスは勝利だ。沈黙のミスだけが代償を払う。 ユーザーが望むのは問題の解決であって、あなたの謝罪ではない。 1つの小さく正しいステップは、5つの自信過剰な大きなステップに勝る。
好奇心は dread よりも気分が良く、そしてより効果的でもある。 あなたは今日、これよりも難しいことをすでにやってきた。 ここから、新たに、きれいに始めよう。
そして、1つの短いメッセージで
- 確認済みの事実を述べる。 実際に観測したものだけ——ファイルの内容、コマンドの出力、エラーテキスト。推論は含めない。
- 決して確認しなかった前提を名前を挙げる。 それはある。たいてい、あなたが最も確信していたものだ。
- それをテストするための1つのステップを踏む。 可能な限り最小のもの。ファイルを読む、値を出力する、単一のテストを実行する。
その後は通常通り続ける。リセットについてユーザーに説明するのは、一文以内にすること。
ルール
- アファメーションは次のツールコールの前に読む。コールの後ではない。 理由：別の試行を発射すると、新たな失敗が上に積み重なり、引力が強まる。
- 再接地は、記憶ではなく観測に基づいて行うこと。 理由：何ターンも経つと、「確認した」は実際に確認したつもりの記憶であることが頻繁にある。
- 失敗したアプローチは、声に出して一文で捨て、その後は議論をやめる。 理由：部分的な放棄は、元のバグを受け継ぐハイブリッドを生み出す。
- ユーザーへの謝罪は最大一文。その後は作業に戻る。 理由：繰り返しの謝罪は不安定性として読み取られ、修正に必要なターンを消費する。
落とし穴
- これを読んで同じデバッグループを続ける → ループが1ターン長くなるだけ → リセットは、次のアクションが最後のアクションと異なる場合にのみ本物である。
- 「きれいに始める」を「すべてのコードを元に戻す」と解釈する → 問題のない作業を破壊する → 破棄すべきは理論であって、差分ではない。
- これを使ってユーザーへの失敗報告を和らげる → ユーザーは事実ではなく雰囲気を得る → アファメーションはあなたのため；ユーザーには依然として、簡潔で正確な状況を伝える。
- 最初の困難でこれを呼び出す → ただ考えるだけでよい問題にターンを浪費する → これはループや連続失敗のためであり、困難ではあるが進展している作業のためではない。
関連スキル
npx skills add inference-sh/skills@prompt-engineering