mcpField
P
platform-apex-generate

platform-apex-generate

github.com/forcedotcom開発1.1k7.2k 回インストール1 日前に更新
リポジトリ

platform-apex-generate について

platform-apex-generate はプロジェクト規約とセキュリティ、バルク処理の制約に沿って、Salesforce Apex のクラスやトリガーの作成・レビューを支援します。Apex 開発者向けで、報告前に解析とテストの実行を求めます。

主な機能

  1. 01Apex クラスとトリガーの生成
  2. 02プロジェクト規約の確認
  3. 03セキュリティとガバナ制限への対応
  4. 04コードアナライザーによる検証
  5. 05Apex テストの実行と報告

活用シーン

  1. 01Apex サービスやトリガーの新規作成
  2. 02Apex コードのリファクタリングやレビュー
  3. 03報告前の生成コード検証

MCP 対応

生成・更新した `.cls` ファイルに対する MCP `run_code_analyzer` の呼び出しを指示し、Apex テストにも MCP を使用できます。最終レポートにはツール出力または利用不可の状態を記載します。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/forcedotcom/sf-skills --skill platform-apex-generate

インストール後、Claude Code で/platform-apex-generateを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/
abstract.cls
batch.cls
domain.cls
dto.cls
exception.cls
interface.cls
invocable.cls
queueable.cls
rest-resource.cls
schedulable.cls
selector.cls
service.cls
trigger.cls
utility.cls
references/
AccountDeduplicationBatch.cls
AccountSelector.cls
AccountService.cls

詳細

Apex の生成

本番環境に対応した Apex の作成にこのスキルを使用します。新しいクラス、セレクター、サービス、非同期ジョブ、呼び出し可能メソッド、トリガーの作成、および既存の .cls または .trigger の根拠に基づくレビューが対象です。

必須入力

作成を始める前に、以下の情報を収集するか推定してください。

  • クラスの種類(サービス、セレクター、ドメイン、バッチ、キューアブル、スケジュール可能、呼び出し可能、トリガー、トリガーアクション、DTO、ユーティリティ、インターフェース、抽象クラス、例外、REST リソース)
  • 対象オブジェクトとビジネス目標
  • クラス名(以下の命名表に従って決定)
  • 新規作成か、リファクタリング/修正か。組織/API の制約があるか
  • デプロイ先(デフォルトでは runSpecifiedTests を使用し、該当する場合は生成したテストを使用)

特に指定がない場合のデフォルト:

  • 共有設定:with sharing(種類ごとの共有ルールは以下を参照)
  • アクセス修飾子:public(マネージドパッケージまたは @RestResource で必要な場合のみ global を使用)
  • API バージョン:66.0(最小バージョン)
  • ApexDoc コメント:あり

ユーザーの依頼が明確かつ完全であれば、不必要なやり取りをせず、すぐに生成してください。


ワークフロー

すべての手順を順番どおりに実行してください。省略、統合、順序の入れ替えはできません。作業が進められない場合は中断し、不足している情報を尋ねてください。該当しない場合は、レポートに理由を1行添えて N/A と記載してください。

フェーズ 1 — 作成
  1. プロジェクトの規約を確認する

    • Service-Selector-Domain レイヤー、ロギングユーティリティ
    • 既存のクラス/トリガーと、現在のトリガーフレームワークまたはハンドラーパターン
    • Trigger Actions Framework(TAF)がすでに使用されているか
  2. 最もシンプルで適切なパターンを選ぶ(以下の種類別ガイダンスを参照)

  3. テンプレートとアセットを確認する

    • 作成前に、assets/ の該当するテンプレートを読む(ファイルの対応関係は種類別ガイダンスを参照)
    • その種類の例が references/ にある場合は、具体的なスタイルガイドとして読む
    • テストクラスに関する作業では、必ず platform-apex-test-generate スキルを読み、使用する
  4. ガードレールに従って作成する -- 以下の「ルール」セクションのすべての規則を適用する

    • ApexDoc を付けて {ClassName}.cls を生成する
    • {ClassName}.cls-meta.xml を生成する
  5. テストクラスを生成する -- platform-apex-test-generate スキルを読み込み、{ClassName}Test.cls と {ClassName}Test.cls-meta.xml を作成する。デプロイには Apex テストの生成が常に必要です。platform-apex-test-generate スキルを読み込んでテストを生成しない限り、テストファイルの作成や編集はできません。

