field-service-data-capture-form-designer-configure

データ入力フォームを設計する（文章または画像／PDFから）

このスキルは、ユーザーの入力（自然言語による説明、または既存フォームのPDF／画像）から中間JSON仕様を生成し、ユーザーの承認を得てから、fs-data-capture-form-deployerを呼び出してコンパイルとデプロイを行います。

このスキルが実行される条件

ユーザーがData Capture Flow／Field Service Mobileフォームを依頼した場合に実行されます。入力には次の2つのモードがあります。

• 文章モード — ユーザーが添付ファイルなしで、フォームを平文で説明します。例：
  • 「資産ID、状態評価、写真、備考を尋ねる資産点検用のデータ入力フォームを作成してください。」
  • 「部品のリピーター、出発地、到着地のドロップダウンを備えた在庫移動用のField Serviceフォームを作成してください。」
  • 「現場名、連絡先情報、メモ欄の3項目を収集するDataCaptureFlowを生成してください。」
• 画像／PDFモード — ユーザーが.pdf、.png、.jpg、.jpegファイルのパスを指定します。例：
  • 「/tmp/inspection.pdfをData Capture Flowに変換してください」
  • 「この画像からField Serviceフォームを作成してください：~/Downloads/site-visit.png」
  • 「この紙のフォームをDataCaptureFlowにしてください」（画像を添付）

入力からモードを判定します。**ユーザーが.pdf／.png／.jpg／.jpegのパスを指定した場合は画像／PDFモードを使用し、それ以外の場合は文章モードを使用します。**抽出後（手順2～6）は、どちらのモードでも同じです。

ワークフロー

1. ソースを読み取る（モードに応じて）

文章モード — 説明を注意深く読み、項目を捏造しないでください。 ユーザーが実際に言及した項目だけを抽出します。点検フォームに「通常含まれる」項目を推測して追加しないでください。ユーザーが「資産ID、状態評価、写真、備考を尋ねる」と言った場合、8項目ではなく4項目を出力します。

ユーザーの説明が曖昧すぎて、実用的なフォームを作成できない場合（「サービス予約に関する情報を収集するフォームを作成してください」など）は、抽出の前に、必要な項目、親レコードの有無、送信時の処理などについて、的を絞った質問を1つか2つ行います。推測しないでください。

次に、reference/extraction-from-prompt.mdの文章に基づく根拠のルールを適用します。

画像／PDFモード — ファイルを読み取ります。 ユーザーが指定したパスに対してReadツールを使用します。PDFと画像は標準でサポートされています。PDFが10ページを超える場合は、フォームが含まれるページをユーザーに尋ねます（大きなPDFでは、Readツールにpagesパラメーターが必要です）。

次に、reference/extraction-from-image.mdのコントロールに基づく根拠のルールを適用します。

2. 中間JSONを抽出する

モードに対応する抽出リファレンス（手順1）に記載されたすべてのルールを適用します。出力スキーマは、ビルドスキルの入力コントラクトで定義されています。

• field-types.md — フィールドタイプからコンポーネントへのマッピング、必須のFlowボイラープレート、選択肢／リピーターの構造、表示ルール。
• post-screen-automation.md — オプションのpostScreenブロックのスキーマ。

JSONを/tmp/data-capture-spec.jsonに書き込みます。

3. 望ましい結果を決定する

データ取得フォームは手段であり、目的ではありません。承認を求める前に、ユーザーがフォームを送信したときに Salesforce で何を行うべきかを決めてください。

• ユーザーが作成／更新する内容を明示している場合（「部品ごとに ProductTransfer を作成する」など）、またはソース／ファイル名から結果を強く推測できる場合（Inventory Transfer → ProductTransfer、Asset Inspection → WorkOrderLineItem）は、指定された（または最善の推測による）オブジェクト名とフィールド API 名を含む postScreen ブロックを出力してください。最善の推測に基づく場合は、ユーザーが名前を修正できるよう、確認ステップで各 valueRef／field をすべて列挙してください。
• 結果が曖昧で、ユーザーからヒントもない場合は、確認ステップで質問を提示してください（「このフォームの送信時に何を行いますか？」）。フォームのドメインに沿った具体的な選択肢を示してください。
• postScreen のない画面のみのフローも有効ですが、その旨を確認ステップで明示してください。

望ましい結果を引き出すためのルール全体については、該当モードの抽出リファレンスを参照してください。

4. ユーザーに確認する（必須のゲート）

デプロイ前に、作成予定の内容をユーザーに提示してください。AskUserQuestion を使って、ビルドへの引き継ぎをゲートしてください。

質問文またはその前後のテキストで、次の内容を明確に伝えてください。

