🛠️ TDD Workflows TDD Cycle
開発の初期段階からテストを書き、それに
📺 まず動画で見る(YouTube)
▶ 【衝撃】最強のAIエージェント「Claude Code」の最新機能・使い方・プログラミングをAIで効率化する超実践術を解説! ↗
※ jpskill.com 編集部が参考用に選んだ動画です。動画の内容と Skill の挙動は厳密には一致しないことがあります。
📜 元の英語説明(参考)
Use when working with tdd workflows tdd cycle
🇯🇵 日本人クリエイター向け解説
開発の初期段階からテストを書き、それに
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o tdd-workflows-tdd-cycle.zip https://jpskill.com/download/3574.zip && unzip -o tdd-workflows-tdd-cycle.zip && rm tdd-workflows-tdd-cycle.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/3574.zip -OutFile "$d\tdd-workflows-tdd-cycle.zip"; Expand-Archive "$d\tdd-workflows-tdd-cycle.zip" -DestinationPath $d -Force; ri "$d\tdd-workflows-tdd-cycle.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
tdd-workflows-tdd-cycle.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
tdd-workflows-tdd-cycleフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-17
- 取得日時
- 2026-05-17
- 同梱ファイル
- 1
💬 こう話しかけるだけ — サンプルプロンプト
- › Tdd Workflows Tdd Cycle を使って、最小構成のサンプルコードを示して
- › Tdd Workflows Tdd Cycle の主な使い方と注意点を教えて
- › Tdd Workflows Tdd Cycle を既存プロジェクトに組み込む方法を教えて
これをClaude Code に貼るだけで、このSkillが自動発動します。
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
このスキルを使用する場面
- TDDワークフローのTDDサイクルに関するタスクやワークフローに取り組む場合
- TDDワークフローのTDDサイクルに関するガイダンス、ベストプラクティス、またはチェックリストが必要な場合
このスキルを使用しない場面
- タスクがTDDワークフローのTDDサイクルと無関係な場合
- このスコープ外の異なるドメインやツールが必要な場合
手順
- 目標、制約、および必要な入力を明確にしてください。
- 関連するベストプラクティスを適用し、結果を検証してください。
- 実用的な手順と検証を提供してください。
- 詳細な例が必要な場合は、
resources/implementation-playbook.mdを開いてください。
厳格なレッド・グリーン・リファクタリングの規律をもって、包括的なテスト駆動開発(TDD)ワークフローを実行してください。
[拡張思考: このワークフローは、調整されたエージェントオーケストレーションを通じてテストファースト開発を強制します。TDDサイクルの各フェーズは、失敗ファースト検証、段階的実装、継続的リファクタリングによって厳密に強制されます。このワークフローは、単一テストとテストスイートの両方のアプローチを、設定可能なカバレッジしきい値でサポートします。]
設定
カバレッジしきい値
- 最小行カバレッジ: 80%
- 最小ブランチカバレッジ: 75%
- クリティカルパスカバレッジ: 100%
リファクタリングトリガー
- 循環的複雑度 > 10
- メソッド長 > 20行
- クラス長 > 200行
- 重複コードブロック > 3行
フェーズ1: テスト仕様と設計
1. 要件分析
subagent_type="comprehensive-review::architect-review"でTaskツールを使用してください。- プロンプト: 「$ARGUMENTSの要件を分析してください。受け入れ基準を定義し、エッジケースを特定し、テストシナリオを作成してください。包括的なテスト仕様を出力してください。」
- 出力: テスト仕様、受け入れ基準、エッジケースマトリックス
- 検証: すべての要件に対応するテストシナリオがあることを確認してください。
2. テストアーキテクチャ設計
subagent_type="unit-testing::test-automator"でTaskツールを使用してください。- プロンプト: 「テスト仕様に基づいて$ARGUMENTSのテストアーキテクチャを設計してください。テスト構造、フィクスチャ、モック、およびテストデータ戦略を定義してください。テスト容易性と保守性を確保してください。」
- 出力: テストアーキテクチャ、フィクスチャ設計、モック戦略
- 検証: アーキテクチャが分離された、高速で信頼性の高いテストをサポートしていることを確認してください。
フェーズ2: RED - 失敗するテストの作成
3. 単体テストの作成(失敗)
subagent_type="unit-testing::test-automator"でTaskツールを使用してください。- プロンプト: 「$ARGUMENTSの失敗する単体テストを作成してください。テストは最初に失敗する必要があります。エッジケース、エラーシナリオ、ハッピーパスを含めてください。プロダクションコードを実装しないでください。」
- 出力: 失敗する単体テスト、テストドキュメント
- 重要: すべてのテストが期待されるエラーメッセージで失敗することを確認してください。
4. テスト失敗の検証
subagent_type="tdd-workflows::code-reviewer"でTaskツールを使用してください。- プロンプト: 「$ARGUMENTSのすべてのテストが正しく失敗していることを確認してください。失敗が正しい理由(実装の欠如であり、テストエラーではない)によるものであることを確認してください。誤検知がないことを確認してください。」
- 出力: テスト失敗検証レポート
- ゲート: すべてのテストが適切に失敗するまで先に進まないでください。
フェーズ3: GREEN - テストをパスさせる
5. 最小限の実装
subagent_type="backend-development::backend-architect"でTaskツールを使用してください。- プロンプト: 「$ARGUMENTSのテストをパスさせるための最小限のコードを実装してください。テストをグリーンにすることのみに焦点を当ててください。余分な機能や最適化を追加しないでください。シンプルに保ってください。」
- 出力: 最小限の動作する実装
- 制約: テストをパスさせるために必要なもの以外のコードは含めないでください。
6. テスト成功の検証
subagent_type="unit-testing::test-automator"でTaskツールを使用してください。- プロンプト: 「$ARGUMENTSのすべてのテストを実行し、パスすることを確認してください。テストカバレッジメトリクスを確認してください。誤ってテストが壊れていないことを確認してください。」
- 出力: テスト実行レポート、カバレッジメトリクス
- ゲート: 先に進む前に、すべてのテストがパスする必要があります。
フェーズ4: REFACTOR - コード品質の向上
7. コードのリファクタリング
subagent_type="tdd-workflows::code-reviewer"でTaskツールを使用してください。- プロンプト: 「テストをグリーンに保ちながら、$ARGUMENTSの実装をリファクタリングしてください。SOLID原則を適用し、重複を削除し、命名を改善し、パフォーマンスを最適化してください。各リファクタリング後にテストを実行してください。」
- 出力: リファクタリングされたコード、リファクタリングレポート
- 制約: テストは常にグリーンである必要があります。
8. テストのリファクタリング
subagent_type="unit-testing::test-automator"でTaskツールを使用してください。- プロンプト: 「$ARGUMENTSのテストをリファクタリングしてください。テストの重複を削除し、テスト名を改善し、共通のフィクスチャを抽出し、テストの可読性を向上させてください。テストが同じカバレッジを提供し続けることを確認してください。」
- 出力: リファクタリングされたテスト、改善されたテスト構造
- 検証: カバレッジメトリクスが変更されていないか、改善されていることを確認してください。
フェーズ5: 統合テストとシステムテスト
9. 統合テストの作成(最初に失敗)
subagent_type="unit-testing::test-automator"でTaskツールを使用してください。- プロンプト: 「$ARGUMENTSの失敗する統合テストを作成してください。コンポーネント間の相互作用、API契約、およびデータフローをテストしてください。テストは最初に失敗する必要があります。」
- 出力: 失敗する統合テスト
- 検証: 統合ロジックの欠如によりテストが失敗することを確認してください。
10. 統合の実装
subagent_type="backend-development::backend-architect"でTaskツールを使用してください。- プロンプト: 「統合テストをパスさせるために、$ARGUMENTSの統合コードを実装してください。コンポーネント間の相互作用とデータフローに焦点を当ててください。」
- 出力: 統合実装
- 検証: すべての統合テストがパスすることを確認してください。
フェーズ6: 継続的改善サイクル
11. パフォーマンスとエッジケーステスト
subagent_type="unit-testing::test-automator"でTaskツールを使用してください。- プロンプト: 「$ARGUMENTSのパフォーマンステストと追加のエッジケーステストを追加してください。ストレステスト、境界テスト、およびエラー回復テストを含めてください。」
- 出力: 拡張されたテストスイート
- メトリクス: テストカバレッジとシナリオカバレッジの増加
12. 最終コードレビュー
subagent_type="comprehensive-review::architect-review"でTaskツールを使用してください。- プロンプト: 「$ARGUMENTSの包括的なレビューを実施してください。TDDプロセスが遵守されているか、コード品質、テスト品質、およびカバレッジを確認してください。改善点を提案してください。」
- 出力: レビューレポート、改善提案
- アクション: グリーンテストを維持しながら、重要な提案を実装してください。
インクリメント
(原文がここで切り詰められています)
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Use this skill when
- Working on tdd workflows tdd cycle tasks or workflows
- Needing guidance, best practices, or checklists for tdd workflows tdd cycle
Do not use this skill when
- The task is unrelated to tdd workflows tdd cycle
- You need a different domain or tool outside this scope
Instructions
- Clarify goals, constraints, and required inputs.
- Apply relevant best practices and validate outcomes.
- Provide actionable steps and verification.
- If detailed examples are required, open
resources/implementation-playbook.md.
Execute a comprehensive Test-Driven Development (TDD) workflow with strict red-green-refactor discipline:
[Extended thinking: This workflow enforces test-first development through coordinated agent orchestration. Each phase of the TDD cycle is strictly enforced with fail-first verification, incremental implementation, and continuous refactoring. The workflow supports both single test and test suite approaches with configurable coverage thresholds.]
Configuration
Coverage Thresholds
- Minimum line coverage: 80%
- Minimum branch coverage: 75%
- Critical path coverage: 100%
Refactoring Triggers
- Cyclomatic complexity > 10
- Method length > 20 lines
- Class length > 200 lines
- Duplicate code blocks > 3 lines
Phase 1: Test Specification and Design
1. Requirements Analysis
- Use Task tool with subagent_type="comprehensive-review::architect-review"
- Prompt: "Analyze requirements for: $ARGUMENTS. Define acceptance criteria, identify edge cases, and create test scenarios. Output a comprehensive test specification."
- Output: Test specification, acceptance criteria, edge case matrix
- Validation: Ensure all requirements have corresponding test scenarios
2. Test Architecture Design
- Use Task tool with subagent_type="unit-testing::test-automator"
- Prompt: "Design test architecture for: $ARGUMENTS based on test specification. Define test structure, fixtures, mocks, and test data strategy. Ensure testability and maintainability."
- Output: Test architecture, fixture design, mock strategy
- Validation: Architecture supports isolated, fast, reliable tests
Phase 2: RED - Write Failing Tests
3. Write Unit Tests (Failing)
- Use Task tool with subagent_type="unit-testing::test-automator"
- Prompt: "Write FAILING unit tests for: $ARGUMENTS. Tests must fail initially. Include edge cases, error scenarios, and happy paths. DO NOT implement production code."
- Output: Failing unit tests, test documentation
- CRITICAL: Verify all tests fail with expected error messages
4. Verify Test Failure
- Use Task tool with subagent_type="tdd-workflows::code-reviewer"
- Prompt: "Verify that all tests for: $ARGUMENTS are failing correctly. Ensure failures are for the right reasons (missing implementation, not test errors). Confirm no false positives."
- Output: Test failure verification report
- GATE: Do not proceed until all tests fail appropriately
Phase 3: GREEN - Make Tests Pass
5. Minimal Implementation
- Use Task tool with subagent_type="backend-development::backend-architect"
- Prompt: "Implement MINIMAL code to make tests pass for: $ARGUMENTS. Focus only on making tests green. Do not add extra features or optimizations. Keep it simple."
- Output: Minimal working implementation
- Constraint: No code beyond what's needed to pass tests
6. Verify Test Success
- Use Task tool with subagent_type="unit-testing::test-automator"
- Prompt: "Run all tests for: $ARGUMENTS and verify they pass. Check test coverage metrics. Ensure no tests were accidentally broken."
- Output: Test execution report, coverage metrics
- GATE: All tests must pass before proceeding
Phase 4: REFACTOR - Improve Code Quality
7. Code Refactoring
- Use Task tool with subagent_type="tdd-workflows::code-reviewer"
- Prompt: "Refactor implementation for: $ARGUMENTS while keeping tests green. Apply SOLID principles, remove duplication, improve naming, and optimize performance. Run tests after each refactoring."
- Output: Refactored code, refactoring report
- Constraint: Tests must remain green throughout
8. Test Refactoring
- Use Task tool with subagent_type="unit-testing::test-automator"
- Prompt: "Refactor tests for: $ARGUMENTS. Remove test duplication, improve test names, extract common fixtures, and enhance test readability. Ensure tests still provide same coverage."
- Output: Refactored tests, improved test structure
- Validation: Coverage metrics unchanged or improved
Phase 5: Integration and System Tests
9. Write Integration Tests (Failing First)
- Use Task tool with subagent_type="unit-testing::test-automator"
- Prompt: "Write FAILING integration tests for: $ARGUMENTS. Test component interactions, API contracts, and data flow. Tests must fail initially."
- Output: Failing integration tests
- Validation: Tests fail due to missing integration logic
10. Implement Integration
- Use Task tool with subagent_type="backend-development::backend-architect"
- Prompt: "Implement integration code for: $ARGUMENTS to make integration tests pass. Focus on component interaction and data flow."
- Output: Integration implementation
- Validation: All integration tests pass
Phase 6: Continuous Improvement Cycle
11. Performance and Edge Case Tests
- Use Task tool with subagent_type="unit-testing::test-automator"
- Prompt: "Add performance tests and additional edge case tests for: $ARGUMENTS. Include stress tests, boundary tests, and error recovery tests."
- Output: Extended test suite
- Metric: Increased test coverage and scenario coverage
12. Final Code Review
- Use Task tool with subagent_type="comprehensive-review::architect-review"
- Prompt: "Perform comprehensive review of: $ARGUMENTS. Verify TDD process was followed, check code quality, test quality, and coverage. Suggest improvements."
- Output: Review report, improvement suggestions
- Action: Implement critical suggestions while maintaining green tests
Incremental Development Mode
For test-by-test development:
- Write ONE failing test
- Make ONLY that test pass
- Refactor if needed
- Repeat for next test
Use this approach by adding --incremental flag to focus on one test at a time.
Test Suite Mode
For comprehensive test suite development:
- Write ALL tests for a feature/module (failing)
- Implement code to pass ALL tests
- Refactor entire module
- Add integration tests
Use this approach by adding --suite flag for batch test development.
Validation Checkpoints
RED Phase Validation
- [ ] All tests written before implementation
- [ ] All tests fail with meaningful error messages
- [ ] Test failures are due to missing implementation
- [ ] No test passes accidentally
GREEN Phase Validation
- [ ] All tests pass
- [ ] No extra code beyond test requirements
- [ ] Coverage meets minimum thresholds
- [ ] No test was modified to make it pass
REFACTOR Phase Validation
- [ ] All tests still pass after refactoring
- [ ] Code complexity reduced
- [ ] Duplication eliminated
- [ ] Performance improved or maintained
- [ ] Test readability improved
Coverage Reports
Generate coverage reports after each phase:
- Line coverage
- Branch coverage
- Function coverage
- Statement coverage
Failure Recovery
If TDD discipline is broken:
- STOP immediately
- Identify which phase was violated
- Rollback to last valid state
- Resume from correct phase
- Document lesson learned
TDD Metrics Tracking
Track and report:
- Time in each phase (Red/Green/Refactor)
- Number of test-implementation cycles
- Coverage progression
- Refactoring frequency
- Defect escape rate
Anti-Patterns to Avoid
- Writing implementation before tests
- Writing tests that already pass
- Skipping the refactor phase
- Writing multiple features without tests
- Modifying tests to make them pass
- Ignoring failing tests
- Writing tests after implementation
Success Criteria
- 100% of code written test-first
- All tests pass continuously
- Coverage exceeds thresholds
- Code complexity within limits
- Zero defects in covered code
- Clear test documentation
- Fast test execution (< 5 seconds for unit tests)
Notes
- Enforce strict RED-GREEN-REFACTOR discipline
- Each phase must be completed before moving to next
- Tests are the specification
- If a test is hard to write, the design needs improvement
- Refactoring is NOT optional
- Keep test execution fast
- Tests should be independent and isolated
TDD implementation for: $ARGUMENTS
Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.