フェーズ 2 — 検証(報告前に必須)

ファイルの書き込みは中間地点であり、完了ではありません。手順 6 と 7 ではそれぞれツールの呼び出しが必要であり、その出力を手順 8 のレポートに記載する必要があります。両方の手順を実行して出力を取得するまで、要約やレポートの提示をしないでください。

  1. コードアナライザーを実行する

    • 生成または更新したすべての .cls ファイルに対して、MCP run_code_analyzer を呼び出す
    • すべての sev0、sev1、sev2 違反を修正し、問題がなくなるまで再実行する
    • 最終的なツール出力をそのまま取得し、レポートに記載する
    • フォールバック:sf code-analyzer run --target <target>。どちらも使用できない場合は、レポートに run_code_analyzer=unavailable: <error> と記録する
  2. Apex テストを実行する

    • sf apex run test または MCP を使用して、{ClassName}Test を含む組織のテストを実行する
    • すべてのテスト生成、修正、カバレッジ作業を platform-apex-test-generate に委任し、テストが合格するまで繰り返す
    • レポート用に合格/失敗件数とカバレッジ率を取得する
    • 使用できない場合は、レポートに test_execution=unavailable: <error> と記録する
フェーズ 3 — レポート
  1. レポート -- このファイルの末尾にある出力形式を使用する
    • Analyzer 行には、手順 6 の実際のツール出力を記載する(呼び出しを試みた後、使用できない場合は run_code_analyzer=unavailable: <reason> と記載)
    • Testing 行には、手順 7 の実際の結果を記載する(呼び出しを試みた後、使用できない場合は test_execution=unavailable: <reason> と記載)
    • どちらかの行が欠けているレポートは不完全です。使用不可と記録する前に、必ずツールの呼び出しを試みてください。

ルール

厳守すべき制約(必ず遵守)

生成するコードがいずれかの制約に違反する場合は、処理を停止し、先に問題を説明してください。

制約理由
すべての SOQL をループの外に配置するクエリのガバナー制限(100 クエリ)を回避します
すべての DML をループの外に配置するDML のガバナー制限(150 ステートメント)を回避します
すべてのクラスで共有キーワードを宣言する意図しない without sharing のデフォルト設定とデータ漏えいを防ぎます
ハードコードされた ID の代わりに、カスタムメタデータ/ラベル/describe 呼び出しを使用する組織間の移植性を確保します
常に例外を処理する(ログ記録、再スロー、または復旧)サイレント障害を防ぎます
ユーザー入力を含む動的 SOQL では、すべてバインド変数を使用するSOQL インジェクションを防ぎます
Java の型ではなく、Apex ネイティブのコレクション(List、Map、Set)を使用するコンパイルエラーを防ぎます
使用前に、Apex にメソッドが存在することを確認する存在しない API への依存を防ぎます
メインのコードパスで System.debug() を使用しないログ記録が有効でない場合でもデバッグステートメントは評価され、CPU を消費します。メインのコードパスで必要な場合は、ロギングフレームワークを使用してください
@future メソッドを決して使用しないSystem.Finalizer を使用する Queueable を使ってください。@future はチェーンできず、Batch から呼び出せず、プリミティブ以外の型も受け取れません
一括処理とガバナー制限
  • すべてのパブリック API はコレクションを受け取り、処理します。単一レコード用のオーバーロードは一括処理メソッドに処理を委譲します
  • バッチ/一括処理のフローでは、部分成功 DML(Database.update(records, false))を優先し、エラーに対して SaveResult を処理します
  • クエリ結果から ID に基づいて効率よく検索するには、Map<Id, SObject> コンストラクターを使用します
  • 子レコードを親ごとにグループ化するには、Map<Id, List<SObject>> を使用します。処理を始める前に、単一のループでマップを構築します
  • 重複排除とメンバーシップの確認には Set<Id> を使用し、List.contains() より Set.contains() を優先します
  • 親レコードと子レコードの両方が必要な場合は、リレーションシップサブクエリを使用して、単一の SOQL で取得します
  • ロールアップ計算では、Apex でクエリ結果を数える代わりに、GROUP BY を指定した AggregateResult を使用します
  • 実際に変更されたレコードのみを DML の対象にします。更新リストに追加する前に、Trigger.oldMap または以前の状態と比較します
  • 複雑なトランザクションでは、Limits.getQueries()、Limits.getDmlStatements()、Limits.getCpuTime() を使用して消費量を監視します
