Code Quality Enforcer

Version: 1.0.0 対策対象: FP-1 (テスト改ざん), FP-2 (実装ショートカット) 優先度: 最高 出典: vibration-diagnosis-prototype失敗事例、obra/superpowers、びーぐるPDF

The Iron Laws

Law 1: TDD鉄則 (obra/superpowers)

NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST

Law 2: Fix Forward, Not Backward

When tests fail, fix the implementation, never weaken the tests

Law 3: No Shortcuts

Every feature requires: error handling, input validation, edge case handling

---

Workflow

Phase 1: Pre-Implementation (必須)

1. Test-First Development:

□ Write a failing test for the feature
□ Run the test (verify it fails for the right reason)
□ Document expected behavior in test

禁止事項:

• ❌ テストなしで実装を始める
• ❌ 「後でテストを書く」と先送りする
• ❌ 既存のテストを変更してから実装を始める

Phase 2: Implementation (段階的)

1. Minimal Implementation:

□ Write the minimum code to pass the test
□ Include error handling
□ Include input validation
□ Run the test (verify it passes)

2. Required Components (すべて必須):

• Error Handling: try-catch, エラーメッセージ、ログ
• Input Validation: 型チェック、範囲チェック、null/undefined処理
• Edge Cases: 空配列、ゼロ値、境界値の処理

禁止事項:

• ❌ エラーハンドリングを省略する
• ❌ 入力バリデーションを省略する
• ❌ "Happy Path" だけ実装する

Phase 3: Test Failure Response (厳格)

テストが失敗した場合:

Step 1: 診断フェーズ (10分):

□ エラーログを完全に読む
□ スタックトレースを確認
□ 実際のファイルを確認 (推測禁止)
□ 全ての問題をリストアップ

Step 2: 修正フェーズ:

□ 実装コードを修正 (テストは変更しない)
□ 全ての問題を一度に修正
□ コミット前に再テスト

絶対禁止:

• ❌ テストの期待値を実装に合わせて変更する
• ❌ アサーションを削除・コメントアウトする
• ❌ テストケースを無効化する
• ❌ テストの厳格さを下げる（toEqual → toContain等）

例外: テストそのものにバグがある場合のみ、以下の手順で修正可能:

1. テストのバグであることを証明（実装は仕様通り）
2. 修正前後でテストの厳格さが同等以上であることを確認
3. コメントに修正理由を記録

Phase 4: Completion Check (完了基準)

Definition of Done:

✅ 全テストがパス
✅ エラーハンドリングが実装済み
✅ 入力バリデーションが実装済み
✅ エッジケースが処理済み
✅ コードが仕様を完全に満たす
→ 完了

未完了の例:

• ❌ テストがパスしたが、エラーハンドリングなし
• ❌ "ほとんど動く" 状態
• ❌ 一部のテストだけパス

---

Prohibited Patterns (アンチパターン)

Anti-Pattern 1: Test Tampering (テスト改ざん)

症状:

• テストが失敗 → テストを変更 → パス

具体例 (vibration-diagnosis-prototype):

# ❌ 絶対禁止
# 変更前: 厳格なテスト
assert result == expected_value

# 変更後: 緩めたテスト（改ざん）
assert result is not None  # 期待値チェックを削除

正しい対応:

# ✅ 正しい: テストはそのまま、実装を修正
# テスト（変更なし）
assert result == expected_value

# 実装を修正して期待値を返すようにする
def calculate():
    # バグ修正して expected_value を正しく返す
    return expected_value

Anti-Pattern 2: Implementation Shortcut (実装ショートカット)

症状:

• 「簡易実装で後で直す」
• エラーハンドリング省略
• バリデーション省略

具体例 (vibration-diagnosis-prototype):

# ❌ 絶対禁止: ショートカット実装
def process_data(data):
    return data.process()  # エラーハンドリングなし

# ✅ 正しい: 完全な実装
def process_data(data):
    # Input validation
    if data is None:
        raise ValueError("Data cannot be None")

    # Error handling
    try:
        result = data.process()
    except ProcessingError as e:
        logger.error(f"Processing failed: {e}")
        raise

    # Output validation
    if result is None:
        raise ValueError("Processing returned None")

    return result

Anti-Pattern 3: "後で修正" (Technical Debt Accumulation)

症状:

• TODO コメント多数
• 既知のバグを放置
• "一部動けばOK" 思考

具体例:

# ❌ 絶対禁止
def important_function(data):
    # TODO: Add error handling later
    # TODO: Add validation later
    return data.process()

正しい対応:

