mcpField
G
generating-apex

generating-apex

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

generating-apex について

本番向け Salesforce Apex の生成とレビューを支援するスキルです。クラス、トリガー、非同期ジョブなどを扱い、結果の報告前にコード解析と Apex テストの実行を求めます。

主な機能

  1. 01Apex クラスとトリガーの作成ガイド
  2. 02プロジェクト規約の確認
  3. 03テンプレートと参考例の確認
  4. 04セキュリティとガバナ制限のルール
  5. 05コードアナライザーによる検証
  6. 06Apex テストの実行

活用シーン

  1. 01Apex サービス、セレクター、非同期ジョブの作成
  2. 02既存 Apex クラスやトリガーのレビュー
  3. 03デプロイに向けた Apex 変更の準備

MCP 対応

生成または更新した Apex ファイルの解析に `run_code_analyzer` MCP ツールを呼び出すよう定めています。MCP を使った Apex テスト実行も認めています。

インストール

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

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

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

同梱ファイル

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

CREDITS.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 コメント：あり

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

ワークフロー

すべての手順を順番に実行してください。省略、統合、順序の入れ替えは禁止です。作業が妨げられた場合は停止し、不足している情報を確認してください。該当しない場合は、レポートに一行の理由を添えて N/A と記載してください。

フェーズ 1 — 作成

  1. プロジェクトの規約を確認する

    • サービス・セレクター・ドメインのレイヤー構成、ログユーティリティ
    • 既存のクラス／トリガーと、現在のトリガーフレームワークまたはハンドラーパターン
    • Trigger Actions Framework（TAF）がすでに使用されているか

  2. 適切な最小限のパターンを選択する（以下の種類別ガイダンスを参照）

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

    • 作成前に、assets/ から該当するテンプレートを読み込む（ファイルの対応関係は種類別ガイダンスを参照）
    • その種類の references/ にサンプルがある場合は、具体的なスタイルガイドとして読み込む
    • テストクラスを作成する場合は、必ず generating-apex-test スキルを読み込んで使用する

  4. ガードレールを適用して作成する — 以下の「ルール」セクションにあるすべてのルールを適用してください

    • ApexDoc を付けて {ClassName}.cls を生成する
    • {ClassName}.cls-meta.xml を生成する

  5. テストクラスを生成する — generating-apex-test スキルを読み込み、{ClassName}Test.cls と {ClassName}Test.cls-meta.xml を作成します。デプロイには Apex テストを必ず生成する必要があります。generating-apex-test スキルを読み込まずに、テストファイルを作成または編集することはできません。

フェーズ 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 を含む組織のテストを実行します。
    • テストの生成、修正、カバレッジ対応はすべて generating-apex-test に委任し、テストが成功するまで繰り返します。
    • 成功／失敗の件数とカバレッジ率を取得し、レポートに記載します。
    • 利用できない場合は、レポートに 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() を優先します
  • 親レコードと子レコードの両方が必要な場合は、リレーションシップサブクエリを使い、1 回の 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() など）を使用します
キャッシュ
  • 頻繁にアクセスされ、変更頻度の低いデータにはプラットフォームキャッシュ（Cache.Org／Cache.Session）を使用します。TTL を設定し、キャッシュミスを必ず処理してください。キャッシュはいつでも破棄される可能性があります
  • 同じ実行コンテキスト内での重複クエリを防ぐには、トランザクションスコープのキャッシュとして private static Map フィールドを使用します。初回アクセス時に遅延初期化します
セキュリティ
  • デフォルトで with sharing を使用します。without sharing または inherited sharing を使用する場合は、その理由を文書化します
  • CRUD／FLS の適用には、SOQL で WITH USER_MODE、Database DML で AccessLevel.USER_MODE を使用します
  • 許可リストまたは Schema.describe を使用して、動的なフィールド名／演算子名を検証します
  • 外部の認証情報／API キーにはすべて名前付き認証情報を使用します
  • ユーザー向けの @AuraEnabled エラーには AuraHandledException を使用し、内部の詳細を含めないでください
  • without sharing を使用するには、カスタム権限のチェックが必要です
  • without sharing のロジックは専用のヘルパークラスに隔離し、with sharing のエントリーポイントから呼び出して、権限昇格の範囲を制限します
  • 個人情報／機密データは、保存時にプラットフォーム暗号化で暗号化します。デバッグステートメント、エラーメッセージ、API レスポンスで個人情報を公開しないでください
セキュリティ検証

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

エラー処理
  • 汎用的な Exception より先に具体的な例外を捕捉し、メッセージにコンテキストを含めます
  • 例外が発生する可能性のあるコード（DML、コールアウト、JSON の解析、キャスト）のみを try/catch で囲みます。単純な代入、コレクション操作、算術演算を防御的に囲むことは避けます
  • 例外の原因チェーンを保持します：new CustomException('message', cause)（スタックトレースを連結したメッセージで置き換えないでください）
  • 意味がある場合は、サービスドメインごとにカスタム例外クラスを用意します
  • @AuraEnabled メソッドでは、例外を捕捉して AuraHandledException として再スローします
  • 代替案：意味のあるドメイン例外がない場合は、汎用的な Exception を捕捉し、そのまま再スローするか、元の原因を保持する最小限のカスタム例外でラップします。
