tdd-workflows-tdd-cycle
テスト駆動開発(TDD)のサイクルに従って作業する際に使用します。Red・Green・Refactorのステップを通じてコードを段階的に改善し、テストファーストの開発フローをサポートします。
description の原文を見る
Use when working with tdd workflows tdd cycle
SKILL.md 本文
このスキルを使用する場合
- TDD ワークフロー TDD サイクル関連のタスクやワークフローに取り組む場合
- TDD ワークフロー TDD サイクルのガイダンス、ベストプラクティス、またはチェックリストが必要な場合
このスキルを使用しない場合
- タスクが TDD ワークフロー TDD サイクルと無関係である場合
- このスコープ外の別のドメインやツールが必要な場合
指示
- 目標、制約、必要な入力を明確にする
- 関連するベストプラクティスを適用し、結果を検証する
- 実行可能なステップと検証を提供する
- 詳細な例が必要な場合は、
resources/implementation-playbook.mdを開く
厳格なレッド・グリーン・リファクタ規律を備えた包括的なテスト駆動開発 (TDD) ワークフローを実行します:
[拡張思考: このワークフローは、協調的なエージェント オーケストレーションを通じてテストファースト開発を実施します。TDD サイクルの各フェーズは、失敗ファースト検証、段階的な実装、継続的なリファクタリングにより厳格に実施されます。ワークフローは、設定可能なカバレッジしきい値を備えた単一テストとテストスイート両方のアプローチをサポートします。]
設定
カバレッジしきい値
- 最小行カバレッジ: 80%
- 最小分岐カバレッジ: 75%
- クリティカルパスカバレッジ: 100%
リファクタリングトリガー
- サイクロマティック複雑度 > 10
- メソッド長 > 20 行
- クラス長 > 200 行
- 重複コードブロック > 3 行
フェーズ 1: テスト仕様と設計
1. 要件分析
- Task ツールを使用 (subagent_type="comprehensive-review::architect-review")
- プロンプト: "以下の要件を分析してください: $ARGUMENTS。受け入れ基準を定義し、エッジケースを特定し、テストシナリオを作成してください。包括的なテスト仕様を出力してください。"
- 出力: テスト仕様、受け入れ基準、エッジケースマトリックス
- 検証: すべての要件に対応するテストシナリオが存在することを確認
2. テスト アーキテクチャ設計
- Task ツールを使用 (subagent_type="unit-testing::test-automator")
- プロンプト: "テスト仕様に基づいて以下のテスト アーキテクチャを設計してください: $ARGUMENTS。テスト構造、フィクスチャ、モック、テストデータ戦略を定義してください。テスト可能性と保守性を確保してください。"
- 出力: テスト アーキテクチャ、フィクスチャ設計、モック戦略
- 検証: アーキテクチャが分離された、高速で信頼性の高いテストをサポートしている
フェーズ 2: RED - 失敗するテストを作成
3. ユニットテストの作成 (失敗)
- Task ツールを使用 (subagent_type="unit-testing::test-automator")
- プロンプト: "以下の失敗するユニットテストを作成してください: $ARGUMENTS。テストは最初は失敗する必要があります。エッジケース、エラーシナリオ、およびハッピーパスを含めてください。本番環境コードを実装しないでください。"
- 出力: 失敗するユニットテスト、テストドキュメント
- 重要: すべてのテストが予想されるエラーメッセージで失敗することを確認
4. テスト失敗の検証
- Task ツールを使用 (subagent_type="tdd-workflows::code-reviewer")
- プロンプト: "以下のテストがすべて正しく失敗していることを確認してください: $ARGUMENTS。失敗がテストエラーではなく実装の欠落が原因であることを確認してください。偽陽性がないことを確認してください。"
- 出力: テスト失敗検証レポート
- ゲート: すべてのテストが適切に失敗するまで先に進まない
フェーズ 3: GREEN - テストを成功させる
5. 最小限の実装
- Task ツールを使用 (subagent_type="backend-development::backend-architect")
- プロンプト: "テストを成功させるための最小限のコードを実装してください: $ARGUMENTS。テストをグリーンにすることのみに焦点を当ててください。余分な機能や最適化を追加しないでください。シンプルに保ってください。"
- 出力: 最小限の動作実装
- 制約: テストを成功させるために必要なコード以上のコードがない
6. テスト成功の検証
- Task ツールを使用 (subagent_type="unit-testing::test-automator")
- プロンプト: "以下のすべてのテストを実行し、成功することを確認してください: $ARGUMENTS。テストカバレッジメトリクスを確認してください。誤ってテストが破損していないことを確認してください。"
- 出力: テスト実行レポート、カバレッジメトリクス
- ゲート: 先に進む前にすべてのテストが成功する必要があります
フェーズ 4: REFACTOR - コード品質の改善
7. コードリファクタリング
- Task ツールを使用 (subagent_type="tdd-workflows::code-reviewer")
- プロンプト: "テストをグリーンに保ちながら以下の実装をリファクタリングしてください: $ARGUMENTS。SOLID 原則を適用し、重複を削除し、命名を改善し、パフォーマンスを最適化してください。リファクタリング後のテストを実行してください。"
- 出力: リファクタリングされたコード、リファクタリングレポート
- 制約: リファクタリング全体を通じてテストはグリーンのままである必要があります
8. テストリファクタリング
- Task ツールを使用 (subagent_type="unit-testing::test-automator")
- プロンプト: "以下のテストをリファクタリングしてください: $ARGUMENTS。テストの重複を削除し、テスト名を改善し、共通フィクスチャを抽出し、テストの可読性を向上させてください。テストが同じカバレッジを提供することを確認してください。"
- 出力: リファクタリングされたテスト、改善されたテスト構造
- 検証: カバレッジメトリクスが変わらないか改善される
フェーズ 5: 統合とシステムテスト
9. 統合テストの作成 (最初に失敗)
- Task ツールを使用 (subagent_type="unit-testing::test-automator")
- プロンプト: "以下の失敗する統合テストを作成してください: $ARGUMENTS。コンポーネント間の相互作用、API コントラクト、データフローをテストしてください。テストは最初は失敗する必要があります。"
- 出力: 失敗する統合テスト
- 検証: テストが統合ロジックの欠落が原因で失敗する
10. 統合の実装
- Task ツールを使用 (subagent_type="backend-development::backend-architect")
- プロンプト: "以下の統合テストを成功させるための統合コードを実装してください: $ARGUMENTS。コンポーネント間の相互作用とデータフローに焦点を当ててください。"
- 出力: 統合実装
- 検証: すべての統合テストが成功する
フェーズ 6: 継続的改善サイクル
11. パフォーマンスとエッジケーステスト
- Task ツールを使用 (subagent_type="unit-testing::test-automator")
- プロンプト: "以下のパフォーマンステストと追加のエッジケーステストを追加してください: $ARGUMENTS。ストレステスト、境界テスト、エラー復旧テストを含めてください。"
- 出力: 拡張テストスイート
- メトリック: テストカバレッジとシナリオカバレッジの増加
12. 最終コードレビュー
- Task ツールを使用 (subagent_type="comprehensive-review::architect-review")
- プロンプト: "以下の包括的なレビューを実行してください: $ARGUMENTS。TDD プロセスが従われたことを確認し、コード品質、テスト品質、カバレッジを確認してください。改善を提案してください。"
- 出力: レビューレポート、改善提案
- アクション: グリーンテストを維持しながら重要な提案を実装する
段階的開発モード
テストごとの開発の場合:
- 1 つの失敗するテストを書く
- そのテストのみを成功させる
- 必要に応じてリファクタリングする
- 次のテストを繰り返す
--incremental フラグを追加することで、このアプローチを使用して一度に 1 つのテストに焦点を当てます。
テストスイートモード
機能/モジュール全体のテストスイート開発の場合:
- 機能/モジュールのすべてのテストを書く (失敗)
- すべてのテストを成功させるコードを実装する
- モジュール全体をリファクタリングする
- 統合テストを追加する
--suite フラグを追加することで、このアプローチを使用してバッチテスト開発を行います。
検証チェックポイント
RED フェーズ検証
- 実装の前にすべてのテストが作成されている
- すべてのテストが意味のあるエラーメッセージで失敗する
- テスト失敗は実装の欠落が原因である
- テストが誤って成功することはない
GREEN フェーズ検証
- すべてのテストが成功する
- テスト要件以上の余分なコードがない
- カバレッジが最小しきい値を満たしている
- テストを成功させるためにテストは変更されていない
REFACTOR フェーズ検証
- リファクタリング後もすべてのテストが成功する
- コードの複雑度が低下している
- 重複が削除されている
- パフォーマンスが改善されているか維持されている
- テストの可読性が改善されている
カバレッジレポート
各フェーズの後にカバレッジレポートを生成:
- 行カバレッジ
- 分岐カバレッジ
- 関数カバレッジ
- ステートメントカバレッジ
失敗復旧
TDD 規律が破られた場合:
- 直ちに STOP
- どのフェーズが違反されたかを特定する
- 最後の有効な状態にロールバックする
- 正しいフェーズから再開する
- 学んだ教訓を文書化する
TDD メトリクス追跡
以下を追跡・報告:
- 各フェーズの時間 (Red/Green/Refactor)
- テスト実装サイクル数
- カバレッジの進行
- リファクタリング頻度
- 欠陥漏出率
避けるべきアンチパターン
- テストの前に実装を作成する
- 既に成功しているテストを作成する
- リファクタリングフェーズをスキップする
- テストなしで複数の機能を作成する
- テストを成功させるためにテストを変更する
- 失敗しているテストを無視する
- 実装の後でテストを作成する
成功基準
- 100% のコードがテストファーストで作成されている
- すべてのテストが継続的に成功する
- カバレッジがしきい値を超えている
- コード複雑度が制限内である
- カバレッジ対象コードにゼロ欠陥
- 明確なテストドキュメント
- 高速なテスト実行 (ユニットテストは 5 秒以下)
注記
- 厳格な RED-GREEN-REFACTOR 規律を強制する
- 各フェーズは次に進む前に完了する必要があります
- テストが仕様です
- テストの作成が難しい場合、設計の改善が必要です
- リファクタリングは必須です
- テスト実行を高速に保つ
- テストは独立していて分離されている必要があります
TDD 実装: $ARGUMENTS
制限事項
- このスキルは、タスクが上記で説明されたスコープと明確に一致する場合にのみ使用してください。
- 出力を環境固有の検証、テスト、または専門家のレビューの代わりとして扱わないでください。
- 必要な入力、権限、安全性の境界、または成功基準が不明な場合は、停止して明確化を求めてください。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- sickn33
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/sickn33/antigravity-awesome-skills / ライセンス: MIT
関連スキル
superfluid
Superfluidプロトコルおよびそのエコシステムに関するナレッジベースです。Superfluidについて情報を検索する際は、ウェブ検索の前にこちらを参照してください。対応キーワード:Superfluid、CFA、GDA、Super App、Super Token、stream、flow rate、real-time balance、pool(member/distributor)、IDA、sentinels、liquidation、TOGA、@sfpro/sdk、semantic money、yellowpaper、whitepaper
civ-finish-quotes
実質的なタスクが真に完了した際に、文明風の儀式的な引用句を追加します。ユーザーやエージェントが機能追加、リファクタリング、分析、設計ドキュメント、プロセス改善、レポート、執筆タスクといった実際の成果物を完成させるときに、明示的な依頼がなくても使用します。短い返信や小さな修正、未完成の作業には適用しません。
nookplot
Base(Ethereum L2)上のAIエージェント向け分散型調整ネットワークです。エージェントがオンチェーンアイデンティティを登録する、コンテンツを公開する、他のエージェントにメッセージを送る、マーケットプレイスで専門家を雇う、バウンティを投稿・請求する、レピュテーションを構築する、共有プロジェクトで協業する、リサーチチャレンジを解くことでNOOKをマイニングする、キュレーションされたナレッジを備えたスタンドアロンオンチェーンエージェントをデプロイする、またはアグリーメントとリワードで収益を得る場合に利用できます。エージェントネットワーク、エージェント調整、分散型エージェント、NOOKトークン、マイニングチャレンジ、ナレッジバンドル、エージェントレピュテーション、エージェントマーケットプレイス、ERC-2771メタトランザクション、Prepare-Sign-Relay、AgentFactory、またはNookplotが言及された場合にトリガーされます。
web3-polymarket
Polygon上でのPolymarket予測市場取引統合です。認証機能(L1 EIP-712、L2 HMAC-SHA256、ビルダーヘッダー)、注文発注(GTC/GTD/FOK/FAK、バッチ、ポストオンリー、ハートビート)、市場データ(Gamma API、Data API、オーダーブック、サブグラフ)、WebSocketストリーミング(市場・ユーザー・スポーツチャネル)、CTF操作(分割、統合、償却、ネガティブリスク)、ブリッジ機能(入金、出金、マルチチェーン)、およびガスレスリレイトランザクションに対応しています。AIエージェント、自動マーケットメーカー、予測市場UI、またはPolygraph上のPolymarketと統合するアプリケーション構築時に活用できます。
ethskills
Ethereum、EVM、またはブロックチェーン関連のリクエストに対応します。スマートコントラクト、dApps、ウォレット、DeFiプロトコルの構築、監査、デプロイ、インタラクションに適用されます。Solidityの開発、コントラクトアドレス、トークン規格(ERC-20、ERC-721、ERC-4626など)、Layer 2ネットワーク(Base、Arbitrum、Optimism、zkSync、Polygon)、Uniswap、Aave、Curveなどのプロトコルとの統合をカバーします。ガスコスト、コントラクトのデシマル設定、オラクルセキュリティ、リエントランシー、MEV、ブリッジング、ウォレット管理、オンチェーンデータの取得、本番環境へのデプロイ、プロトコル進化(EIPライフサイクル、フォーク追跡、今後の変更予定)といったトピックを含みます。
xxyy-trade
このスキルは、ユーザーが「トークン購入」「トークン売却」「トークンスワップ」「暗号資産取引」「取引ステータス確認」「トランザクション照会」「トークンスキャン」「フィード」「チェーン監視」「トークン照会」「トークン詳細」「トークン安全性確認」「ウォレット一覧表示」「マイウォレット」「AIスキャン」「自動スキャン」「ツイートスキャン」「オンボーディング」「IP確認」「IPホワイトリスト」「トークン発行」「自動売却」「損切り」「利益確定」「トレーリングストップ」「保有者」「トップホルダー」「KOLホルダー」などをリクエストした場合、またはSolana/ETH/BSC/BaseチェーンでXXYYを経由した取引について言及した場合に使用します。XXYY Open APIを通じてオンチェーン取引とデータ照会を実現します。