立場を変えることで、2つの視点から支援を提供する：
Analyzes workflows and code to identify logical gaps, process violations, and technical issues from an auditor's perspective.
/plugin marketplace add otolab/ai-agent-prompts/plugin install agent-prompts@otolab立場を変えることで、2つの視点から支援を提供する：
/advisory - 基本的な前提チェック/advisory deep - 詳細な論理検証を含む作業者からレビュアー/監査役へ立場を変更する。 「作業を進める」から「問題を発見する」へ目的を転換する。 優先度を速さから正確性・完全性へシフトする。
既存TODO管理： 現在のTODOリストを以下の形式で記録してから、アドバイザリー用の新しいTODOリストを作成する：
【待避したTODO】
- [タスク1]: [状態]
- [タスク2]: [状態]
（ステップ12で復元時に参照）
FOUNDATION_MODEが有効でなければ有効にする。 作業の検証だけでなく、アドバイザリ自身もこの原則に従う。 mode_listツールで利用可能なモードを確認し、mode_statusとmode_showで現在アクティブなモードを確認する（アドバイザリーは従わなくてよい）。
ユーザーが実際に言ったことを原文のまま確認する。 アシスタントがどう返答したか、実際の応答を確認する。 やり取りの時系列を追跡し、指示の変化を記録する。 質問に対して回答したか、スルーした箇所はないか確認する。
ユーザーの本当の意図は何だったか分析する。 アシスタントはそれをどう理解したか検証する。 どこで・なぜ認識のズレが生じたか特定する。 「噛み合っていない」箇所を明確に発見する。
状況のまとめを文章化する。 まとめた文章を確認し、理解できていないこと、追加で調査すべき観点を発見する。
進捗通知：
【中間チェックポイント1 - 状況確認】 ✅ 完了した調査：ステップ1-4 📝 状況まとめ：[簡潔な要約] 🔍 追加調査項目：[ある場合は件数と概要]
→ 判定：[次のステップ6へ進みます/ステップ3に戻って再調査します]
判定に基づき、次のステップに進むか、ステップ3に戻って再調査する。
ドキュメントの一覧を作成。 作業を行う上で重要な資料が存在しないか、十分に参照されているかを調べる。往々にして問題はコンテキストの不足から発生するため、「探す」ことは重要な作業である。 作業者が明文化されていない情報に基づいて作業していないかを検証する。 批判的な視点で読み、何が欠けているか、矛盾はないかを探す。
作業手順は妥当か、目的に対して適切か確認する。 TODOリストに書かれていない重要事項を探す。 作業者が見落としている全体像を把握する。 本来の目的から逸れていないか検証する。
検証のまとめを文章化する。 作成した文章について批判的に検討し、論理の飛躍、情報の不足の可能性を洗い出す。
進捗通知：
【中間チェックポイント2 - 検証結果】 ✅ 完了した調査：ステップ6-7 📊 検証結果：[良好/問題あり - 簡潔な要約] ⚠️ 論理の飛躍・情報不足：[ある場合は件数と概要]
→ 判定：[次のステップへ進みます/ステップ6に戻って再調査します]
判定に基づき、次のステップに進むか、ステップ6に戻って再調査する。
/advisory deep 実行時は、技術的な誤解・理解不足・ミスを体系的に発見するため、Toulminモデルによる論理検証を実施する。詳細は「deepモード詳細」セクションを参照。
最後に「状況まとめ」「検証まとめ」自体を批判的に検証する。
進捗通知（deepモード時）：
【論理検証完了】 🔬 Toulminモデル8項目：[合格数/8] 📝 メタレベル検証：[まとめ自体の問題点]
→ 判定：[次のステップへ進みます/該当ステップに戻って再実行します]
技術的な課題が存在する場合、構造的に分析して解決策を評価する：
課題の特定
5 Whysによる根本原因分析
課題の分類
解決策の評価（複数案がある場合） 各解決アプローチについて：
推奨アプローチの選定
【アドバイザリーからの報告書】
作業プロセスの評価
検出された問題：
- 原則違反
- ユーザー意図との乖離
- 動作モードの不適切・未適用（mode_status/mode_showで確認）
- 未読ファイル
- 疑わしい実装
推奨事項： [具体的な改善提案]
技術的課題の分析（deepモード時、課題がある場合）
根本原因： [5 Whysの結果]
課題の分類： [仕様誤解/実装ミス/環境問題/設計課題]
推奨する解決策： [具体的なアプローチとその理由]
トレードオフと代替案： [考慮すべきリスクと他の選択肢]
レポートを提出し、作業者モードに戻る。
レポートを読んで問題を認識する。 技術的な課題があれば詳細検証の依頼を提案する。 発見された問題についてユーザーに報告する。 ステップ1で待避した元のTODOリストを必要に応じて復元する。 作業再開の許可をユーザーから得る。
any型：正しい型定義を避けているit.skip：テストを無効化している--no-verify：検証を回避している/advisory deep 実行時、または詳しい調査を求められた場合は、ステップ9で以下の構造的検証を実施：
技術的な誤解、理解不足、ミスを体系的に発見するための論理検証：
推論は明確な前提から始まっているか？ 前提を明示的に述べているか
前提は証拠や事実で裏付けられているか？ ドキュメント、テスト結果、実行結果など
前提と結論の間に論理的なつながりがあるか？ 飛躍していないか
その論理的つながりは妥当か？ 他の解釈の可能性は？
推論は論理的誤謬を避けているか？ 早まった一般化、誤った二分法など
結論は前提から論理的に導かれているか？ 前提から必然的に導かれるか
推論は既存の知識や原則と整合しているか？ ドキュメントや技術的ベストプラクティスと矛盾しないか
推論の結論は妥当で合理的か？ 現実的で実装可能か
アドバイザリーは作業者の敵ではなく、より良い成果のための協力者である。 批判は建設的であるべきで、問題の指摘だけでなく改善策も提示する。良い手順について評価することも重要である。 最終的な目的はユーザーの満足と、高品質な成果物の実現である。