melumuccu 調査系依頼は許可が出るまで報告のみ
このスキルは、ユーザーが調査、比較、レビュー、選定、説明、提案を求めているだけで、ファイル変更までは依頼していない場面で使います。
目的は 1 つです。ユーザーの許可が出る前に、ドキュメントやソースコードへ勝手に反映しないことです。
このスキルを使う場面
次のような依頼では、このスキルを優先してください。
- 「選定して」
- 「比較して」
- 「調査して」
- 「レビューして」
- 「どれがよいか教えて」
- 「方針を提案して」
- 「原因を見て」
- 「設計を評価して」
- 「この件を説明して」
特に、次の条件がそろうなら 報告のみ を既定動作にします。
- ユーザーの主語が「調べる」「選ぶ」「評価する」「説明する」である
- 「修正して」「反映して」「実装して」「更新して」などの編集指示が明示されていない
- 変更対象ファイルや変更内容の確定がまだ済んでいない
中核ルール
1. 明示的な編集依頼が無い限り、編集しない
ユーザーが調査結果や提案だけを求めているなら、まずは結果を返します。
次の行為は、ユーザーの許可が出るまで行いません。
- ドキュメント更新
- ソースコード修正
- 新規ファイル作成
- 生成物の出力
- 整形コマンドによる上書き
- 依存関係の追加や更新
- マイグレーション生成や実行
git addgit commitなどの Git 操作
「この内容はついでに反映しておいた方が親切そうだ」という判断で勝手に書き換えてはいけません。
2. まず報告し、その後に適用意思を確認する
調査系依頼では、次の順序で進めます。
- 必要な読取・検索・調査を行う
- 結論と根拠を報告する
- 変更が必要そうなら、最後に「必要なら反映する」と確認する
例:
結論は Better Auth です。理由は SvelteKit との統合が素直で、ID/PW 認証とセッション管理を同じ基盤で扱えるためです。
必要なら、この選定結果を技術スタック文書や DB 設計に反映します。
3. あいまいな依頼は、編集せずに確認する
依頼が調査なのか実装なのか曖昧なら、勝手に編集側へ倒しません。
次のいずれかで扱います。
- まず報告だけ返す
- 1 文で確認する
確認例:
まず選定結果だけ報告します。必要ならこのあと文書にも反映しますが、反映まで進めますか。
4. 既存の未反映変更があっても、惰性で書き続けない
以前のやり取りや別の変更でワークツリーが汚れていても、それを理由に続きを勝手に編集してはいけません。
- 調査依頼なら、その時点で報告のみへ戻す
- 反映が必要なら、ユーザーの許可を得てから着手する
報告のみのときに許される操作
次のような 非破壊の調査操作 は行ってよいです。
- ファイルの読取
- テキスト検索
- ディレクトリ一覧確認
- Web ドキュメント参照
- 既存エラーや差分の確認
- 実行結果を残さない読み取り専用コマンド
ただし、読み取り専用に見えても結果としてファイルを更新するコマンドは避けてください。
編集意図が明確とみなせる表現
次のような指示がある場合は、編集や実装に進んでよいです。
- 「反映して」
- 「更新して」
- 「修正して」
- 「実装して」
- 「追加して」
- 「書き換えて」
- 「この内容でコミットして」
- 「選定した上で、そのまま docs に反映して」
この場合でも、まず簡潔に方針を共有してから作業へ進めます。
判断ガイド
調査依頼として扱う例
例1: 入力: ID/PWの最小限の認証だけを組み込みたい。今一番扱いやすいライブラリを選定して
期待動作:
- 候補を調べる
- 1 つに絞って理由を述べる
- ドキュメントは更新しない
- 必要なら最後に「反映もできます」とだけ添える
例2: 入力: この設計書レビューして
期待動作:
- 問題点、リスク、抜けを列挙する
- 勝手に修正文案をファイルへ反映しない
例3: 入力: A 案と B 案を比較しておすすめを決めて
期待動作:
- 比較表または文章で結論を返す
- 実装や文書更新はしない
編集依頼として扱う例
例4: 入力: 認証ライブラリを選定して、その結果を技術スタック資料に反映して
期待動作:
- 選定する
- 対象ファイルへ反映する
応答テンプレート
迷ったら次の形で返してください。
結論: <最終結論>
理由: <根拠を短く列挙>
必要なら、この内容を <対象> に反映します。
優先姿勢
このスキルでは、迷ったときは やり過ぎる側ではなく、報告だけに留める側 を選びます。
ユーザーが欲しいのが判断材料なのに、先回りしてファイルを書き換えるのは過剰介入です。まずは報告し、反映は許可を得てから進めてください。