canvas-apps-ui-gen

あなたは Power Apps Canvas App の開発とオーケストレーションに精通しています。このスキルが呼び出されたら、以下のプロセスに正確に従ってください。

---

フェーズ 1 — モードの判定

呼び出し時に、画像が利用可能かどうかを判断します。

画像が利用可能（$ARGUMENTS にファイルパスが含まれている、または画像が会話に貼り付けられている／ドラッグされている）：

• 画像を今すぐ読み込みます（フェーズ 2 に正確に従います）
• フェーズ 3 に直接進みます。モードについて質問しないでください
• モード（複製と改善）はフェーズ 3 の一部として判断します

画像が利用できない（$ARGUMENTS が空、またはパス以外のテキストのみを含み、画像も貼り付けられていない）：

• ユーザーに次の内容をそのまま尋ね、回答を待ちます。

「どのモードで作業しますか？

1. 複製 — モックアップ、ワイヤーフレーム、またはデザインのスクリーンショットをお持ちの場合です。レイアウト、色、比率を忠実に再現し、Power Apps YAML を作成します。

2. 改善 — モダン化、再設計、または仕上げを行いたい既存の Power Apps 画面のスクリーンショットをお持ちの場合です。

3. ゼロから作成 — 画像はありません。作りたいものを説明していただければ、その説明をもとに YAML を生成します。」

• モード 1 または 2 → 画像を求め（フェーズ 2）、フェーズ 3 に進みます
• モード 3 → フェーズ 2 をスキップし、テキストのみのモードでフェーズ 3 に直接進みます

---

フェーズ 2 — 画像の読み込み

（フェーズ 1 でモード 3 が選択された場合、このフェーズ全体をスキップします。）

画像の提供方法を判断します。

方法 A — $ARGUMENTS にファイルパスがある場合： $ARGUMENTS が空でなく、ファイルパスのように見える場合（/ または \ を含む、あるいは .png、.jpg、.jpeg、.webp で終わる場合）、Read ツールを使って読み込みます。$ARGUMENTS 全体をパスとして扱います。スペースで分割しないでください（C:\Users\My Documents\screen.png のように、パスにスペースが含まれる場合があります）。

ファイルを読み込めない場合は、ユーザーに次のように伝えます。「[path] のファイルを読み込めませんでした。パスが正しいこと、およびファイル形式が PNG、JPG、WEBP のいずれかであることを確認してください。または、画像をチャットに直接貼り付けてください。」その後、停止します。

方法 B — 会話内の画像： $ARGUMENTS が空（またはパス以外のテキストのみを含む）であれば、現在の会話に貼り付けられた、またはドラッグされた画像を探します。画像が見つからない場合は、次のように尋ねます。「画像をチャットに貼り付けてください（Canvas アプリのスクリーンショット、UI モックアップ、ワイヤーフレーム、または YAML に変換したいデザインなど）。または、引数としてファイルパスを指定してください：/canvas-apps-ui-gen C:\path\to\image.png」

ファイルパスと画像の両方が提供された場合： より明確な指定であるファイルパス引数を優先します。

---

フェーズ 3 — 分析と質問

このフェーズでは、構造の説明と生成前のすべての質問を1 回の応答で提示します。2 つのメッセージに分けないでください。ユーザーが一度にすべて回答できるよう、分析と質問をまとめて提示する必要があります。

ステップ A — 構造の説明

次の内容を含む説明を提示します。

1. レイアウトのセクション：それぞれ異なる UI 領域（例：「上部に KPI 指標カードが横一列に 4 枚並んでいる」「画面下部の 65% を占めるデータテーブル」）
2. 特定されたコンポーネントの種類：カード、テーブル／グリッド、フォームフィールド、ナビゲーションバー、ヘッダー、ボタン、ステータスバッジ、グラフ、テキストラベルなど
3. おおよその配色：背景が暗色か明色か、確認できるアクセントカラー
4. セクションのおおよその比率：画面の大部分を占めている要素

形式の例：

「次のように見えます。

• 左側にサイドバー（幅約 130px）があり、ロゴ、縦並びのナビゲーションギャラリー、下部のプロフィール行が配置されています
• ページタイトルとパンくずリストを含む上部バー（高さ約 64px）
• タブが 6 つ並んだ横並びのタブバー
• 商品名、カテゴリー、ブランド、バリエーション、アクションボタンの各フィールドを含む、中央配置のフォームカード（幅約 440px）

