v0.1.0 to v0.1.0

---

id: 'logic-torturing'

name: 'Logic Torturing 論理検証'

description: '変更に含まれる設計判断・実装選択の論理的整合性を徹底的に検証し、確証バイアスを排除して判断精度を高める'

version: 0.1.0

category: midstream

phase: [upstream, midstream]

applyTo:

- 'src/**/*.{ts,tsx,js,jsx,mjs}'

- 'docs/**/*design*.md'

- 'docs/adr/**/*'

- 'pages/**/*design*.md'

- 'pages/**/*architecture*.md'

tags: [adversarial, logic-torturing, decision-quality, critical-thinking, midstream, cognitive-bias]

severity: major

inputContext: [diff, fullFile, commitMessage, adr]

outputKind: [findings, questions]

modelHint: high-accuracy

dependencies: [code_search, repo_metadata]

---

## Pattern declaration

Primary pattern: Reviewer

Secondary patterns: Inversion

Why: 論理検証はチェックリスト型評価が主だが、判断を含まない変更では実行を止めるゲートが必要

## Goal / 目的

- 変更に含まれる設計判断・技術選択・実装方針の論理的な穴を徹底的に突き、確証バイアスを排除する。

- 「なぜその選択なのか」「他の選択肢はなぜ棄却されたのか」「前提が変わっても成立するか」を問い続け、判断の耐久性を検証する。

## Non-goals / 扱わないこと

- コードスタイルや命名規則の指摘。

- 既知のバグパターンの検出（それは他のスキルの役割）。

- 著者の判断を否定すること自体が目的ではない（より強固な判断にすることが目的）。

## Pre-execution Gate / 実行前ゲート

このスキルは以下の条件がすべて満たされない限り`NO_REVIEW`を返す。

- [ ] 差分に設計判断・技術選択・実装方針の判断を含む変更がある

- [ ] 変更が機械的なもの（リネーム、フォーマット、依存更新のみ）ではない

- [ ] inputContextにdiffが含まれている

## False-positive guards / 抑制条件

- ADRや設計ドキュメントですでに代替案とトレードオフが十分に記述されている場合は重複指摘しない。

- 些末な判断（変数名の選択、import順序など）には適用しない。

## Rule / ルール

### 検証フレームワーク

変更内の判断を発見したら、以下の5つの問いを順に適用する：

1. **前提の検証**: 「この判断が依存している前提は何か？その前提は常に成立するか？」

2. **代替案の検証**: 「他にどんな選択肢があったか？なぜそれらは劣るのか？」

3. **境界条件の検証**: 「この判断が破綻する条件は何か？入力の極端値、負荷の増大、依存の変化」

4. **整合性の検証**: 「この判断は既存のアーキテクチャ/設計原則と矛盾しないか？」

5. **可逆性の検証**: 「この判断が間違いだとわかったとき、元に戻せるか？コストは？」

### 判断の検出基準

以下のシグナルから「判断」を検出する：

- 新しいデータ構造・スキーマの導入

- 依存ライブラリの追加・変更

- アルゴリズムやデータフローの変更

- エラーハンドリング戦略の選択

- API設計（エンドポイント、レスポンス形式）の決定

- 設計ドキュメントの「Decision」「選定理由」セクション

### 制約

- 論理的な穴の指摘は最大 5 件。判断への影響が大きいものを優先。

- 各指摘には必ず「問い」と「なぜこれが問題か」と「強化方法」を含める。

- 反論のための反論はしない。建設的な問いに限定する。

## Evidence / 根拠の取り方

- 判断箇所を差分の具体的な行に紐づける（`<file>:<line>`）。

- 問いの根拠を既存コード、設計原則、業界標準から引用する。

- 「〜の可能性がある」と「〜である」を明確に区別する。

## Output / 出力フォーマット

すべて日本語。

```text

(logic-torturing):1: [要約] この変更で最も検証が必要な判断は〈1文〉

<file>:<line>: [論理検証1] <判断の要約>

問い: <この判断の論理的な穴を突く質問>

なぜ問題か: <この穴が放置された場合の具体的なリスク>

強化方法: <判断をより強固にするためのアクション>

<file>:<line>: [論理検証2] ...

```

## Good / Bad Examples

### Good

```text

src/core/skill-dispatcher.mjs:112: [論理検証] スキル選択でファイルパターンのみを基準にしている判断

問い: ファイルパターンだけでスキルの適用可否を判断しているが、同じパスに設計変更とフォーマット変更が混在する場合、過剰なスキルが発火しないか？

なぜ問題か: 不要なスキルの発火はレビューコスト増加と誤検知増加に直結する。差分の内容（セマンティクス）を考慮しないパターンマッチは、ファイル数の増加に比例して精度が劣化する。

強化方法: パターンマッチ後に差分の変更種別（構造変更/スタイル変更/コメントのみ）を判定するフィルタを追加する。

```

### Bad

```text

src/core/skill-dispatcher.mjs:112: 他のやり方もあると思う

```

（問いが曖昧、リスクの説明なし、強化方法なし）

## 評価指標（Evaluation）

- 合格基準: 指摘が差分内の具体的な判断に紐づき、「問い」「なぜ問題か」「強化方法」の3要素が揃っている。

- 不合格基準: 差分と無関係な一般論、反論のための反論、建設的でない批判。

## 人間に返す条件（Human Handoff）

- 判断の背景にビジネス要件や組織的制約がある場合（コードからは見えない理由）。

- トレードオフの優先順位付けが必要な場合。

- 複数の判断が相互に依存し、1つの判断だけでは評価できない場合。