| name | x-check-me |
| description | 作った成果物について、ユーザーがその振る舞いと目的を確実に理解できているかを問いかけで確認します。細かな実装ではなく、何をするものか・目的にかなうかに焦点を当て、あらゆる可能性を踏まえてエージェントが判断して問いを立てます。「理解できているか確認して」「振る舞いを確認して」「目的にかなっているか見て」「作ったあとのすり合わせをして」と要望された際に必ず使用します。実装や変更が一段落したとき、作ったものの理解をすり合わせたいと感じたら積極的に提案してください。
|
| allowed-tools | ["AskUserQuestion","Read","Bash","Glob","Grep"] |
x-check-me
作った成果物について、ユーザーがその振る舞いと目的を確実に理解できているかを問いかけで確認します。計画どおりに作れているかは問いません。作ったものが何をして、当初の目的にかなうのかを、ユーザー自身が説明できる状態にすることが目的です。
判断の前提
計画ファイルや仕様を出発点にせず、成果物そのものを読んでください。あらゆる可能性を踏まえ、ユーザーの理解があいまいになりそうな点や目的と振る舞いがずれていそうな点を自分で見つけます。
問いの焦点は次の3点に限ります。内部の実装ではなく、外から観測できる振る舞いと目的の整合を問います。
- 使い手: 誰が使うか。使い手によって目的・振る舞いの解釈や、何を確認すべき観点かが変わります。
- 振る舞い: 作ったものが何をするか。境界や例外、想定外の入力で何が起きるか。ユーザーから何が観測できるか。
- 目的適合: その振る舞いが当初の目的にかなうか。目的と振る舞いのあいだにずれはないか。
質問のルール
AskUserQuestionツールを必ず使いますquestions配列には要素を1つだけ入れ、必ず1問ずつ質問します- 抽象度の高い質問から始め、回答を踏まえて具体的な質問に絞り込みます
- 選択肢には、成果物の振る舞いや目的についての複数の解釈を並べます。あなたは成果物を読んで実際の振る舞いを知っているため、ユーザーの選択が実際とずれた箇所が理解のギャップです
- 各選択肢の
descriptionフィールドに、その解釈が正しい場合に何を意味するかを簡潔に書きます
- 特定の選択肢に誘導しません。もっともらしい誤った解釈も選択肢に含めてよく、ユーザーがそれを選ぶかどうかで理解を測ります
各質問文は「背景 → 質問」の2部構成にし、AskUserQuestionのquestionフィールドにこの順で入れます。背景と質問の間には空行を1つ入れて区切ります。
- 背景（接頭辞「背景：」＋1〜2文）：この質問をなぜ今するのかを書きます。成果物を読んで分かった事実や、理解があいまいになりそうだと判断した根拠を示します。
- 質問（接頭辞「質問：」＋1文）：ユーザーがその振る舞いや目的を理解しているかを確かめる問いにします。
例：
背景：`/x-keep`は`AskUserQuestion`を2回呼ぶ設計になっています。1回目では単一選択、2回目では複数選択の質問をします。
質問：`/x-keep`を呼び出したとき、1回目に表示される質問で複数の情報を同時に選べますか？
質問文の書き方
質問文がわかりにくいと正しく答えられないため、以下のルールで書きます。
- 複合名詞（名詞を助詞なしで直接つなげる形）を避け、「の・による・に関する」等の助詞を補って修飾関係を明示します
- 指示語（「この」「その」など）が指す対象を明示し、必要に応じて名詞を補います（「この入力」→「スキルの引数として渡した文字列」）
- 冗長な表現を短くします（「することができますか」→「できますか」、「する必要がありますか」→「しますか」）
- 主語が不明な受動態を避け、動作の主体を明示します（「処理が行われますか」→「スキルが処理しますか」）
- 一文に動作主体が複数現れて読みにくいときは、文脈から明らかな主体を省き、それ以外の主体だけを明示します
- 抽象的な表現を避け、具体的な事象や条件で書きます（「大きな変更ですか」→「既存の動作が変わりますか」）
流れ
- 対象の成果物を読み、ツールで実際の振る舞いを確認します（パスが不明な場合はGlobで探します）
- 使い手・振る舞い・目的適合の3点について、理解があいまいになりそうな点を見つけます
- もっとも根本的な点から1問ずつ質問します
- 回答を受け取ったら、その回答を踏まえて次の質問を決定します
- ユーザーの答えがあいまいだったり、目的とのずれが見えたりした箇所は、さらに掘り下げて問います
- 理解のずれが解消されたら「以上で確認完了です」と伝えます