Null 安全性
  • すべての public メソッドの先頭で、null または空の入力に対するガード節を追加します。コンテキストに合わせた書き方にしてください：private メソッドやトリガーハンドラーでは早期に return し、public API では例外をスローし、検証サービスでは record.addError() を使用します
  • null ではなく空のコレクションを返します
  • 連鎖したプロパティアクセスにはセーフナビゲーション（?.）を使用します
  • 存在が保証されていない限り、map.get(key) をそのまま参照しないでください。先に containsKey を使う、値を代入して null チェックを行う、またはセーフナビゲーションを使用します
  • デフォルト値には null 合体演算子（??）を使用します
  • value == null || value.trim().isEmpty() のような手動チェックより、String.isBlank(value) を優先します
定数とリテラル
  • 可能な場合は文字列定数より enum を使用し、enum 値には UPPER_SNAKE_CASE を使用します
  • 繰り返し使われる文字列や数値のリテラルは、private static final 定数または定数クラスに切り出します
  • ユーザー向けの文字列には Label. カスタムラベルを使用します
  • 設定可能な値（しきい値、マッピング、機能フラグ）にはカスタムメタデータを使用します
  • コードで HTML エスケープされたエンティティ（例：&#39;）を出力しないでください。Apex の文字列リテラルでは、リテラルのシングルクォート ' を使用します
命名規則
種類パターン例
サービス{SObject}ServiceAccountService
セレクター{SObject}SelectorAccountSelector
ドメイン{SObject}DomainOpportunityDomain
バッチ{Descriptive}BatchAccountDeduplicationBatch
キュー可能{Descriptive}QueueableExternalSyncQueueable
スケジュール可能{Descriptive}SchedulableDailyCleanupSchedulable
DTO{Descriptive}DTOAccountMergeRequestDTO
ラッパー{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 の成否にかかわらず実行
長時間実行されるコールアウトContinuationトランザクションあたり最大 3 件、並列実行は 3 件
10 分を超える遅延System.scheduleBatch()特定の将来時刻に Batch ジョブをスケジュール
レガシーのファイア・アンド・フォーゲット@future新しいコードでは使用しないでください — ハードストップ制約を参照してください。Queueable + Finalizer に置き換えてください。

型ごとのガイダンス

サービス
  • テンプレート：assets/service.cls · 参考：references/AccountService.cls
  • with sharing を指定します。ステートレスに保ちます（public フィールドや変更可能なインスタンス状態は使用しません）。公開 API は目的を絞り、妥当な場合は static にします。
  • すべての SOQL は Selector に、SObject の動作は Domain に委譲します。
  • ビジネスエラーはカスタム例外（例：AccountServiceException）でラップします。
Selector
  • テンプレート：assets/selector.cls · 参考：references/AccountSelector.cls
  • inherited sharing を指定し、SObject またはクエリドメインごとに 1 つ作成します。
  • List<SObject> または Map<Id, SObject> を返します。共通のベースフィールドリスト定数を使用し、インラインで重複させないでください。
  • フィルターパラメーターを受け取り、常に WITH USER_MODE を含めます。
Domain
  • テンプレート：assets/domain.cls
  • with sharing を指定し、フィールドのデフォルト値、導出値、検証をカプセル化します。
  • メモリー内のリストのみを操作します。SOQL／DML は使用しません（Services／Selectors の担当です）。
Batch
  • テンプレート：assets/batch.cls · 参考：references/AccountDeduplicationBatch.cls
  • with sharing を指定し、Database.Batchable<SObject> を実装します（チャンクをまたいで状態を追跡する場合は Database.Stateful を追加します）。
  • start() = クエリ定義、execute() = ビジネスロジック、finish() = ログ記録／通知
  • 大規模なデータセットには QueryLocator を使用し、部分的な失敗は Database.SaveResult で処理します。
  • 再利用できるよう、コンストラクターでフィルターパラメーターを受け取ります。
Queueable
  • テンプレート：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
  • 純粋なデータコンテナーなので、共有キーワードは不要です
  • シンプルな public プロパティ、引数なしコンストラクターと引数付きコンストラクターを用意します。順序付けが必要な場合は Comparable を実装します
  • シリアライズ／デシリアライズされる private／protected の内部 DTO には @JsonAccess を使用します
ユーティリティ
  • テンプレート：assets/utility.cls
  • 共有キーワードは不要です。すべてのメソッドを public static にし、コンストラクターは private にします
  • 純粋で副作用のない処理にし、SOQL／DML は使用しません
インターフェース
  • テンプレート：assets/interface.cls
  • 各メソッドシグネチャに ApexDoc を付け、明確な契約を定義します
抽象クラス
  • テンプレート：assets/abstract.cls
  • with sharing を指定し、virtual メソッドでデフォルトの動作を提供します
  • 拡張ポイントには protected virtual または protected abstract を指定します
  • ApexDoc に、クラスの拡張方法を示す具体例を含めます
カスタム例外
  • テンプレート：assets/exception.cls
  • 共有キーワードは不要です。説明的な名前で 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 boolean よりフィールド値の比較を優先します
呼び出し可能メソッド（@InvocableMethod）
  • テンプレート：assets/invocable.cls
  • with sharing を指定し、内部に @InvocableVariable を持つ Request／Response を定義します
  • メソッドは 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 のコレクション入出力には 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（generating-apex-test スキルで生成）
  • {ClassName}Test.cls-meta.xml（generating-apex-test スキルで生成）

トリガーごとの成果物：

  • {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 テスト／失敗の修正generating-apex-test スキル
オブジェクト／項目の説明メタデータスキル（利用可能な場合）
組織へのデプロイデプロイスキル（利用可能な場合）
Apex を呼び出す FlowFlow スキル（利用可能な場合）
Apex を呼び出す LWCLWC スキル（利用可能な場合）

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

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

コメント

Markdown 対応