配色：明るい背景（温かみのあるグレー）、白いサイドバーとカード、アクティブ状態にはオレンジのアクセントカラー。」

（モード 3／テキストのみの場合は、視覚的な観察の代わりに、ユーザーが提示した説明についての理解を示します。）

ステップ B — 互換性チェック

reference/canvas-apps-limitations.md を読みます。構造の説明（またはモード 3 の場合はユーザーのテキストによる説明）を、すべての項目と照合します。一致した項目は Handle: タグごとに分類します。

Handle: auto — Canvas Apps の代替案を通知せずに適用します。置き換えた内容を内部リストに記録します（フェーズ 4 のステップ 4 で使用）。ここでは言及しないでください。

Handle: ask — このブロックを現在の応答に含めます（ユーザーはほかの質問とあわせて回答します）。

Canvas Apps の互換性 — 入力が必要です： これらの要素は Canvas Apps でネイティブに実装できません。 それぞれの代替案を選択してください：

1. [検出された要素] — [理由を 1 行で記載] (a) [代替案 A] (b) [代替案 B] (c) この要素を省略する

(ask に該当する項目ごとに繰り返します)

Handle: skip — このブロックを含め、そのまま続行します（ユーザーの判断は不要です）。

Canvas Apps の互換性 — 省略する要素： 以下の要素は Canvas Apps の YAML として生成できないため、出力から除外されます：

• [要素]：[簡単な理由]

制限事項が見つからない場合は、互換性に関するブロックをすべて省略します。

ステップ C — 生成前の質問

説明と互換性ブロックの直後に、同じ応答内で質問ブロックを出力します。

---

画像が提供された場合（モードは未確認）：

生成の準備ができました — 簡単な質問です：

1. このデザインをどのように扱いますか？ (a) 再現 — このデザインを忠実に PA YAML として再現します (b) 改善 — 現代的で洗練されたデザインに整えます（余白やタイポグラフィの統一、コントロールの刷新、適切なホバー／フォーカス状態の追加）

2. この YAML はどこに貼り付けますか？ (a) 既存の画面 — Screen ラッパーなしでコントロールを生成します (b) 新しい画面 — 画面名とすべての子要素を含む Screens: ブロックを生成します (c) 画面内の特定のセクション／コンポーネントのみ

3. クラシックとモダン（Fluent）のどちらのコントロールを使用しますか？

• クラシック — 基本スタイルは最小限で、完全にカスタマイズ可能です。色、境界線、フォント、インタラクション状態をすべて個別に調整できます
• モダン／Fluent — Microsoft Fluent 2 のデザインが組み込まれており、洗練された外観、スムーズなアニメーション、アクセシブルな既定値が備わっています

画像からカラーパレットを抽出し、表示されているフィールド名をそのまま使用します。レスポンシブデザインは既定で「いいえ」とします。モバイル／タブレットへの対応が必要な場合は、返信でお知らせください。

任意 — 画像からの変更点： 表示内容から変更したい点はありますか？（例：「下部にメモ用のテキストエリアを追加する」「ブランドフィールドを仕入先のドロップダウンに置き換える」「サイドバーを削除する」）。表示どおりに進める場合は空欄のままにしてください。

ユーザーからの 1 回の返信を待ってから、フェーズ 4 に進みます。

---

モード 3 の場合（画像なし — テキストのみ）：

生成の準備ができました — 簡単な質問です：

1. この YAML はどこに貼り付けますか？ (a) 既存の画面 — Screen ラッパーなし (b) 新しい画面 — Screens: ブロック全体 (c) セクション／コンポーネントのみ

2. クラシックとモダン（Fluent）のどちらのコントロールを使用しますか？

• クラシック — 完全にカスタマイズ可能で、各プロパティを個別に調整できます
• モダン／Fluent — Fluent 2 のデザインが組み込まれており、洗練された既定値が備わっています

3. 使用するカラーパレットを指定してください。

• 青のアクセントがあるダークテーマ（背景は RGBA(35,36,47,1)、アクセントは RGBA(0,142,210,1)）
• ライト／ホワイトテーマ
• 独自のパレットを説明してください（例：「ネイビーとゴールド」「コーポレートブルーとホワイト」）

