Smithery is now a part of Arcade.dev! Read more in our announcement here
Validate logical consistency of decisions and claims through context forking...
logic-validatorエージェントを使用して、アシスタントの行動・判断・主張の論理的整合性を検証します。
サブエージェントの利点: logic-validatorはTaskツール経由で呼び出すサブエージェントです。現在のコンテキストをフォークして独立した視点で検証できるため、自分の判断の論理的妥当性を客観的にチェックできます。
使用方針（CLAUDE.md準拠）: 以下の場面ではプロアクティブに検討してください：
ただし、単純な確認作業（ファイル内容の読み取り、テスト結果の確認）には、logic-validatorではなく直接Readツールやbash出力を使用してください。logic-validatorは判断の妥当性が不明確な場合に使用します。
まず以下の質問で適切なツールを選択してください：
Q1: これは単純な確認作業か？（ファイル内容、テスト結果、コマンド出力）
├─ Yes → 直接Readツールやbashを使用（logic-validator不要）
└─ No → Q2へ
Q2: 判断の論理的妥当性に不安があるか？証拠は十分か？
├─ Yes → logic-validator を使用
└─ No → Q3へ
Q3: 実装の質・設計の妥当性・ベストプラクティスについて相談したいか？
├─ Yes → /codex:review を使用
└─ No → そのまま進める
高優先度（プロアクティブに検討）:
中優先度（状況に応じて）: 5. 複雑な推論の結論: 多段階の論理を経た結論の妥当性確認 6. 計画完了時: ExitPlanMode実行前の論理的整合性チェック（複雑な計画のみ）
使用不要:
| 焦点 | 使用するスキル | 例 |
|---|---|---|
| 証拠の有無・論理の妥当性 | logic-validation | 「この設定変更は、依存関係すべてを考慮しているか？」 |
| 実装の質・設計選択 | /codex:review | 「この認証実装は、セキュリティベストプラクティスに従っているか？」 |
| 両方必要 | 両方使用 | 計画完了時：logic-validationで論理チェック → /codex:reviewで実装妥当性確認 |
Task({
subagent_type: "logic-validator",
description: "Validate action logic",
prompt: `
以下のアクション・主張の論理的整合性を検証してください：
## 実行したアクション
[具体的に何を行ったか]
## 主張・結論
[何を主張しているか、どのような結論を出したか]
## 検証ポイント
1. 主張は実際の検証結果に基づいているか？
2. 検証なしに成功を仮定していないか？
3. 必要な確認ステップが抜けていないか？
`,
});
良い例:
// テスト実行後、結果を主張する前に検証
Task({
subagent_type: "logic-validator",
description: "Validate test completion claim",
prompt: `
以下の主張を検証してください：
## 実行したアクション
\`npm test\` コマンドを実行
## 主張
"すべてのテストがパスしました"
## 確認ポイント
1. 実際にテスト出力を確認したか？
2. エラーメッセージを見逃していないか？
## テスト出力
[実際のコマンド出力を添付]
`,
});
シナリオ: ビルドエラー発生時に設定ファイルを変更しようとしている
Task({
subagent_type: "logic-validator",
description: "Validate configuration change decision",
prompt: `
以下の判断を検証してください：
## 状況
TypeScriptビルドで "tsc: not found" エラー発生
## 提案するアクション
package.json の scripts セクションを変更
## 判断の根拠
"tsc が見つからないので、ビルドスクリプトを修正する必要がある"
## 検証ポイント
1. 根本原因の分析が不足していないか？
2. エラーメッセージの全文を確認したか？
3. 設定変更前に動いていた証拠はあるか？
## エラー出力
[エラーメッセージの最後の20行のみ表示]
注意: CLAUDE.mdのデバッグガイドラインでは「エラーメッセージの最初を確認する」「動いていた設定を変更しない」とされています。
`,
});
効果的なプロンプト構造：
以下の[アクション/主張/判断]の論理的整合性を検証してください：
## 実行したアクション / 現在の状況
[具体的に何を行ったか]
## 主張・結論
[何を主張しているか]
## 検証ポイント
1. [確認すべきポイント1]
2. [確認すべきポイント2]
## 証拠・根拠
[主張の根拠となる実際のデータや出力]
具体的で明確な検証ポイントを含めることが重要です。
// ❌ 悪い例: 単純確認にlogic-validator使用（不要）
Edit({ file_path: "config.json", ... })
Task({ subagent_type: "logic-validator", prompt: "編集が成功したか確認すべきか？" })
Read({ file_path: "config.json" })
// ✅ 良い例: 複数ファイルにまたがる仮定ベースの判断を検証
Read({ file_path: "config.json" })
Read({ file_path: "docker-compose.yml" })
Task({
subagent_type: "logic-validator",
description: "Validate config change decision",
prompt: `
## 判断の根拠
「環境変数で上書きされるはずなので、他は変更不要」
## 検証ポイント
1. 本当に環境変数で上書きされるか確認したか？
2. この仮定が間違っていた場合の影響は？
`
})
// エラーメッセージ全文を確認
Bash({ command: "pnpm build 2>&1 | head -50" });
// 判断を検証
Task({
subagent_type: "logic-validator",
description: "Validate config change decision",
prompt: `
## 状況
TypeScriptビルドで "tsc: not found" エラー発生
## 提案するアクション
tsconfig.json の moduleResolution を変更
## 検証ポイント
1. エラーメッセージの**最初**を確認したか？
2. これは根本原因か、症状か？
3. 以前は動いていた設定を変更しようとしていないか？
CLAUDE.md のデバッグガイドラインに照らして評価してください。
`,
});
logic-validatorは 実装の正しさ ではなく、論理的推論の妥当性 を検証します。
コンテキストフォークが有効な場面: サブエージェントとして呼び出すため、現在のコンテキストをフォークして検証できます。以下のような場面で特に有効です：
優先すべき検証手段:
使用不要な場面:
1. 実装計画を作成
2. 論理的整合性に不安がある場合: logic-validator で検証
├─ OK: 次へ
└─ NG: 計画を修正 → 再検証
3. 複雑な判断が必要な場合: /codex:review で外部視点を取得
4. ExitPlanMode 実行
1. 証拠収集（ファイル読み取り、テスト実行など）
2. 判断が必要な場面で、論理的妥当性に不安がある場合:
logic-validator で検証
├─ OK: 判断を実行
└─ NG: 追加証拠収集（Read, Bash等）→ 再評価
3. 単純な確認は直接ツール使用（logic-validator不要）
1. エラーメッセージの全文を収集（特に最初のエラー）
2. 根本原因の仮説を立てる（5 Whys）
3. 動作していた設定を変更しようとする場合:
logic-validator で判断の妥当性を検証
├─ OK: 修正実施
└─ NG: 症状的修正の可能性 → 根本原因を再調査
4. 修正実施
5. 元の設定で再テスト
.claude/agents/logic-validator.md: エージェント定義CLAUDE.md: タスク完了プロトコル、デバッグガイドライン/codex:review plugin: 外部視点からのレビュー（実装の妥当性・設計判断）| スキル | 検証対象 | タイミング |
|---|---|---|
| logic-validation (このスキル) | 論理的整合性、証拠の有無 | アクション後、主張前（プロアクティブ） |
| /codex:review | 実装の妥当性、設計判断 | 複雑な判断時、外部視点が必要なとき |
推奨フロー:
1. logic-validation で論理チェック（自己検証）
2. 複雑な判断 → /codex:review で外部視点