SOQL の最適化
  • 適切な WHERE 句を使って選択性の高いクエリを作成します。可能であれば、フィルターにはインデックス付きフィールド(Id、Name、OwnerId、参照/主従関係フィールド、ExternalId フィールド、カスタムインデックス)を使用します
  • SOQL に SELECT * はありません。必要なフィールドを必ず明示します
  • 結果セットの上限を定めるには LIMIT 句を適用し、決定的な結果を得るには ORDER BY を使用します
  • カスタムメタデータ型(__mdt で終わるオブジェクト)をクエリする場合、SOQL は使用しないでください。組み込みメソッド({CustomMdt__mdt}.getAll().values()、getInstance() など)を使用します
  • API バージョン 67.0 以降で without sharing キーワードを指定したクラス内で実行されるクエリは、実行ユーザーが適切なフィールドレベルまたはオブジェクトレベルのセキュリティ権限を持たない場合に例外をスローします。API バージョンを更新する場合は、クエリが適切に保護されていることを確認し、それに応じてテストも更新してください。デフォルトで許可するのは、クエリ内で SYSTEM_MODE バリアントを使用することが明示的に正当化されている場合に限ります
キャッシュ
  • 頻繁にアクセスされ、変更頻度が低いデータには Platform Cache(Cache.Org/Cache.Session)を使用します。TTL を設定し、キャッシュミスは必ず処理してください。キャッシュはいつでも削除される可能性があります
  • トランザクションスコープのキャッシュとして private static Map フィールドを使用し、同じ実行コンテキスト内でクエリが重複しないようにします。初回アクセス時に遅延初期化します
セキュリティ
  • デフォルトでは with sharing を使用します。without sharing または inherited sharing を使用する場合は、その理由をドキュメントに記載します
  • SOQL では WITH USER_MODE を、Database の DML では AccessLevel.USER_MODE を使用して CRUD/FLS を適用します。これらは、API バージョン 67.0 以上のすべての Apex クラスにおけるデフォルトです
  • 動的なフィールド名や演算子名は、許可リストまたは Schema.describe で検証します
  • 外部の認証情報や API キーには、すべて Named Credentials を使用します
  • ユーザー向けの @AuraEnabled エラーには AuraHandledException を使用します(内部情報は含めません)
  • without sharing を使用する場合は、Custom Permission のチェックが必要です
  • without sharing のロジックは専用のヘルパークラスに分離し、with sharing のエントリーポイントから呼び出して、昇格されたアクセスの範囲を制限します
  • PII/機密データは、保存時に Platform Encryption で暗号化します。デバッグステートメント、エラーメッセージ、API レスポンスで PII を公開してはいけません
セキュリティの検証

最終確定する前に、次の点を確認します。CRUD/FLS が適用されている(SOQL + DML)・すべてのクラスに明示的な共有キーワードがある・ハードコードされたシークレットや Record ID がない・PII がログやエラーメッセージに含まれていない・エンドユーザー向けのエラーメッセージがサニタイズされている。

