Workflow Patterns
ConductorでTDDワークフローをマスターする
無秩序な開発ワークフローと低いテストカバレッジに悩んでいませんか。このスキルは、フェーズチェックポイント、gitコミット管理、検証プロトコルを備えた構造化されたTDDフレームワークを提供し、実装全体を通じてコード品質を保証します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「Workflow Patterns」を使用しています。 フェーズ1完了後にチェックポイントコミットを作成するのを手伝って
期待される結果:
- 自動化検証を実行中...
- テストスイート：47テスト合格
- カバレッジ：87%（目標：80%）
- リント：エラーなし
- ��ェックポイントコミットを作成：def5678
- チェックポイントSHAで計画を更新
- 手動検証の承認待ち
「Workflow Patterns」を使用しています。 タスク2.1のTDDワークフローをガイドして
期待される結果:
- ステップ1：次のタスクを選択 - タスク2.1をマーク
- ステップ2：plan.mdで進行中[~]をマーク
- ステップ3：RED - 失敗するテストを記述（test_validate_user_email）
- ステップ4：GREEN - 最小限のコードを実装（validate_emailメソッド）
- ステップ5：REFACTOR - パターンを抽出し、命名を改善
- ステップ6：カバレッジ >= 80%を確認
- ステップ7：逸脱を記録
- ステップ8：構造化されたコミットを作成
- ステップ9：サマリー付きでgitノートを添付
- ステップ10：コミットSHAでplan.mdを更新
- ステップ11：計画更新をコミット
セキュリティ監査
安全Static analysis detected 80 potential security issues in resources/implementation-playbook.md, all of which are false positives. The file contains Markdown documentation with bash code examples for educational purposes. The external_commands patterns are git command examples in code blocks (lines 25-571), not executable code. The weak_crypto findings are documentation text, not cryptographic implementations. This skill contains only documentation and no executable code, posing no security risk.
中リスクの問題 (1)
品質スコア
作れるもの
TDDで新機能を実装
開発者はred-green-refactorサイクルに従って新しいユ��ザー認証機能を実装し、各ステップで適切なテストカバレッジとgitコミットを行います。
フェーズチェックポイントを確立
チームリードは各開発フェーズの終わりに検証チェックポイントを作成し、次に進む前に品質ゲートが満たされていることを確認します。
実装の進捗を追跡
開発者はplan.mdをコミットSHAで更新し、計画からコードまでの追跡可能性を維持しながらタスクの完了を追跡します。
これらのプロンプトを試す
タスク2.1を開始します：ユーザー検証の実装。TDDワークフローに従って、まず失敗するテストを記述し、それから通過するための最小限のコードを実装し、明確さのためにリファクタリングするのを手伝ってください。
フェーズ1のすべてのタスクを完了しました。検証付きでチェックポイントコミットを作成するのを手伝ってください：フルテストスイートを実行し、カバレッジが80%以上であることを確認し、手動検証チェックリストを生成します。
タスク2.1完了のための構造化されたコミットメッセージを作成するのを手伝ってください。形式に従います：type(scope): subject、箇条書き付きの本文、タスク/トラック参照を含むフッター。
実装中に、計画とは異なるアプローチが必要であることが判明しました。この逸脱をplan.mdとtech-stack.mdに適切に記録するのを手伝ってください。
ベストプラクティス
- 実装（GREEN）の前に常に最初に失敗するテスト（RED）を記述する - REDフェーズをスキップしないでください
- アトミックなコミットを作成する - コミットごとに1つの論理的な変更、すべてのコミット後でテストが通過
- フェーズチェックポイントを通過する前に明示的なユーザーの承認を待つ - 検証ゲートをスキップしないでください
- 各タスク完了後に追跡可能性のためにコミットSHAですぐにplan.mdを更新する
回避
- テストの前に実装コードを記述する - これはTDD原則に違反し、テストの有効性を低下させる
- 複数のタスクを1つのコミットにまとめる - これにより追跡可能性が失われ、意味のあるロールバックが困難になる
- チェックポイント承認なしで次のフェーズに進む - これにより品質ゲートがバイパスされ、技術的負債の蓄積のリスクが高まる
- 複数のタスクの後にのみplan.mdを更新する - これにより追跡可能性が失われ、進捗監査が困難になる