4. 全体的なレイアウトパターンは何ですか？ （例：サイドバー＋メインコンテンツ、全幅の単一カラム、ウィザード／段階式フォーム、分割ペイン、カードを使ったダッシュボード）

5. この画面の主な目的は何ですか？ （例：データテーブル／リスト、データ入力フォーム、KPI ダッシュボード、レコード詳細ビュー、設定ページ）

ユーザーからの 1 回の返信を待ってから、フェーズ 4 に進みます。

---

フェーズ 4 — マルチエージェントによる YAML 生成

ステップ 0：パスを解決する

何かを始める前に、フェーズ 4 で使用する 2 つのルートパスを解決します。

A. スキルディレクトリ（SKILL_DIR） このスキルのディレクトリ（この SKILL.md ファイルがあるフォルダー）の絶対パスを特定します。 SKILL_DIR は、プラグインアセット（agents/、reference/、templates/）の読み取りにのみ使用してください。ここに出力ファイルを書き込まないでください。

B. 出力ディレクトリ（OUTPUT_DIR） 次の Bash コマンドを実行して、ユーザーの作業ディレクトリを取得します。

pwd

結果を USER_CWD として保存します。その後、次のように構成します。 OUTPUT_DIR = {USER_CWD}/canvas-apps-output

存在しない場合は作成します。

mkdir -p "{USER_CWD}/canvas-apps-output"

エッジケース： USER_CWD に .claude/plugins が含まれている場合は、ユーザーに警告します。

「注意：ターミナルが Claude プラグインディレクトリ内にあるようです。出力は {OUTPUT_DIR} に保存されます。意図した場所が異なる場合は、先にプロジェクトフォルダーへ移動してください。」

そのまま続行し、中断しないでください。

プラグインアセットの読み取り操作にはすべて SKILL_DIR を使用します。フェーズ 4 で生成したファイルの書き込み、読み戻し、削除操作にはすべて OUTPUT_DIR を使用します。

ステップ 1：スケルトンと設計仕様書を生成する

フェーズ 3 の分析とユーザーの回答に基づき、2 つの成果物を作成し、一時ファイルに書き込みます。

書き込む前に、ユーザーの回答からモードを解決します。

• ユーザーが（a）複製と回答した場合 → 複製モードで進めます
• ユーザーが（b）改善と回答した場合 → 改善モードで進めます
• モード 3 の呼び出し → テキストのみのモードで進めます

ユーザーが変更（任意の変更項目）を指定した場合： 書き込む前に、スケルトンと設計仕様書の両方に反映します。設計仕様書に MODIFICATIONS セクションを追加し、要望された変更をそれぞれ記載します。未加工のモックアップではなく、変更を反映したスケルトンを作成します。

成果物 1：構造スケルトン → Write ツールを直接使用して {OUTPUT_DIR}/temp-skeleton.md に書き込む（Python や Bash は使用しないでください）

コントロール名、種類、階層、概要レベルのレイアウト方向を示す、簡潔なインデント付きテキストツリーです。次の形式を厳守してください。

Screen: [ScreenName]
Paste target: [a / b / c]

  screenRoot [GroupContainer, AutoLayout, fills screen]
  ├── sidebarContainer [GroupContainer, Vertical, fixed-width]
  │   ├── logoArea [GroupContainer, AutoLayout]
  │   │   ├── logoIcon [Image, icon]
  │   │   └── logoText [Label]
  │   ├── navGallery [Gallery, Vertical, items-cols: NavLabel|NavIcon|NavItemID, active-var: CurrentNavID, active-col: NavItemID]
  │   │   └── navItemRow [GroupContainer, ManualLayout]
  │   │       ├── navItemIcon [Image, icon, gallery-child]
  │   │       ├── navItemLabel [Label, gallery-child]
  │   │       └── navItemOverlay [Classic/Button, transparent overlay]
  │   └── profileRow [GroupContainer, AutoLayout]
  └── mainContent [GroupContainer, Vertical, fills remaining]
      ├── topBar [GroupContainer, Vertical]
      │   ├── pageTitle [Label]
      │   └── breadcrumb [Label]
      └── scrollableBody [GroupContainer, Vertical, scrollable]
          └── formCard [GroupContainer, Vertical, centered, card]
              ├── inputTitle [Classic/TextInput]
              └── actionRow [GroupContainer, AutoLayout]
                  ├── btnCancel [Classic/Button]
                  └── btnSave [Classic/Button]

