test-data-generation

テストデータの生成

使用する場面

• ビジネスルール、境界値、組み合わせ、プライバシー制約を網羅する再利用可能なテストデータセットを設計する必要がある場合に、このスキルを使用します。
• 既存の計画、結果、エビデンスセットをレビューし、実行可能な改善策を提示する場合に使用します。
• コンテキストが不完全でも、範囲を限定した初回の取り組みに価値がある場合に使用します。

出力形式の選択肢

• レビュー、実行、段階的な改善には、デフォルトで Markdown を使用します。
• ユーザーが表、CSV、JSON、チケットのフィールドを求めた場合は、リスク、エビデンス、優先度、境界値の情報を保持します。
• 機械処理される出力では、まずスキーマ、列挙値、必須フィールドを確認します。

使用方法

1. 入力仕様、実行ルール、最低限の網羅範囲、出力順序を含め、prompts/test-data-generation.md を読んで従います。
2. 判断に影響するコンテキストのみを追加します。対象範囲、環境、バージョン、制約、エビデンス、成功基準が該当します。
3. 入力を監査し、確認済みの事実、作業上の仮定、未解決の質問を分けます。
4. リスクとエビデンスの強さに基づいて優先順位を付け、すぐに実行またはレビューできる成果物を作成します。
5. 情報が不足している場合は、範囲を限定した初回の成果を提示し、裏付けのない結論を明示します。

参照ファイル

• ドメイン上の結果、有効な対照データ、エビデンスの不足を調整する際は、サニタイズされた入力、項目ごとのオラクル、再現可能な計算を確認するために、references/domain-decision-example.md を読みます。

• 常に prompts/test-data-generation.md を読みます。これは、このスキルの完全な実行仕様です。

• 評価または回帰テストでは、evals/eval.yaml と evals/cases/ 以下の関連ケースを読みます。

• references/、examples/、scripts/、output-formats.md は、これらのディレクトリが存在し、タスクで必要な場合にのみ読み込みます。

ドメイン実行の要点

1. 提供されたスキーマ、外部キー、一意性、状態の関係、シナリオのオラクルからグループを導き出します。シードとジェネレーターのバージョンを固定します。ルールが不足している場合は、フィールドや実在の個人情報を創作せず、UNKNOWN のままにします。
2. 有効な正常系／境界値データと、意図的な無効グループを分けます。他の関係性を保ちながら、違反する制約と、想定される許可／拒否の結果を明記します。無効な行を有効なグループに紛れ込ませてはいけません。
3. 一意性、外部キー、型／範囲、状態、再現性のチェックを含む、実際のサニタイズ済みサンプルを提示します。同じシードでは、単に手法の説明が一致するだけでなく、データの識別情報が再現される必要があります。
4. 出所、プライバシー制限、逆依存関係のクリーンアップを備えた、分離された ID／名前空間を使用します。権限が確認できない場合は、実在する個人データを収集しません。合成データだけでは、母集団を代表しているとは言えません。

主な制約

• 実在する個人の機微なデータを使用しないでください。
• 合成データ、マスキング済みデータ、本番環境に近いデータを区別してください。
• 生成データは再現可能で、クリーンアップ可能でなければなりません。
• エビデンスにないシステムの動作、フィールド、データ、指標、根本原因を決して創作しないでください。
• 重要な結論はエビデンスに紐付け、裏付けのない結論は検証方法を添えた仮説として明示してください。
• ビジネスへの影響、発生可能性、検出可能性に基づいて優先度を説明してください。

提出前チェックリスト

• 有効値と無効値、境界値、同値クラス、組み合わせ、参照整合性、状態、ロール、ローカライズ、プライバシー、クリーンアップを網羅した。
• 事実、仮定、不足事項、推奨事項を分けた。
• 高リスク項目に優先度、エビデンスの根拠、担当者または次のアクションを付けた。
• 一般論ではなく、検証可能な判断基準を定義した。
• 許可されていない本番環境への書き込みや破壊的な操作を行っていない。

よくある落とし穴

• 前提条件、期待結果、エビデンスを示さずにチェック項目を列挙する。
• すべてを高優先度とし、トレードオフを避ける。
• ドメインに即した推論の代わりに、ツール名や一般論を使う。
• 不完全な入力を理由に対応を拒否する、または不完全なエビデンスから確実な結論が得られるかのように扱う。

ベストプラクティス

• ビジネス上の損失、安全上の問題、リリースの阻害につながる可能性が最も高いパスから着手します。
• 最小限の検証可能な実験で不確実性を減らし、再現条件を記録します。
• 成果物を実行可能にし、別のエンジニアが独立してレビューできるようにします。