performance-test-gatling

performance-test-gatling（EN）

中国語版： 対応する中国語スキルを参照してください。

使用する場面

• Gatling の構成に沿ったパフォーマンス出力が必要な場合。
• プロジェクトですでに Gatling を使用している場合、または Gatling 対応のシナリオが必要な場合。

ワークフロー

1. Progressive disclosure に記載されたメインプロンプト（網羅性、構成、品質基準）を読み、従ってください。
2. 結果に影響するプロジェクトのコンテキストのみ追加します。対象範囲、環境、制約、リスク、依存関係、期待する成果物などです。
3. 入力が不完全な場合は、使用可能な初稿を作成し、前提と不足情報を明示してください。
4. デフォルトは Markdown とし、ユーザーの要望がある場合にのみ形式を変更してください。

ドメイン実行の要点

1. プロジェクトの Gatling／プラグイン／JDK と Java／Scala／Kotlin DSL のバージョンを確認し、既存のレイアウトを維持してください。互換性のあるインジェクション／アサーション API を同一の DSL 内で使用します。生成した成果物をプロジェクトのビルドでオフラインのテストコンパイルにかけてください。依存関係がキャッシュされていない場合は、コンパイル成功ではなく BLOCKED とします。
2. オープンモデルはユーザーの到着を制御します。追加のループや再試行がなく、ユーザーあたりのリクエストが 1 件の場合に限り、到着率はリクエスト RPS と等しくなります。クローズドモデルは同時実行数を制御します。実際のリクエスト数と時間枠から RPS を確認してください。
3. フィーダーの消費量をユーザー／ループごとに計算してください。キューが枯渇した場合は明確に失敗させます。循環再利用にはポリシー上の許可と、ID／ビジネスキーの競合がないことが必要です。
4. プロジェクトのしきい値と、使用中のバージョンでサポートされているアサーションを使用してください。ゲートが未設定の場合は、500ms／1% の値を作り出さず、未設定の骨組みを提示します。コンパイル、達成負荷、SLO の結果は、それぞれ別の証拠です。

主な制約

• リスク／ビジネスへの影響に基づいて優先順位を付け、すべてを同等に扱わないでください。
• 確認済みの事実と現在の前提を分けてください。SLA／トラフィックの情報がない場合は、すべての数値に「前提」と明記し、未解決の質問を列挙してください。
• ユーザーから提供されていないエンドポイント、フィールド、環境、根本原因を作り出さないでください。シークレットにはプレースホルダー／環境変数のみを使用し、実際のトークンは決して使用しないでください。
• 出力は実行可能なものにしてください。具体的なシナリオ、明確な優先順位、明確な次の手順を示します。
• デフォルトでは最も重要な 1～2 種類のシナリオのみを対象にします。ベースライン／負荷／ストレス／スパイク／ソークをすべてデフォルトで実行しないでください。

段階的な開示

• ドメイン上の判断、妥当な制御方法、証拠の不足を調整する際は、サニタイズ済みの入力、項目ごとのオラクル、再現可能な計算について、references/domain-decision-example.md を読んでください。

• 出力を作成する前に、prompts/performance-test-gatling.md を読み、従ってください（最低限の網羅性、出力構成、品質基準）。

• 既製のテンプレートが適している場合は、output-templates/ 内の該当するファイルを使用してください。

• ユーザーが既存の成果物に沿った例を求めている場合は、関連する examples/ を読んでください。

• フレームワークの詳細、トラブルシューティング、スキーマのメモを確認する場合は、references/ 内の関連ファイルのみを読み、ディレクトリ全体を読み込まないでください。

• 形式の変換や補助的なチェックには、作り直すのではなく既存の scripts/ を優先して使用してください。

• このスキルを評価／回帰テストする場合は、skill-up と evals/ を使用してください。

提出前チェックリスト

• メインプロンプトの出力構成に従った
• 最低限の網羅性を確保した：対象シナリオ、負荷モデル、テストデータまたはフィーダーの要件、ランププロファイル、しきい値、環境とモニタリング、優先度の高いボトルネック、レポートの要件など（詳細はメインプロンプトを参照）
• 最低限のチェックリストを網羅した、または省略した項目の理由を説明した
• リスクの高い項目に明示的な優先順位を付けた
• ユーザーから提供されていない詳細を作り出していない
• 前提と不足情報を明記した

よくある落とし穴

• 対象範囲／コンテキストが不足しているのに、完全であるかのように装わないでください。

• すべての項目を同等に重要なものとして扱わないでください。

• 前提や情報不足を省略しないでください。

• 現在のツールチェーンに関係のない一般論を大量に並べないでください。

• DSL／JMX の成果物とデータ消費の境界を確認するには、evals/fixtures/java-dsl/README.md を読んでください。ローカルの例は成果物の調整には役立ちますが、プロジェクトのゲートなしでは合否判定の根拠になりません。