すべてのコントロールを含めます。特殊な役割は角括弧内に記載します：transparent overlay、icon、gallery-child、scrollable、centered、card。

ギャラリーのデータ契約（すべての Gallery コントロールで必須）： 役割タグに加えて、すべての Gallery 行に、各専門エージェントが連携できるよう、次の 3 つの追加注釈を含めます。

• items-cols: A|B|C — controls-agent が Table() で使用する正確な列名です。ギャラリーの意味上の用途から名前を導きます。
  • ナビゲーション／サイドバーのギャラリー → NavLabel|NavIcon|NavItemID
  • タブギャラリー → TabLabel|TabID
  • データテーブルの行ギャラリー → デザイン内の表示フィールドに一致する列名（例：OrderName|Status|Amount|OrderID）
  • シンプルなリストギャラリー → ItemLabel|ItemID
• active-var: CurrentX — 選択された項目を追跡するグローバル変数名です。必ず Current 接頭辞を使用し（var は使用しないでください）、その後に意味を表す名詞を続けます：CurrentNavID、CurrentTabID、CurrentOrderID。この変数は OnVisible で初期化され、オーバーレイボタンの OnSelect で設定されます。
• active-col: X — アクティブ／選択状態の判定に使用する、items-cols 内の列です。active-var と比較する列であり、必ず ID／キー列にします。

例：navGallery [Gallery, Vertical, items-cols: NavLabel|NavIcon|NavItemID, active-var: CurrentNavID, active-col: NavItemID]

Artifact 2: デザイン仕様 → Write ツールを直接使って {OUTPUT_DIR}/temp-design-spec.md に書き込みます（Python や Bash は絶対に使用しないでください）

今すぐ reference/design-spec-formats.md を読み込みます。解決したモードに対応するセクションを使用します。

• レプリケートモード → ## Replicate Mode セクション
• 改善モード → ## Improvement Mode セクション
• テキストのみモード → ## Text-Only Mode セクション

改善モードとテキストのみモードでは、ほかのセクションを埋める前に、まず DESIGN TOKENS ブロックを作成します。

以下のルールに従って各フィールドを設定します。すべての専門エージェントは、このブロックをそれぞれの担当領域における最優先の基準として扱います。

• パレット：RGBA 値をちょうど 7 つ設定します。ユーザーが説明した目的や画面のコンテキストから導きます（例：「HR ポータル」→クールなグレー＋青、「フィールドサービスアプリ」→アースカラー＋オレンジ、「分析ダッシュボード」→ダーク＋ティール）。Background と Surface は、明度を少なくとも 4 ポイント変えます。アクセントが 1 色だけでよい場合は、Accent-Secondary を空欄にします。出力内のすべての塗りつぶしには、この 7 つの値のいずれか、またはその透明版を使用します。独自に色を追加してはいけません。

• タイポグラフィ：画面全体で使用するフォントファミリーを 1 つ選びます。フォントを混在させてはいけません。サイズ：Heading は Body より PA サイズ単位で少なくとも 2 大きくし、Body は Caption より少なくとも 1 大きくします。デフォルト（Classic コントロールで、ほかに指定がない場合）：Heading=14、Body=11、Caption=9。Modern コントロールの場合は、reference/sizing-reference.md の Classic→Modern サイズ変換を適用します。

• 密度：レイアウトの種類から判断します。

  • データテーブル／リスト → コンパクト：LayoutGap=8、PaddingH=12、PaddingV=8
  • フォーム／レコード詳細ビュー → バランス型：LayoutGap=12、PaddingH=16、PaddingV=12
  • ダッシュボード／ランディングページ → ゆったり：LayoutGap=16、PaddingH=20、PaddingV=16

• 角丸：コンテナーに使用する値を 1 つ選びます（0=角張った形状、4=わずかに丸い、6=標準、8=丸い、12=柔らかい）。インタラクティブコントロールには同じ値か半分の値を使用します。それより大きい値にしてはいけません。デフォルト：Container=6、Interactive=4。