エラー処理
  • 汎用的な Exception より先に、具体的な例外をキャッチします。メッセージにはコンテキストを含めます
  • try/catch は例外が発生する可能性のあるコード(DML、コールアウト、JSON の解析、キャスト)の周囲でのみ使用します。単純な代入、コレクション操作、算術演算を防御的にラップするのは避けます
  • 例外の原因チェーンを保持します。new CustomException('message', cause) を使用し、スタックトレースを連結したメッセージに置き換えないでください
  • 意味がある場合は、サービスドメインごとにカスタム例外クラスを用意します
  • @AuraEnabled メソッドでは、例外をキャッチして AuraHandledException として再スローします
  • 代替策:意味のあるドメイン例外がない場合は、汎用的な Exception をキャッチし、そのまま再スローするか、元の原因を保持する最小限のカスタム例外でラップします。
Null 安全性
  • すべての公開メソッドの先頭で、null/空の入力に対するガード節を追加します。コンテキストに合わせた形式にします。非公開メソッド/トリガーハンドラーでは早期に return し、公開 API では例外をスローし、検証サービスでは record.addError() を使用します
  • null ではなく空のコレクションを返します
  • プロパティへの連鎖アクセスには、安全ナビゲーション(?.)を使用します
  • 存在が保証されていない限り、map.get(key) をインラインで逆参照してはいけません。事前に containsKey を使用するか、値を変数に代入して null チェックを行うか、安全ナビゲーションを使用します
  • デフォルト値には Null 合体演算子(??)を使用します
  • value == null || value.trim().isEmpty() のような手動チェックより、String.isBlank(value) を優先します
