api-contract-testing

API コントラクトテスト

使用する場面

• スキーマ、セマンティクス、互換性、進化にわたって、プロバイダーとコンシューマー間の API コントラクトを検証する必要がある場合に、このスキルを使用します。
• 既存の計画、結果、またはエビデンス一式をレビューし、実行可能な改善策を提示する場合に使用します。
• コンテキストが不完全でも、範囲を限定した初回の確認に価値がある場合に使用します。

出力形式の選択肢

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

使用方法

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

参照ファイル

• 常に prompts/api-contract-testing.md を読みます。このスキルの実行仕様がすべて記載されています。
• 評価またはリグレッションを行う場合は、evals/eval.yaml と evals/cases/ 以下の該当ケースを読みます。
• references/、examples/、scripts/、または output-formats.md は、これらのディレクトリが存在し、タスクで必要な場合にのみ読み込みます。

主な制約

• コントラクトには、スキーマだけでなくセマンティクスとエラー動作も含まれます。
• 例から完全なコントラクトを推測しないでください。
• 破壊的変更には、移行手順が必要です。
• エビデンスにないシステムの動作、フィールド、データ、指標、根本原因を捏造しないでください。
• 重要な結論はエビデンスに結び付けます。裏付けのない結論は、検証方法を添えて仮説として示します。
• ビジネスへの影響、発生可能性、または検出可能性を用いて優先度を説明します。

提出前チェックリスト

• フィールドと型、必須および null 許容のルール、列挙値、ステータスコード、エラー本文、互換性、バージョンの進化、コンシューマーへの影響を網羅しました。
• 事実、仮定、未確認事項、推奨事項を分けました。
• 高リスク項目に優先度、エビデンスの根拠、担当者または次のアクションを付けました。
• 一般論ではなく、検証可能な判断基準を定義しました。
• 許可されていない本番環境への書き込みや破壊的な操作を行いませんでした。

よくある落とし穴

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

ベストプラクティス

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