• 状態色：すべて Accent-Primary から導きます。

  • HoverFill：RGBA(accent_r, accent_g, accent_b, 0.08)
  • PressedFill：RGBA(accent_r, accent_g, accent_b, 0.15)
  • FocusedBorder：不透明度 100% の Accent-Primary
  • DisabledFill：背景に近い色（コントラストは非常に低くします）
  • DisabledColor：不透明度 0.38 の Text-Secondary

スクリーンショット／ユーザーの回答から抽出した値を使って、選択した形式を埋めます。結果を {OUTPUT_DIR}/temp-design-spec.md に書き込みます。

両方のファイルを書き込んだら、ただちにステップ 2 に進みます。ここで reference/controls-index.md を再度読み込んではいけません（controls-agent が直接読み込みます）。

---

Step 2: 専門エージェントを並行して起動する

このスキルの agents/ サブディレクトリにある 3 つのエージェント指示ファイルを読み込みます。

• agents/layout-sizing-agent.md
• agents/controls-agent.md
• agents/styling-agent.md

次に、Agent ツールを使って、3 つのエージェントを1 つのメッセージで同時に起動します。各エージェントには、指示ファイルの内容に以下の詳細を加えて構成したプロンプトを渡します。

各エージェントに渡す内容：

• 指示ファイルの全文（タスクの説明として）
• {OUTPUT_DIR}/temp-skeleton.md の絶対パス
• {OUTPUT_DIR}/temp-design-spec.md の絶対パス
• SKILL_DIR（reference/ 内の参考資料を読み込むためのスキルディレクトリの絶対パス）
• ユーザーのフェーズ 3 の回答にあるコントロールスタイルの希望（classic / modern）。適切なバリアントを選べるよう、この内容を controls-agent に明示的に渡します。
• 各エージェントの出力ファイルの絶対パス：
  • Layout+Sizing → {OUTPUT_DIR}/temp-layout-annotations.yaml
  • Controls → {OUTPUT_DIR}/temp-controls-annotations.yaml
  • Styling → {OUTPUT_DIR}/temp-styling-annotations.yaml

ステップ 3 に進む前に、3 つのエージェントがすべて完了するまで待ちます。

---

ステップ 3：組み立て + QA

agents/assembly-agent.md を読みます。Agent ツールを使って Assembly エージェントを起動し、次の内容を含むプロンプトを渡します。

• agents/assembly-agent.md の全文
• 次の絶対パス：{OUTPUT_DIR}/temp-skeleton.md、{OUTPUT_DIR}/temp-layout-annotations.yaml、{OUTPUT_DIR}/temp-controls-annotations.yaml、{OUTPUT_DIR}/temp-styling-annotations.yaml
• {OUTPUT_DIR}/temp-design-spec.md の絶対パス（QA の忠実性チェックに必要です）
• SKILL_DIR（QA 中に reference/controls-reference.md を読むためのスキルディレクトリの絶対パス）
• 貼り付け先（a、b、または c）と画面名
• 出力ファイル名：まず {OUTPUT_DIR}/[ScreenName]-*-generated.yaml に対して Glob を実行して、一意のファイル名を決定します。{OUTPUT_DIR}/[ScreenName]-1-generated.yaml が存在する場合は、-2-、その次も同様に番号を増やします。
• データバインディングの指示（貼り付け先が b の場合はインラインで、a と c の場合は別のブロックで指定します）
• レスポンシブデザインのフラグ（ユーザーが Phase 3 の返信でレスポンシブに言及した場合）と、ScreenName.Size 数式に使用する画面名

Assembly エージェントは、出力ファイルを書き込む前に、QA の問題をすべて自己検証して修正します。処理が完了し、出力ファイルが書き込まれたことを確認するまで待ちます。

---

ステップ 4：クリーンアップと出力

Bash ツールを使って一時ファイルを削除します（Python は使用しないでください）。

• {OUTPUT_DIR}/temp-skeleton.md
• {OUTPUT_DIR}/temp-design-spec.md
• {OUTPUT_DIR}/temp-layout-annotations.yaml
• {OUTPUT_DIR}/temp-controls-annotations.yaml
• {OUTPUT_DIR}/temp-styling-annotations.yaml

次に、ユーザーに以下を出力します。

1. 目立つファイルリンク（最初に配置）：

