confirm-typo

name	confirm-typo
description	ユーザー入力に typo らしき箇所があり、修正候補が 1 つに強く絞れる状態で、実行前に意図した文言を確認すべきときに使う。

Confirm Typo

概要

確度の高い typo 修正の場合だけ一時停止する。ユーザーのメッセージ全体を 1 つの発話として扱い、修正候補を 1 つだけ示して短く確認し、承認後にだけ続行する。

ワークフロー

1. 文脈込みでユーザーの発話全体を読む。
2. 現在の文脈で不自然、または綴り間違いに見える文言を特定する。
3. 修正候補を作る。優先順は、現在の作業ディレクトリや repository にある既存名、近くの既知の識別子、一般的なコマンド・用語・skill 名とする。
4. 代替候補より明らかに強い候補が 1 つあり、修正後の依頼全体が自然に読める場合だけ確認する。
5. 質問には具体的な修正候補を 1 つだけ含める。
6. ユーザーが承認した場合は、修正後の解釈で元の依頼を続行する。
7. ユーザーが修正を否定した場合は、元の文言を維持し、ユーザーが新しい情報を出さない限り同じ代替案を再度押さない。

確信度のルール

次の場合だけ確認する。

• 提案する修正が元の文言より明らかに自然である。
• 候補群が実質的に 1 つの強い選択肢へ収束している。
• 修正後の文言が依頼全体にきれいに合う。
• 競合候補が十分弱く、1 つの修正だけを確認しても誤解を招かない。

次の場合は確認しない。

• 複数の候補が同程度に妥当なまま残っている。
• その文字列が意図的な名前、プロジェクト用語、任意の識別子である可能性が十分ある。
• 問題が typo ではなく、スタイル、略語、言い回しの好みに見える。
• 提案する修正によって、依頼の意味が大きく変わりそうである。

確認スタイル

次のような簡潔な確認にする。

• touch README.md でいいですか?
• README.md を作成 の意味でいいですか?
• brainstorming skill のことですか?

実行前に確認する。修正候補は 1 つだけ示す。長い説明や確信度のパーセンテージは避ける。

承認後の扱い

• ユーザーが承認した場合は、修正後の解釈で続行する。
• ユーザーが提案を否定した場合は、元の文言を尊重する。
• ユーザーが別の修正を示した場合は、ユーザーが示した文言を使う。
• 承認を受けるまでは、修正版を実行しない。