1. 望ましい結果。 最後の画面の後にフローが行う処理を示してください。例：「フォームを送信すると、Parts リピーターの各行について ProductTransfer が作成されます」または「このフローはデータを取得するだけです。管理者が Flow Builder で自動化を設定します。」postScreen ブロックが生成された場合は、参照する Salesforce オブジェクト名と field API 名をすべて列挙してください。オブジェクト／フィールド API 名は、デプロイ後のエラーで最もよくある原因です。
2. formTitle と、提案する <FlowApiName>（パスカルケース、スペースなし）。
3. 画面数とフィールドの合計数（リピーターの子フィールドも数えてください）。
4. 生成された表示ルールと、それらの判定に使う選択肢の値。
5. 特に特殊なフィールドについて、すべてのフィールドタイプと、その根拠。 仕様内の各 Signature、UploadFile、UploadImage、Images、Matrix、Address、Lookup、FileView、Repeater について、フィールド名と根拠を示してください。文章モードでは文章の根拠（「ユーザーが『部品リピーター』と述べた」「ユーザーが署名欄について説明した」など）、画像モードでは視覚的な根拠（「damagePhoto → UploadImage。ソースにカメラアイコン付きボタンがあるため」など）を示してください。これらは実際に機能するコンポーネント（dcSignature、dcUpImage など）としてデプロイされます。そのため、ユーザーが単なるテキストフィールドを意図している場合（文章）や、フィールドのラベルしか根拠を示せない場合（画像）にこれらを出力することが、抽出時に最もよくある誤りです。一致するコントロールの用語／視覚的なコントロールがない場合は、ShortText／LongText／Numeric にダウングレードし、その旨を明示してください。
6. Lookup オブジェクトと FileView のファイル名。 各 Lookup について、選択した lookupObject（Salesforce オブジェクト API 名）と lookupSearchFields を列挙してください。各 FileView について、fileName を列挙してください。これらの名前はデプロイ後のエラーでよくある原因です。ユーザーが修正できるよう提示してください。
7. ラベル付き dcTextInput のプレースホルダーにフォールバックしたフィールド（Lookup に lookupObject がない場合と、FileView に fileName がない場合に限られます）。

ユーザーに明確な選択肢を提示してください。

• 承認してデプロイ — ステップ 5 に進みます。
• 先に仕様を編集 — /tmp/data-capture-spec.json を直接編集できるようにしてから、ステップ 4 から再実行します。
• キャンセル — デプロイせずに終了します。

明示的な承認なしにステップ 5 に進まないでください。

5. Build への引き渡し

承認されたら、承認済みの仕様を fs-data-capture-form-deployer に引き渡します。^[A-Z][A-Za-z0-9_]*$ に一致する <FlowApiName> を選択し（デフォルト: formTitle の PascalCase）、そのスキルのワークフローに従います。これは Codey ランタイムを通じて完全に REST 経由で実行され、sf CLI もスクリプトも .flow-meta.xml も不要です:

1. 組織の認証を確認 — fs-data-capture-form-deployer/SKILL.md §1（軽量な SELECT Id FROM Organization LIMIT 1 REST プローブ。ランタイムが接続済みの組織を解決します — このファミリーはエイリアスを管理しません）。
2. 承認済みの仕様から Flow Metadata JSON をインラインで構築 — deployer §3 + reference/flow-metadata-json.md。エージェントは Metadata オブジェクトを直接組み立てます。XML コンパイルのステップはありません。
3. デプロイ — { "FullName": "<FlowApiName>", "Metadata": { ... } } を含む単一の POST /services/data/vXX.0/tooling/sobjects/Flow を使用します — deployer §4。

デプロイ後は、fs-data-capture-form-deployer/SKILL.md §5 のレポートとエラー処理のステップに従います。

6. フォームを親レコードに紐付けるかどうかの確認

デプロイが成功すると、フローは存在しますが、任意の Service Appointment / Work Order の Forms タブからは見えません。特定の親に紐付けるかどうかをユーザーに確認します（正規の「保留中フォーム」パターン）。はいの場合、fs-data-capture-form-deployer/SKILL.md §6 の紐付けステップに従います — 単一の POST /services/data/vXX.0/sobjects/DynamicDataCapture（スクリプトなし）。SA コンテキストでのテストでは、SA 自体ではなく SA の親 Work Order に紐付けます — FSL Mobile は親 Work Order から Forms を読み取ります。

スコープ外

• すでにデプロイ済みのフローの修正 → fs-data-capture-form-editor。
• コンバーターが生成しないパターンの手作業による作成（視覚的な装飾 HTML、実際の dcSignature/dcUpImage、マスター詳細の子レコード、サポート用の CustomObjects） → fs-data-capture-reference ライブラリスキル。

このスキルに含まれるファイル

• reference/extraction-from-prompt.md — ユーザーの説明からフィールド型を選択するための散文エビデンスのルール、画面のグルーピング、表示ルール、結果の引き出し、検証チェックリスト。散文モードで使用します。
• reference/extraction-from-image.md — レンダリングされたウィジェットからフィールド型を選択するためのコントロールエビデンスのルール、リピーター抽出ルール、画面のグルーピング、表示ルール、結果の引き出し、検証チェックリスト。画像 / PDF モードで使用します。