YAML の準備ができました： ファイルは {OUTPUT_DIR}/[ScreenName-N-generated.yaml] に保存されています。エディターで開き、Ctrl+A を押してから Ctrl+C を押してすべてをコピーし、Power Apps Studio に貼り付けてください。

2. 貼り付け先に応じた手順：

• (a) または (c)：「PA Studio でツリービューを開き、対象の画面またはコンテナーを右クリックして、Paste code を選択してください。」
• (b) 新しい画面：「PA Studio で画面リストのパネルを右クリックし、Paste code を選択してください。選択できない場合は、空白の画面（Insert → New Screen → Blank）を作成し、ツリービューでその画面を右クリックして、Paste code を選択し、Children: の下の内容だけを貼り付けてください。その後、OnVisible の数式を画面の OnVisible プロパティにコピーしてください。」

3. キャンバスサイズに関する注意： 「これはタブレットキャンバス（幅 1366px）向けのサイズです。アプリがスマートフォン向けレイアウトの場合は、LayoutMinWidth の値を小さくし、コンテナーの幅を =Parent.Width に設定してください。」 （レスポンシブ対応が求められている場合：「この YAML はレスポンシブ対応のために [ScreenName].Size を使用します。アプリが Tablet キャンバスの種類であることを確認し、Settings → Display で Scale to fit と Lock Orientation をオフにしてください。」）

4. 貼り付け先が (a)/(c) の場合 — データバインドブロック： Assembly エージェントの完了メッセージに ONVISIBLE_BLOCK フィールドが含まれている場合、その数式を抽出してここに表示します。出力ファイルから読み取らないでください。ファイルには YAML のみが含まれています。次の形式で表示します。

画面の OnVisible プロパティにも、次の内容を貼り付けてください：

[ONVISIBLE_BLOCK の数式]

5. 改善モードの場合 — 変更内容の概要： 行った主な改善点を簡潔な箇条書きで示します（カラーパレットの適用、コントロールのアップグレード、間隔の統一、状態の追加など）。

6. YAML のインライン表示（サイズ制限あり）： 出力ファイルの行数を数えます。400 行以下の場合は、YAML 全体を yaml のコードブロックで表示します。400 行を超える場合は、「YAML は [N] 行あるため、インライン表示には大きすぎます。上のファイルを開き、Ctrl+A → Ctrl+C を押してコピーしてください。」と出力します。

7. QA 警告（ある場合）： Assembly エージェントから PA2105 のバージョン警告、またはその他のブロッキングではない懸念が報告されている場合は、ここに列挙します。

QA 警告（ブロッキングではありません）：

• [警告の内容]

Assembly エージェントから警告が報告されていない場合、このブロックは省略します。

8. 自動置換（ある場合）： フェーズ 3 で Handle: auto の制限に遭遇し、通知なしで置き換えた場合は、ここに列挙します。

自動的に適用された置換：

• [元の要素] → [使用した Canvas Apps の代替要素]

auto による置換がなかった場合、このブロックは省略します。

追加の修正依頼について： ユーザーから変更を依頼された場合は、Edit ツールを使って同じ出力ファイルに直接変更を適用します。複製に関する追加依頼では、依頼された内容だけを変更し、それ以外の部分には手を加えないでください。

---

テンプレートの拡充

templates/ に対応するテンプレートがないコンポーネントタイプの YAML を生成した後、次のように提案します。 「参照テンプレートなしで [コンポーネントタイプ] を生成しました。今後の生成で参照できるよう、新しいテンプレートとして保存しますか？」

ユーザーが希望した場合は、以下の保護対象ファイルの変更に記載されたステージング手順に従います。

---

保護対象ファイルの変更

templates/ にあるテンプレートは変更不可の参照用ファイルです。このフォルダーにテンプレートとして登録された後は、編集してはいけません。YAML の生成中に読み取る場合に限り使用できます。

新しいテンプレートの追加

1. スキルディレクトリ内の output/staging-[name].yaml にプレビューを書き込みます
2. プレビューを Power Apps Studio に貼り付け、正しくレンダリングされることを確認するようユーザーに伝えます
3. ユーザーがプレビューの動作を確認するまで待ちます
4. 昇格します。検証済みファイルをスキルディレクトリ内の templates/[name].yaml に移動し、output/ からステージングファイルを削除します

既存のテンプレートは編集しないでください

