Stats
Actions
Tags
From eld-plugin
TDDサイクル（RED-GREEN-REFACTOR）を強制するスキル。 Evidence Ladder L1（ユニットテスト）を最低条件として、テストなし実装を防止。 トリガー条件: - 「TDDで進めて」「テストファーストで実装して」「テスト駆動で」 - ELD Phase 3: Implementation中の各ステップで自動チェック - コミット前の自動検証（git-commit連携） - 「テストを先に書いて」
How this skill is triggered — by the user, by Claude, or both
Slash command
/eld-plugin:eld-ground-tdd-enforcerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
TDDサイクル（RED-GREEN-REFACTOR）を**強制**し、Evidence Ladder L1（ユニットテスト）達成を保証するスキル。
TDDサイクル（RED-GREEN-REFACTOR）を強制し、Evidence Ladder L1（ユニットテスト）達成を保証するスキル。 テストなし実装を許さず、Law Severity別のEvidence要件を満たすまで次に進ませない。
┌─ RED ─────────────────────────────────┐
│ 1. テスト作成（失敗することを確認） │
│ - Law/Term の観測写像をテスト化 │
│ - アサーションは具体的に │
│ - 期待値を明示 │
└──────────────────────────────────────┘
↓ テストが失敗（RED）
┌─ GREEN ───────────────────────────────┐
│ 2. 最小限の実装（テストが通る） │
│ - テストを通すだけのコード │
│ - 過剰な実装はしない │
│ - まずGREENにする │
└──────────────────────────────────────┘
↓ テストが成功（GREEN）
┌─ REFACTOR ────────────────────────────┐
│ 3. リファクタリング（動作を保ったまま）│
│ - 重複削除 │
│ - 名前の改善 │
│ - 構造の最適化 │
└──────────────────────────────────────┘
↓ テストが成功を維持
↓
次のサイクルへ（新しいテストケース）
詳細は references/tdd-cycle.md を参照。
テスト作成後、必ず失敗することを確認:
# テスト作成
# → テスト実行
# → 失敗することを確認（期待通りのエラーメッセージ）
違反検出:
S0 Law（ビジネスクリティカル）:
- L1（ユニットテスト）: 必須 - 違反時動作含む
- L2（統合テスト）: 必須
- L3（失敗注入）: 推奨
- L4（本番Telemetry）: 必須
S1 Law（機能要件）:
- L1（ユニットテスト）: 必須
- L2（統合テスト）: 推奨
- L4（本番Telemetry）: 推奨
S2 Law（品質要件）:
- L1（ユニットテスト）: オプション
- L4（本番Telemetry）: 推奨
強制ポイント:
詳細は references/evidence-ladder.md を参照。
# コミット前チェック
1. 変更されたコードに対応するテストが存在するか
2. すべてのテストが成功しているか
3. カバレッジが低下していないか
検出方法:
RED状態の許容時間:
- 5分以内: 正常（実装を続行）
- 5-15分: 警告（設計の見直しを提案）
- 15分超: 停止（タスクが大きすぎる。分解が必要）
停止条件:
詳細は references/enforcement-rules.md を参照。
実装開始前に、Law/Termの Evidence要件を確認:
対象 Law:
LAW-xxx (Severity: S0):
- Evidence要件: L1必須、L2必須、L4必須
- 既存テスト: なし → テスト作成が必須
対象 Term:
TERM-yyy (Type: Entity):
- 観測写像: ID検証、状態遷移チェック
- 既存テスト: なし → 観測写像のテストが必須
チェックポイント:
Law/Termの観測写像をテストコードに変換:
# 例: LAW-stock-non-negative (在庫数は常に0以上)
def test_stock_cannot_be_negative():
"""LAW-stock-non-negative: 在庫数がマイナスになる注文を拒否"""
product = Product(stock=5)
order = Order(quantity=10)
# 期待: 在庫不足エラー
with pytest.raises(InsufficientStockError) as exc_info:
product.reserve_stock(order)
# エラーメッセージ検証
assert "insufficient stock" in str(exc_info.value).lower()
# 在庫が変更されていないことを確認
assert product.stock == 5
チェックポイント:
assert True でないか）テスト実行 → 失敗を確認（RED状態）
テストを通す最小限のコードを書く:
class Product:
def __init__(self, stock: int):
self.stock = stock
def reserve_stock(self, order: Order):
if order.quantity > self.stock:
raise InsufficientStockError(
f"Insufficient stock: available={self.stock}, required={order.quantity}"
)
self.stock -= order.quantity
チェックポイント:
動作を保ったまま、コード品質を改善:
# リファクタリング例:
# - マジックナンバーの除去
# - 名前の改善
# - 重複の削除
class Product:
def __init__(self, stock: int):
if stock < 0:
raise ValueError("Stock cannot be negative")
self._stock = stock
@property
def stock(self) -> int:
return self._stock
def reserve_stock(self, order: Order):
self._validate_stock_availability(order.quantity)
self._stock -= order.quantity
def _validate_stock_availability(self, quantity: int):
if quantity > self._stock:
raise InsufficientStockError(
f"Insufficient stock: available={self._stock}, required={quantity}"
)
チェックポイント:
コミット前に Evidence Ladder 達成を確認:
# 自動チェックスクリプト
1. すべてのテストが成功しているか
2. S0/S1 Lawに対応するテストが存在するか
3. カバレッジが基準を満たしているか（S0: 100%, S1: 80%）
4. テストが追加/変更されているか
拒否条件:
/git-commit の前段階として自動実行:
実装完了
↓
TDD Enforcer チェック
- Evidence L1 達成確認
- テスト成功確認
- カバレッジ確認
↓ OK
git-commit
↓
コミット成功
拒否時のメッセージ:
❌ TDD Enforcer: コミット拒否
理由:
- LAW-stock-non-negative (S0) のテストが存在しません
- カバレッジが基準未満です: 現在 65%, 必要 80%
次のアクション:
1. test_stock_non_negative() を作成
2. テストを実行して成功を確認
3. 再度コミットを試行
以下の場合、TDD強制を緩和:
条件: 技術検証・実験的実装
対応:
- TDDスキップを明示的に宣言
- コミットメッセージに [prototype] タグ付与
- 本番マージ前に必ずテスト追加
条件: Severity S2 のLaw
対応:
- L1は推奨だが必須ではない
- L4（本番Telemetry）で代替可能
条件: テストのない既存コードの修正
対応:
- 修正箇所のみテスト追加（完全カバレッジ不要）
- Characterization Test（既存動作の記録）から開始
詳細は references/enforcement-rules.md を参照。
#!/bin/bash
# .git/hooks/pre-commit
# TDD Enforcer チェック
python scripts/tdd_enforcer_check.py
if [ $? -ne 0 ]; then
echo "❌ TDD Enforcer: テストまたはカバレッジ不足"
exit 1
fi
name: TDD Enforcer
on: [pull_request]
jobs:
tdd-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Run TDD Enforcer
run: |
pytest --cov --cov-fail-under=80
python scripts/evidence_ladder_check.py
詳細は references/ci-integration.md を参照。
unknownと言う勇気を持つ以下をすべて満たしたら TDD Enforcer 完了:
references/tdd-cycle.md - RED-GREEN-REFACTORサイクルの詳細references/enforcement-rules.md - 強制ルールと例外条件references/evidence-ladder.md - Evidence Ladder L1達成基準references/ci-integration.md - CI/CD統合ガイドUser: 在庫管理機能を実装して
Claude: 実装を開始する前に、TDD Enforcerで確認します。
## Evidence要件チェック
対象Law:
- LAW-stock-non-negative (S0): 在庫数は常に0以上
- Evidence要件: L1必須、L2必須、L4必須
- 現状: テストなし → 作成が必要
## TDDサイクル開始
### RED: テスト作成
まず、LAW-stock-non-negative のテストを書きます：
[テストコード作成]
[テスト実行 → 失敗を確認]
✅ RED状態を確認しました。
### GREEN: 最小実装
テストを通す最小限のコードを実装します：
[実装コード作成]
[テスト実行 → 成功を確認]
✅ GREEN状態になりました。
### REFACTOR: リファクタリング
コードを改善します：
[リファクタリング]
[テスト実行 → 成功を維持]
✅ REFACTOR完了。
## Evidence L1 達成確認
- LAW-stock-non-negative: テストあり ✅
- カバレッジ: 100% ✅
コミット可能です。
以下が発生したら即座に停止し、追加計測またはスコープ縮小：
npx claudepluginhub caphtech/claude-marketplace --plugin eld-pluginEnforces red-green-refactor TDD cycle with configurable strictness (strict/recommended/off). Use before writing implementation code for any feature or bugfix.
Enforces strict test-driven development: write a failing test first, then minimal code to pass, then refactor. Activates when TDD is explicitly requested or chosen for an atomic task.
Enforces strict TDD workflow for coding agents: requires test evidence before state changes (RED/GREEN/REFACTOR), minimal code, dependency promotion, outside-in development.