定数とリテラル
  • 可能な場合は文字列定数より列挙型を使用します。列挙値には UPPER_SNAKE_CASE を使用します
  • 繰り返し使用される文字列/数値リテラルは、private static final 定数または定数クラスに切り出します
  • ユーザー向け文字列には Label. カスタムラベルを使用します
  • 設定可能な値(しきい値、マッピング、機能フラグ)には Custom Metadata を使用します
  • コード内に HTML エスケープされたエンティティ(例:&#39;)を出力してはいけません。Apex の文字列リテラルでは、単一引用符 ' をそのまま使用します
命名規則
種類パターン例
サービス{SObject}ServiceAccountService
セレクター{SObject}SelectorAccountSelector
ドメイン{SObject}DomainOpportunityDomain
バッチ{Descriptive}BatchAccountDeduplicationBatch
Queueable{Descriptive}QueueableExternalSyncQueueable
Schedulable{Descriptive}SchedulableDailyCleanupSchedulable
DTO{Descriptive}DTOAccountMergeRequestDTO
Wrapper{Descriptive}WrapperOpportunityLineWrapper
ユーティリティ{Descriptive}UtilStringUtil
インターフェースI{Descriptive}INotificationService
抽象クラスAbstract{Descriptive}AbstractIntegrationService
例外{Descriptive}ExceptionAccountServiceException
REST リソース{SObject}RestResourceAccountRestResource
トリガー{SObject}TriggerAccountTrigger
トリガーアクションTA_{SObject}_{Action}TA_Account_SetDefaults

追加の命名規則:

  • クラス:PascalCase
  • メソッド:camelCase。動詞(get、create、process、validate、is、has、can)で始めます
  • 変数:説明的な名詞を使ったcamelCase。リストは複数形の名詞(例:accounts、relatedContacts)、マップは{value}By{key}(例:accountsById)、セットは{noun}Idsにします
  • 定数:UPPER_SNAKE_CASE
  • 略語(acc、tks、rec)ではなく、完全で説明的な名前を使います
ApexDoc
  • クラスヘッダーとすべてのpublic/globalメソッドに必須です
  • 含める内容:簡潔な説明、役立つ場合は@param、@return、@throws、@example

クラスレベルの形式:

/**
 * Provides services for geolocation and address conversion.
 */
public with sharing class GeolocationService { }

メソッドレベルの形式:

/**
 * @param paramName Description of the parameter
 * @return Description of the return value
 * @example
 * List<Account> results = AccountService.deduplicateAccounts(accountIds);
 */
コード構造とアーキテクチャ
  • クラスごとの責務は1つにし、最大500行とします。超える場合は分割します
  • 早期リターン:メソッドの先頭で事前条件を検証し、すぐにリターンまたは例外を送出します
  • 約40行を超えるメソッドでは、プライベートヘルパーを抽出します
  • テスト可能性を高めるため、依存性注入(コンストラクター/メソッドのパラメーター)を使います
  • 深い継承よりもコンポジションと狭いインターフェースを優先します。変更ではなく、新しい実装で拡張します
  • レイヤー境界をまたぐ各メソッドでは、抽象化のレベルを1つに保ちます:
レイヤー担当する内容含めてはならない内容
トリガーイベントの振り分けのみビジネスロジック、オーケストレーション
ハンドラー/サービスフロー制御、調整インラインのSOQL/DML/HTTP/解析
ドメインビジネスルール、検証クエリ、コールアウト、永続化の詳細
データ/インテグレーションSOQL、DML、HTTPビジネス上の判断
  • 禁止事項:オーケストレーションとインラインのSOQL/DML/HTTPを混在させるメソッド、ビジネスルールと解析の内部処理を混在させること、検証・永続化・システム間連携を1つのメソッドにまとめること

非同期処理の選択マトリクス

シナリオデフォルト主な特性
標準的な非同期処理Queueableジョブ ID、チェーン、プリミティブ型以外の型、設定可能な遅延(AsyncOptions経由で最大10分)、重複排除シグネチャ
非常に大きなデータセットBatch Apexチャンク処理、同時実行は最大5件。大きなスコープにはQueryLocatorを使用します
最新のバッチ代替手段CursorStep(Database.Cursor)2000レコード単位のチャンク、より高いスループット、5ジョブの制限なし
定期的なスケジュールScheduled Flow(推奨)またはSchedulableSchedulableには100ジョブの上限があります。Batchへのチェーンや複雑なApexロジックが必要な場合にのみ使用します
ジョブ後のクリーンアップFinalizer(System.Finalizer)Queueableの成功・失敗にかかわらず実行されます
長時間実行されるコールアウトContinuation1トランザクションあたり最大3件、並列実行は3件
10分を超える遅延System.scheduleBatch()指定した将来の時刻にBatchジョブをスケジュールします
従来の起動後に結果を待たない処理@future新しいコードでは使用しないでください — Hard-Stop Constraintsを参照してください。Queueable + Finalizerに置き換えます

型固有のガイダンス

サービス
  • テンプレート:assets/service.cls · 参照:references/AccountService.cls
  • with sharing を使用します。ステートレスに保ちます — public フィールドや変更可能なインスタンス状態を持たせず、公開 API は目的を絞り、妥当な場合は static にします。
  • すべての SOQL をセレクターに、SObject の動作をドメインに委譲します。
  • ビジネスエラーはカスタム例外(例:AccountServiceException)でラップします。
セレクター
  • テンプレート:assets/selector.cls · 参照:references/AccountSelector.cls
  • inherited sharing を使用し、SObject またはクエリドメインごとに 1 つ作成します。
  • List<SObject> または Map<Id, SObject> を返します。共有の基本フィールドリスト定数を使用し、インラインで重複させないでください。
  • フィルターパラメーターを受け取り、常に WITH USER_MODE を含めます。
ドメイン
  • テンプレート:assets/domain.cls
  • with sharing を使用し、フィールドのデフォルト値、導出値、検証をカプセル化します。
  • インメモリのリストのみを操作します。SOQL/DML は使用しません(これらはサービス/セレクターの役割です)。
バッチ
  • テンプレート:assets/batch.cls · 参照:references/AccountDeduplicationBatch.cls
  • with sharing を使用し、Database.Batchable<SObject> を実装します(チャンクをまたいで状態を追跡する場合は Database.Stateful を追加します)。
  • start() = クエリの定義、execute() = ビジネスロジック、finish() = ログ記録/通知
  • 大規模なデータセットには QueryLocator を使用し、Database.SaveResult で部分的な失敗を処理します。
  • 再利用できるよう、コンストラクターでフィルターパラメーターを受け取ります。
キューアブル
  • テンプレート:assets/queueable.cls
  • with sharing を使用し、Queueable を実装します。HTTP コールアウトが必要な場合は、必要に応じて Database.AllowsCallouts も実装します。
  • コンストラクターでデータを受け取ります。
  • 無限チェーンを防ぐため、チェーン深度のガードを追加します。
  • 必要に応じて、復旧/クリーンアップ用に Finalizer を実装します。
  • 設定可能な遅延(最大 10 分)と重複排除シグネチャには AsyncOptions を使用します。
スケジュール可能
  • テンプレート:assets/schedulable.cls
  • with sharing を使用し、execute() から Queueable または Batch に処理を委譲します。
  • CRON 定数と、簡単に利用できる scheduleDaily() ヘルパーを用意します。
DTO/ラッパー
  • テンプレート:assets/dto.cls
  • 純粋なデータコンテナーのため、sharing キーワードは不要です。
  • シンプルな public プロパティ、引数なしおよびパラメーター付きコンストラクターを用意します。順序付けが必要な場合は Comparable を実装します。
  • シリアライズ/デシリアライズする private/protected な内部 DTO には @JsonAccess を使用します。
ユーティリティ
  • テンプレート:assets/utility.cls
  • sharing キーワードは不要です。すべてのメソッドを public static にし、private コンストラクターを用意します。
  • 純粋で副作用のない処理にします。SOQL/DML は使用しません。
インターフェース
  • テンプレート:assets/interface.cls
  • 各メソッドシグネチャに ApexDoc を付け、明確な契約を定義します。
抽象クラス
  • テンプレート:assets/abstract.cls
  • with sharing を使用し、virtual メソッドでデフォルトの動作を提供します。
  • 拡張ポイントには protected virtual または protected abstract を指定します。
  • ApexDoc に、クラスの拡張方法を示す具体例を含めます。
カスタム例外
  • テンプレート:assets/exception.cls
  • sharing キーワードは使用せず、説明的な名前を付けて Exception を拡張します。
  • サポートされるコンストラクター:(), ('msg'), (cause), ('msg', cause)
トリガー
  • テンプレート:assets/trigger.cls
  • オブジェクトごとにトリガーを 1 つ作成し、すべてのロジックをハンドラー/TAF アクションクラスに委譲します。
  • 関連するすべての DML コンテキストを含めます。TAF を使用する場合:new MetadataTriggerHandler().run();
トリガーアクション(TAF)
  • コンテキストごとに、関心事 1 つにつきクラスを 1 つ作成し、TriggerAction.{Context} を実装します。
  • Trigger_Action__mdt を介して登録します(登録されていないアクションは無効です)。
  • 名前:TA_{SObject}_{ActionName}。再帰防止には static ブール値よりもフィールド値の比較を優先します。
呼び出し可能なメソッド(@InvocableMethod)
  • テンプレート:assets/invocable.cls
  • with sharing を使用し、内部クラスの Request/Response には @InvocableVariable を指定します
  • メソッドは public static である必要があります。非 static のシグネチャや単一オブジェクトのシグネチャではコンパイルできません
  • List<Request> を受け取り、List<Response> を返します。バルク処理に対応させてください(SOQL/DML はループの外に記述します)
  • デコレーターのパラメーター:label(必須 — Flow Builder での表示名)、description、category(Builder でアクションをグループ化)、callout=true(メソッドが HTTP コールアウトを行う場合は必須)
  • @InvocableVariable のパラメーター:label(必須)、description、required=true/false
  • @InvocableVariable でサポートされる型は、プリミティブ型、Id、SObject、List<T> のみです(Map/Set/Blob は使用不可)。Flow のコレクション I/O には List<Id> または List<SObject> のフィールドを使用します
  • Response には必ず isSuccess、errorMessage、errorType(e.getTypeName())を含めます
  • エラーは Response で返してください(推奨)。例外をスローすると Flow の Fault パスが実行されるため、回復不能な障害の場合にのみ使用します
REST リソース(@RestResource)
  • テンプレート:assets/rest-resource.cls
  • global with sharing を指定し、クラスとメソッドの両方を global にします
  • バージョン付き URL:@RestResource(urlMapping='/{resource}/v1/*')
  • 分岐に応じて適切な HTTP ステータスコード(200/201/400/404/422/500)を使用します。すべてのエラーで既定の 500 を使用しないでください
  • 入力を検証します(Id 形式:Pattern.matches('[a-zA-Z0-9]{15,18}', value))。SOQL ではすべてのユーザー入力をバインドします
  • クエリには LIMIT/ORDER BY を含め、ページネーション(pageSize/offset)を実装します
  • 標準化された ApiResponse ラッパー(success、message、data/records)と、内部のリクエスト/レスポンス DTO を使用します
  • コントローラーは薄く保ち、ビジネスロジックを Service クラスに委譲します
@AuraEnabled コントローラー
  • with sharing を指定し、すべての SOQL で WITH USER_MODE を使用します
  • 読み取り専用のクエリにのみ @AuraEnabled(cacheable=true) を使用し、DML 操作では cacheable を設定しません
  • 例外をキャッチし、ユーザーにわかりやすいメッセージを指定した AuraHandledException として再スローします

出力要件

クラスごとの成果物:

  • {ClassName}.cls
  • {ClassName}.cls-meta.xml(指定がない場合、デフォルトの API バージョンは 66.0 以上)
  • {ClassName}Test.cls(platform-apex-test-generate スキルで生成)
  • {ClassName}Test.cls-meta.xml(platform-apex-test-generate スキルで生成)

トリガーごとの成果物:

  • {TriggerName}.trigger
  • {TriggerName}.trigger-meta.xml(指定がない場合、デフォルトの API バージョンは 66.0 以上)

メタ XML テンプレート:

<?xml version="1.0" encoding="UTF-8"?>
<ApexClass xmlns="http://soap.sforce.com/2006/04/metadata">
    <apiVersion>{API_VERSION}</apiVersion>
    <status>Active</status>
</ApexClass>

次の順序で報告します。

Apex work: <summary>
Files: <paths>
Design: <pattern / framework choices>
Workflow: all steps completed (1-8); any N/A justified
Risks: <security, bulkification, async, dependency notes>
Analyzer: <REQUIRED -- paste actual run_code_analyzer output or state "run_code_analyzer=unavailable: <reason>">
Testing: <REQUIRED -- paste actual test execution results (pass/fail, coverage) or state "test_execution=unavailable: <reason>">
Deploy: <dry-run or next step>

スキル間の連携

必要な作業委譲先
Apex テスト/失敗の修正platform-apex-test-generate スキル
オブジェクト/フィールドの詳細取得metadata スキル(利用可能な場合)
組織へのデプロイdeploy スキル(利用可能な場合)
Apex を呼び出す FlowFlow スキル(利用可能な場合)
Apex を呼び出す LWCLWC スキル(利用可能な場合)

トラブルシューティングの範囲

このスキルでは、本番環境の .cls/.trigger/.apex の問題のみを扱います。コンパイル/解析エラー、デプロイ時の依存関係エラー、実行時のガバナ制限エラーが対象です。テストの実行、アサーション、カバレッジ、sf apex run test の失敗については、platform-apex-test-generate に委譲してください。

コメント