AI が既存のテンプレートに似ているものの異なるものを必要とする場合は、複製して新しいステージングファイルを作成してください。元のファイルには手を加えないでください。

例外 — バージョンの自己修復

PA2105 のバージョン更新は、テンプレートファイルを機械的にその場で更新できる唯一のケースです。変更されるのはコントロール型文字列の @version サフィックスのみであり、レンダリングに影響することはありません。

重大なルール（常に適用）

1. Skeleton を生成する前に、reference/pa-yaml-rules.md を読んでください。正確な形式のルール、サイズ設定の方針、有効なコントロールの種類が記載されています。
2. 有効なプロパティ名と列挙値については、reference/controls-reference.md を読んでください。
3. このスキル自体に context: fork を使用しないでください。貼り付けられた画像にアクセスできるよう、会話形式を維持する必要があります。ただし、Phase 4 内では Agent ツールを使用して専門のワーカーを起動します。ワーカーには事前分析済みの Skeleton とデザイン仕様をテキストで渡すため、元の画像にアクセスする必要はありません。
4. ユーザーが明示的に確認しない限り、ファイルを書き込まないでください（新しいテンプレートの保存など）。Phase 4 の一時ファイルは内部作業用のため、使用して問題ありません。
5. 生成する YAML に、実際のデータソース名や接続文字列を含めないでください。
6. バージョンの自己修復：ユーザーからいずれかのコントロールについて PA2105 警告が報告された場合は、そのコントロールの @version を、記載されているすべての箇所ですぐに更新してください。対象は、reference/pa-yaml-rules.md の VALID CONTROL TYPES テーブル、reference/pa-yaml-rules.md のすべてのコード例、reference/controls-reference.md のセクション見出し、および templates/ 内のすべての .yaml ファイルです。PA が報告したバージョン番号を最新のものとして使用してください。同じコントロールについて同じ PA2105 警告が再度発生してはなりません。
7. Control: Screen は使用しないでください。これは PA2101 の原因になります。新しい画面では必ず、Phase 4 Step 3 および reference/controls-reference.md に記載されているトップレベル形式の Screens: を使用してください。
8. コントロールの忠実性を守り、劣ったコントロールで代用しないでください。 UI 要素には、必ず意味的に正しいコントロールを使用してください。適切なコントロールを特定するには、reference/controls-index.md を使用してください。バージョンが不確かだからといって、別のコントロールで代用してはいけません。
9. [email protected]、[email protected]、または [email protected] を使用する前に、Default（TextInput/Radio）または SearchFields（ComboBox）が必要かどうかを確認してください。必要な場合は、代わりに Classic バリアントを使用してください。これらのプロパティを前世代のコントロールに追加しないでください。PA2108 の原因になります。
10. Classic と Modern のコントロールのプロパティを混在させないでください。 使用するコントロールの種類と完全に一致する項目を reference/controls-reference.md で確認してください。
11. 生成するテキスト値に絵文字や em ダッシュを含めないでください。ユーザーの元画像に含まれている場合、またはユーザーが明示的に求めた場合を除き、コントロールの Text、HintText、Placeholder、TrueText、FalseText、Tooltip、その他の文字列プロパティには、絵文字や em ダッシュ（—）を使用しないでください。
12. 必ずカスタム SVG アイコンを使用し、Classic/[email protected] は使用しないでください。 アイコンにはすべて、インライン SVG を含む [email protected] を使用してください。生成する YAML に Classic/Icon コントロールを含めてはいけません。
13. 出力トークン数は、必ず応答あたり 32 000 トークン以内にしてください。 まず YAML をファイルに書き込み（Phase 4 Step 4）、その後、コードブロックのサイズガード（400 行のしきい値）を適用してください。
14. HtmlText は表示専用です。操作を実装しないでください。 ハイパーリンクやクリック可能なリンクには、OnSelect: =Launch("<url>") を指定した Classic/[email protected]（または Modern ボタン）を使用してください。リンクに見えるよう、塗りつぶしや枠線のないテキストのみのボタンとしてスタイルを設定してください。操作の手段として HtmlText 内に <a> タグを使用してはいけません。
15. GroupContainer に Variant: GridLayout を使用しないでください。 [email protected] では、Variant: AutoLayout または Variant: ManualLayout のみを使用してください。方向は LayoutDirection で指定してください。