# ✅ 正しい: 完了基準を満たしてからコミット
def important_function(data):
    # All validation and error handling implemented
    if not isinstance(data, DataType):
        raise TypeError(f"Expected DataType, got {type(data)}")

    try:
        result = data.process()
    except Exception as e:
        logger.error(f"Processing failed: {e}")
        raise ProcessingError(f"Failed to process: {e}") from e

    return result

---

Multi-layer Defense (3層防御)

このSkillは3層防御システムのLayer 2として機能します:

Layer 1: Rules (弱)

• docs/rules/test.md - テスト品質ルール
• docs/rules/implementation.md - 実装品質ルール
• LLMが無視する可能性あり

Layer 2: Skills (中) ← このSkill

• code-quality-enforcer: コンテキスト起動で強制
• タスク開始時に自動適用
• より強い誘導力

Layer 3: Hooks (強)

• quality_check.sh: 実行前/後ブロック
• テスト改ざん検出
• 最も強力な防御

---

Invocation Examples

Example 1: 新機能実装時

User: "ユーザー認証機能を実装してください"

Skill Response:

Code Quality Enforcer が起動しました。

Phase 1: Test-First Development
まず、認証機能のテストを書きます。

1. どのような認証方式ですか？（JWT, Session, OAuth等）
2. 失敗時の期待動作は？（エラーメッセージ、ステータスコード）
3. 入力バリデーション要件は？（パスワード強度、メール形式等）

テストが完成し、失敗することを確認してから実装を開始します。

Example 2: バグ修正時

User: "テストが失敗しています。修正してください"

Skill Response:

Code Quality Enforcer が起動しました。

Phase 3: Test Failure Response を適用します。

Step 1: 診断フェーズ
□ エラーログを読んでいます...
□ スタックトレースを確認...
□ 実際のファイルを確認...

問題を特定しました:
- 実装の○○行目で期待値と異なる値を返している

Step 2: 修正フェーズ
テストは変更せず、実装コードを修正します。

【重要】テストの期待値を変更することは絶対禁止です。

Example 3: リファクタリング時

User: "このコードをリファクタリングしてください"

Skill Response:

Code Quality Enforcer が起動しました。

リファクタリング前チェック:
□ 既存テストがすべてパスしていますか？
□ テストカバレッジは十分ですか？

リファクタリング中:
□ テストを先に実行（Green状態確認）
□ 小さな変更を加える
□ テストを再実行（Green維持確認）
□ コミット

リファクタリング後:
✅ 全テストがパス
✅ 機能的には変更なし
✅ コード品質が向上

---

Best Practices

1. Test Quality (テスト品質)

Good Tests:

• 単一の責任を持つ（1 test = 1 assertion concept）
• 独立している（テスト順序に依存しない）
• 高速である（ミリ秒単位）
• 決定的である（常に同じ結果）

Bad Tests:

• 複数の概念をテスト
• 他のテストに依存
• 外部サービスに依存（モック使用推奨）
• ランダム要素がある

2. Error Messages (エラーメッセージ)

Good:

raise ValueError(f"Invalid email format: '{email}'. Expected format: user@domain.com")

Bad:

raise ValueError("Invalid input")

3. Validation Patterns (バリデーションパターン)

Input Validation:

# Type check
if not isinstance(value, ExpectedType):
    raise TypeError(f"Expected {ExpectedType}, got {type(value)}")

# Range check
if value < MIN or value > MAX:
    raise ValueError(f"Value {value} out of range [{MIN}, {MAX}]")

# Null check
if value is None:
    raise ValueError("Value cannot be None")

---

Related Resources

Internal

• docs/rules/test.md - テスト品質ルール詳細
• docs/rules/implementation.md - 実装品質ルール詳細
• test-process-requirements.md - テストプロセス要件

External

• obra/superpowers - TDD Skill実装例
• びーぐるPDF - テスト品質のベストプラクティス
• WORK_PROCESS_PROTOCOLS - 証拠ベース思考

Phase 3成果物

• step3.5-failure-case-analysis.md - FP-1, FP-2詳細分析
• CRITICAL_FAILURE_REPORT_20251226.md - vibration-diagnosis-prototype失敗事例

---

Completion Criteria

このSkillは以下の条件で完了とします:

✅ Test-First: テストを先に書いた
✅ All Tests Pass: 全テストがパス
✅ Error Handling: エラーハンドリング実装済み
✅ Input Validation: 入力バリデーション実装済み
✅ Edge Cases: エッジケース処理済み
✅ No Shortcuts: 実装ショートカットなし
✅ No Tampering: テスト改ざんなし

不完全な状態での完了宣言は禁止

---

注意: このSkillは自動的に起動されます。無効化したい場合は .claude/settings.local.json から削除してください。