edit-app

プラグインの確認：node "${PLUGIN_ROOT}/scripts/check-version.js" を実行します。メッセージが出力された場合は、先にユーザーに表示してから続行してください。

共通の指示：shared-instructions.md — 最初にお読みください。

アプリの編集（/edit-app）

既存のモバイルアプリを生成後に編集します。native-app-plan.md は引き続き信頼できる唯一の情報源ですが、通常の結果はプランのみの差分ではなく、生成済みアプリを直接変更したものです。ユーザーがプランの差分を承認したら、Dataverse／ネイティブ／デザイン／画面の変更を続行し、検証を実行して、memory-bank.md を更新し、UI に変更があった場合は静的プレビューを再生成してください。

--plan-only は、ユーザーがアプリのコードを変更せず、計画ドキュメントの更新のみを明示的に求めた場合に限り使用してください。通常、Copilot Chat Agent モードでの追加プロンプトでは、アプリの変更を最初から最後まで適用してください。

使用する場合

• 「検索画面をモバイルで使いやすくしてください」
• 「リスト画面に読み込み中、空、エラーの状態を追加してください」
• 「選択したレコードの詳細画面を追加してください」
• 「会社のブランディングにより合うようにデザインを更新してください」
• 「Dataverse に新しいレコードを作成するフォームを追加してください」
• 「バーコードスキャンを追加し、スキャンした値を使ってレコードを検索してください」
• 「更新したアプリの静的プレビューを新しく生成してください」
• 「データモデルに case テーブルを追加してください」
• 「Drawer ナビゲーションを Tabs に置き換えてください」
• 「ネイティブ機能に expo-camera を追加してください」
• 「承認に署名の取得を追加し、Dataverse に保存してください」
• 「証拠を示す PDF を生成し、検査レコードに保持してください」
• 「HTTPS のレポート URL に対する PDF の表示アクションを追加してください」
• 「画面の順序を変更してください。プロフィールをタブから外し、ホームヘッダーから開くモーダルに移動してください」
• 「このアプリで Application Insights を有効にしてください」
• 「このアプリが使用する Application Insights リソースを変更してください」
• 「このアプリで Application Insights を無効にしてください」

使用しない場合

• 新規プロジェクト → /create-mobile-app
• 実装のみを明示的に求められた場合 → app-edit-routing.md にある該当するリーフスキルを使用してください。短い依頼や画面の詳細がないことを根拠に、実装のみの依頼だと推測しないでください。
• プランファイルが見つからない場合 → 中止し、ファイルを復元するか、範囲を限定した実装のみの作業を行うか確認してください。既存アプリに対して、決して再スキャフォールドしないでください。

ワークフロー

このスキルは、ネイティブ、コネクター、データモデル、デザインのエントリーポイントから転送された機能に関する直接の依頼を担当します。転送された元の依頼、引数、回答を再利用し、ユーザーに繰り返し尋ねないでください。

これらのエントリーポイントは、この完全なワークフローを呼び出す前に許可を求めます。現在の依頼には entry_choice: full-integration を再利用し、モードに関する質問を繰り返さないでください。/edit-app を直接呼び出した場合も、エントリーチョイスのメニューは不要です。いずれの場合も変更が許可されるわけではありません。以下の影響確認とプランの承認ゲートは維持してください。承認された子スキルの呼び出しでは、エントリー時の質問を省略してここに戻ってください。再帰的なメニューは作成しないでください。

子スキルを呼び出すたびに、app-edit-routing.md のコンテキストを明示的に渡してください。 MOBILE_APP_ORCHESTRATING=1、orchestrator: edit-app、working_dir、phase、approved_scope を渡します。計画段階では読み取り専用の提案を使用し、ステップ 5 の実装ではステップ 3 で承認され、ステップ 4 で保存された範囲を使用します。このマーカーは承認を意味するものではなく、保存してはならず、以前のシェルエクスポートを通じて依存してはなりません。

0. アプリの場所を特定し、健全性／差分を確認 → 0.5 該当する場合は Application Insights の迅速な対応 → 1. 意図を把握し、既存アプリを調査 → 1.5 影響をプレビュー → 2. 影響を受けるセクションを再計画 → 3. 意図、プラン、変更プレビューの承認を取得 → 4. プランの差分を書き込む → 5. 追加／更新を適用 → 6. 影響を受ける画面を再構築 → 6.5 承認された廃止済みソースの登録を解除 → 7. 検証と品質の総点検 → 8. プレビュー、メモリバンクの更新、任意のデバッグへの引き継ぎ

---

編集品質ゲートポリシー — 品質を妥協しない

これは品質基準を緩和した編集ワークフローではなく、対象を絞った編集ワークフローです。編集の規模に応じて /create-mobile-app のゲートを再利用してください。

編集の種類ごとに必須となるゲート：

編集対象	必須ゲート
ソースファイル全般	既存アプリの健全性ゲート、最後に npx --no-install tsc --noEmit
Dataverse／スキーマ／コネクター	環境差分ゲート、データソース／スキーマゲート、Generated Services スナップショットの更新、最後に tsc
ナビゲーション／ルート	ナビゲーション／レイアウトゲート、ルートコントラクトのチェック、最後に tsc
新しい画面	共通スキャフォールドゲート、スケルトンゲート、画面ビルダーのウェーブゲート、スタイル品質の一括確認、ルートチェック、最後に tsc
既存画面の TSX	画面編集ゲート、スタイル品質の一括確認、ナビゲーションを変更した場合はルートチェック、最後に tsc
ネイティブ機能	ネイティブ許可リストゲート、ラッパーの存在確認ゲート、最後に tsc
純粋な JavaScript の依存関係	承認済みの正確なバージョンを記載した依存関係テーブル、パッケージ内容ゲート、パッケージ検証、最後に tsc
デザイン／コンポーネント／密度	デザインシステムゲート、影響を受ける画面のスタイル一括確認、最後に tsc、プレビュー
Application Insights の設定のみ	有効な app.json、プロバイダーの appConfig 配線、app/_layout.tsx を変更した場合のみ最後に tsc

ゲートに失敗した場合： 完全な出力を一度取得し、根本原因ごとに分類して、まとめて修正し、同じゲートを一度だけ再実行してください。細かな編集のたびに tsc を実行して、1 行ずつ修正してはいけません。ゲートがクリーンになるか、memory-bank.md に BLOCKED: ／ DONE_WITH_CONCERNS: エントリーを記録した場合にのみ続行してください。

厳守事項：

• アプリのルート／環境を特定できない場合は、データソースを変更しないでください。
• 生成済みサービス、ルートレイアウト、共通コード、スケルトンに問題がある状態で、画面ビルダーを起動しないでください。
• /add-native による生成が完了する前に、画面でネイティブラッパーをインポートしないでください。
• TypeScript を通すためだけに、未対応のネイティブ機能をモックや TODO で隠さないでください。
• 変更した画面が TypeScript、ルートコントラクト、または必須のバリデーターに失敗する場合、編集を成功と判定しないでください。

Step 0 — アプリの場所の特定 + ヘルス／ドリフトの確認

テレメトリのチェックポイント：assess_app_health_and_drift

プロジェクトを読み取ったりコマンドを実行したりする前に、 app-working-directory.mdを実行します。 絶対パスのworking_dirを一度だけ解決し、フェイルクローズのガードを使ってすべてのシェル呼び出しをそこに固定し、ファイルツールには絶対パスを使用します。同じルートをすべてのデータ子プロセスに渡します。以前のcdや引き継がれた起動時のcwdは、引き継ぎとはみなしません。

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
test -f native-app-plan.md && echo "OK: plan found" || echo "ERROR: no plan"
test -f package.json && echo "OK: package found" || echo "ERROR: no package"
test -d app && echo "OK: app routes found" || echo "ERROR: no app routes"
test -f memory-bank.md && echo "OK: memory bank found" || echo "WARN: no memory bank"
git status --short

native-app-plan.mdが見つからない場合 → STOP。既存のプランを復元するか、依頼の範囲を実装作業のみに明示的に限定するよう求めます。1つの機能リクエストからアプリ全体のプランを再構築したり、このアプリに対して/create-mobile-appを実行したりしないでください。

存在する場合は、以下を読み取ります。

• memory-bank.md — プロジェクトの事実、対象環境、ビジュアルコンパニオンのフラグ、以前のブロック
• .datamodel-manifest.json — 既存のDataverseテーブル／列
• brand/design-system.mdおよびbrand/tokens.ts — デザイン上の制約とトークンの利用可否
• src/generated/services/*.tsおよびsrc/generated/models/*.ts — 生成されたデータサーフェス

変更を加える前に、既存アプリの以下のヘルスチェックを実行します。

これは検査のみを行うゲートです。必要なスキャフォールド／プロバイダー／サービスの修復は、提案する変更範囲に含めます。Step 3で承認される前に適用しないでください。 --plan-onlyは、これらの修復やその他のアプリ／クラウドの変更を許可するものではありません。

チェック	不健全な場合の対応
memory-bank.mdが存在し、想定される見出しがある	見つからない、または破損している場合は、再開時の安全性を低下させて続行するか確認します。作成／更新は承認後にのみ行います
power.config.json、.resolved-environment.json、memory bankの環境設定が一致している	データソース／スキーマを編集する場合は、ユーザーが意図する環境を確認するまでSTOP
src/components/index.tsx、src/hooks/index.ts、src/utils/index.ts、src/tokens/index.tsが存在する	不足している共通スキャフォールドは、画面ビルダーの作業前にshared/samples/src/から復元します。既存ファイルは上書きしません
app/_layout.tsxが引き続きプロバイダーとSafeAreaProviderを正しくラップしている	画面の作業前に慎重にパッチを適用します。ルート／セーフエリアのバリデーターはこれに依存します
編集で生成済みサービスを利用する場合、src/generated/がコンパイルできる	画面の作業前にスキーマ／サービスを再生成するか、処理をブロックします
検証に必要なnode_modulesとパッケージスクリプトが存在する	見つからない場合は、ユーザーにインストールの実行を依頼します。検証に合格したかのように装わないでください

ワークツリーに未コミットの変更があり、編集対象となる可能性の高いファイルと重複する場合は、該当ファイルを示し、続行前に確認します。自動で元に戻したり、stashしたりしないでください。

アプリがすでにnpx --no-install tsc --noEmitに失敗する場合は、エラーを一度だけ記録します。失敗が今回の編集で触れるファイルに関するものか、今回の編集で修復できる生成サービスのドリフトである場合に限り、続行します。それ以外の場合は、既存の失敗を提示し、続行するか確認します。編集によって画面または生成サービスを追加する場合は、続行前に前提条件のゲートをクリアしてください。

ステップ 0.5 — Application Insights 設定のクイックパス

--plan-only が指定されている場合は、設定スキルを呼び出したり、Application Insights を変更したりしないでください。設定のみのリクエストの場合は、プランセクションがないことを伝えて変更せずに終了します。複合リクエストの場合は、リクエストされたプランの提案のみを続行します。

Application Insights の有効化、リソースの変更、無効化のみを求めるリクエストでは、このクイックパスを使用してください。Application Insights はホスト／ランタイムの設定であり、コネクターやプランセクションではないため、プランナー、データモデル、ネイティブ、デザイン、画面、プレビューの各フローは実行しないでください。

リクエストにアプリ画面のカスタムイベントの追加や変更も含まれている場合は、まずここで Application Insights を設定し、その後、ソース変更の通常の編集ワークフローに進んでください。

Application Insights のロジックはすべて、専用の /setup-app-insights スキルにあります。Azure の検出、接続文字列の処理、プロバイダーの配線、プライバシールールを重複して実装せず、このスキルに委任してください。

Invoke skill: /setup-app-insights

Environment:
  MOBILE_APP_ORCHESTRATING=1
  orchestrator: edit-app
  working_dir: <working_dir>
  phase: configuration
  approved_scope: <requested configuration action; setup-app-insights owns approval>

Arguments:
  --working-dir <working_dir>
  --action <enable|change-resource|disable>   # omit to let the skill infer + ask

リクエストから --action（enable／change-resource／disable）を判断してください。リクエストが「Application Insights を更新」とだけ述べている場合は省略し、スキルから質問させてください。このスキルが、変更のプレビュー、承認、app.json と PowerAppsProvider の appConfig の配線、memory-bank.md の更新、および選択時のテレメトリ送信を担当します。

ステータスプロトコル（AGENTS.md ルール #12）に従って戻り値を処理してください。

• DONE → 完了したアクションを出力します。その後、戻り値に instrumentation_offer: available（有効化／リソース変更が成功）が含まれている場合は、既定値を No として、ユーザーに質問を 1 つします：「Application Insights は有効です。アプリの主要な操作（作成／更新／削除）にカスタムテレメトリを追加しますか？」
  • Yes → 次の要件を伝え、通常の編集ワークフロー（ステップ 1 以降）に進みます。「アプリの主要エンティティについて、作成、更新、削除が成功した各境界でカスタムイベントを追加し、承認済みのスカラー値プロパティのみを使って getCustomEventsLogger から名前付きイベントを送信してください（操作結果、ペイロード、フォーム値、自由記述、レコード名、個人識別子、トークン、正確な座標、ネストされたオブジェクト、完全な URL は含めないでください）。所要時間には trackScenario() を使用してください。」 画面プランナーと画面ビルダーは、既存のプライバシー許可リストに従ってソースを編集します。
  • No（または instrumentation_offer: none）→ 終了し、ステップ 1 に進まないでください。
• DONE_WITH_CONCERNS → 懸念事項を提示して終了します。
• NEEDS_CONTEXT → 質問を提示し、回答を得てから再度呼び出します。
• BLOCKED → エラー（通常は app.json が使用できないこと）を提示して終了します。

ステップ 1 — 意図を把握し、既存のアプリを確認する

可能な場合は $ARGUMENTS から意図を推測しますが、具体的な編集要件が定まるまではファイルを変更しないでください。これは、既存のアプリに対する 1 件の変更についての /create-mobile-app の要件確認フェーズです。

抽象的な選択肢ではなく、実際の選択肢を使った質問ができるよう、まずアプリを確認します。

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
find app -name '*.tsx' -not -name '_layout.tsx' -not -name '+not-found.tsx' | sort
ls -1 src/generated/services/*.ts 2>/dev/null | sed 's|src/generated/services/||;s|\.ts$||'
ls -1 src/generated/models/*.ts 2>/dev/null | sed 's|src/generated/models/||;s|\.ts$||'
find src/native -maxdepth 1 -type f -name '*.ts*' 2>/dev/null | sort

また、関連する native-app-plan.md のセクション（## Data Model、## Native Capabilities、## Design、## Screens、および存在する場合は ## Generated Services）と、候補となる画面の既存の TSX を読みます。brand/design-system.md が存在する場合は、編集内容でプロダクトの文法、密度、コンポーネントのルール、禁止事項を維持できるよう、デザインや画面について質問する前に読みます。

アプリから推測できない情報だけを尋ねてください。候補となる画面／テーブル／サービスが 1 つだけの場合は、質問せず、変更プレビューで推測した選択肢を示します。候補が複数ある場合は、実際の名前を使った簡潔な選択式の質問をします。

ステップ 2 の前に編集要件を作成します。

## Edit Brief
- Intent: <what user wants to accomplish>
- Target screens/routes: <existing or new>
- Data surface: <generated service/table/connector, or none>
- Native capability: <wrapper/control needed, or none>
- Design scope: <tokens/component grammar/screen-specific, or none>
- Plan sections to update: <Data Model / Native Capabilities / Screens / Design / Connectors>
- App files likely touched: <routes/layouts/src/native/src/generated/brand/etc.>
- Verification gates: <schema, tsc, routes, validators, preview>

確認後も編集要件が不完全な場合は、続行する前にシナリオに即した質問をしてください。

確認後も依頼された変更内容が不明な場合に限り、AskUserQuestion を使って質問します。

「このアプリの編集内容はどれですか？ (a) データモデル — Dataverse テーブルの追加／拡張／再利用 (b) ネイティブ機能 — カメラ、スキャナー、PDF、ペン、ファイル、安全なストレージ (c) 画面／ナビゲーション — リスト、検索、詳細、フォーム、タブ、状態 (d) デザイン — カラーパレット、タイポグラフィ、コンポーネント、情報密度、ブランドルール (e) コネクタ／データソース — SharePoint、Office、カスタムコネクタ (f) 複数セクションにまたがる機能 — 上記の複数が必要となる、ユーザーに見える変更 (g) プレビューのみ (h) キャンセル」

元の依頼と提示された回答だけでは内容がまだ明確でない場合に限り、簡潔な説明を求めてください。未解決の質問は一度に1つずつ尋ねてください。

回答からすでに明らかな場合を除き、シナリオに応じた次の質問のみを尋ねてください。

シナリオ	計画前に確認する意図に関する質問
検索／モバイルでの使いやすさ	既存のどの検索／リスト画面ですか？検索対象とするフィールドはどれですか？読み込み済みの行をローカルで検索しますか、それとも Dataverse／コネクタにサーバー側でクエリを実行しますか？フィルター／並べ替え／対象範囲の指定は必要ですか？
読み込み中、空、エラーの状態	どのリスト画面ですか？リスト画面がない場合、/edit-app で新しいリスト画面を作成しますか、それとも別のデータ画面に状態を適用しますか？すでに改善対象とすべき読み込み中／空／エラーのコンポーネントがあり、重複を避ける必要はありますか？
詳細画面	ユーザーはどのソース画面からレコードを選択しますか？レコードはどのテーブル／サービスのものですか？表示するフィールド／アクションはどれですか？詳細画面への遷移はプッシュ、モーダル、formSheet のどれにしますか？
ブランディング／デザイン	ブランドの参照元は何ですか（ブランドドキュメント、ロゴ、URL、テキストの説明、既存のアプリ）？変更対象はカラーパレットのみ、タイポグラフィ、コンポーネント／情報密度、全面的なリスキンのどれですか？すべての画面を更新しますか、それとも指定した画面のみですか？
Dataverse の作成フォーム	対象の Dataverse テーブルはどれですか？既存のテーブルですか、新しいテーブルですか？必須／編集可能なフィールドはどれですか？フォームはどこから起動しますか？保存後はどうしますか（戻る、詳細を表示、続けて追加）？ルックアップ／ファイル／画像のフィールドはありますか？
バーコード／QR コードのスキャン検索	スキャン機能はどこに配置しますか（新しいスキャナー画面、既存の検索画面のアクション、フォームフィールド）？スキャンした値は何を表しますか（レコード ID、シリアル番号、資産タグ、SKU、カスタムフィールド）？どのテーブル／サービス／フィールドを検索しますか？一致するレコードがない場合や、複数一致する場合はどうしますか？
新しい要件＋画面	追加するユーザーワークフローは何ですか？誰が使いますか？必要なデータ／ネイティブ機能／コネクタは何ですか？ナビゲーションのどこに配置しますか？成功／失敗時の動作はどうしますか？
新しいデータソース	そのデータソースはどのような用途に使いますか？構造化された業務データ（Dataverse）、SharePoint リスト／ライブラリ、コネクタのアクション、その他のコネクタのどれですか？現時点で使用する画面があれば、どの画面ですか？
テーブルまたは統合の削除／置換	このアプリからのみ削除しますか、それともサーバー側の削除も別途意図していますか？残る画面、ルックアップ／ID の補助機能、ネイティブ同期、オフライン動作のうち、引き続きそのテーブルまたは統合を必要とするものはありますか？デフォルトではサーバー上のデータを保持してください。
ワークフローを伴わないネイティブ機能	その機能は何を行い、ユーザーはどこから呼び出し、結果はローカルにとどめますか、それとも既存のデータソースに保持しますか？
プレビューのみ	すべての画面をプレビューしますか、それとも変更した画面／主要な画面のみですか？Visual Companion の自動起動動作を尊重しますか？

追加するか編集するかを判断する前に行う、既存状態の確認：

• 名前付きの画面については、ルートファイルが存在することを確認します。存在しない場合は、作成するか既存の画面を選択するかを尋ねます。
• リストの状態については、対象の画面で LoadingState、EmptyState、ErrorState、refreshing、onRefresh を grep します。不足している、または弱い状態を改善し、既存のものを重複させないでください。
• フォームについては、UI を計画する前に、生成されたサービスのメソッドに create/update があるか確認します。メソッドやテーブルが存在しない場合は、先にデータモデルを追加または更新します。
• スキャナー関連の作業については、画面の作業の前に、src/native/ と計画の Native Capabilities テーブルでスキャナー/カメラのラッパーを確認します。
• 詳細画面については、別の [id].tsx を作成する前に、Navigation Contracts と既存の動的ルートを確認します。
• ブランディングについては、TSX の再構築が必要かどうかを判断する前に、brand/design-system.md、brand/tokens.ts、tamagui.config.ts を確認します。

よくあるフォローアップには、このシナリオカバレッジマトリクスを使用してください。目標は、ユーザーが手動で実行しなければならないコマンドのリストではなく、1 つのユーザープロンプト -> 1 つのオーケストレーションされた編集です。

ユーザーの依頼	計画セクション	適用パス	画面／検証
モバイル向けに検索画面を改善する	Screens	mobile-app:screen-planner の編集パスのみ	指定された検索／一覧画面を再構築し、tsc、ルートチェック、プレビューを実行します
読み込み中、空、エラーの状態を追加する	Screens	画面仕様書 + 既存の TSX の編集	影響を受ける一覧画面を再構築し、読み込み中、空、エラー、再試行、更新の状態が表示されることを確認します
選択したレコードの詳細画面を追加する	Screens。フィールド／サービスが不足している場合のみ Data Model	Screen Map + Navigation Contracts を更新します。データの受け口が不足している場合のみ /add-dataverse または /add-datasource を実行します	必要に応じてルート／フォルダー／レイアウトを作成し、詳細画面とソース一覧／検索のナビゲーションを構築します
会社のブランディングに合わせてデザインを更新する	Design。コンポーネントの文法／密度が変わる場合のみ Screens	/design-system --refresh <dimension> または --reskin	トークンだけでは不十分な場合のみ、影響を受ける画面を再構築します。必ずプレビューします
Dataverse レコードを新規作成するフォームを追加する	Screens。テーブル／列／ルックアップ／作成サービスが不足している場合は Data Model	スキーマ／サービスが不足している場合は /add-dataverse --skip-planning	フォームのルート、作成ペイロードヘルパー、親画面へのナビゲーション、フォーカス時の更新を構築し、作成／更新ペイロードを検証します
バーコードをスキャンし、スキャンした値でレコードを検索する	Native Capabilities、Screens。スキャン対象フィールドが不足している場合は Data Model	/add-native barcode-scanner。対象フィールド／テーブルが存在しない場合のみ /add-dataverse	スキャナー／検索フローを構築し、スキャンコールバックを一時停止／ロックして、サービスフィルターで検索し、プレビューします
カレンダー、アジェンダ、またはスケジュール画面を追加する	Screens → JavaScript Dependencies	承認済みテーブルに react-native-calendars の正確なバージョンを追加し、ビルダーを実行する前に npm install --save-exact を実行します	承認済みのパターンでカレンダー画面を構築します。/add-native や Android/iOS の再ビルドは不要です
新しい画面を伴う要件を追加する	通常は Screens と、要件が示す Data Model、Connector、Native、Design のいずれか	まとまりのある 1 つの機能に分解します。まずデータ／コネクター／ネイティブ／デザインを適用し、その後に画面を構築します	生成されたサービススナップショット、レイアウト、スケルトン／共有コードを生成／更新し、影響を受ける画面を構築します
画面なしで新しいデータソースを追加する	Connector/Data Source。場合によっては Data Model	あいまいな場合は /add-datasource、明確な場合は /add-sharepoint、/add-connector、または /add-dataverse	生成済みサービスとメモリバンクを更新します。ユーザーが UI を求めていない限り、画面の再構築は不要です
Teams／メールのアクションまたはプロファイル検索を追加する	Connectors。利用する場合は Screens	承認後に /add-connector	アクション／読み取りと、その読み込み中／エラー／成功時の動作を接続します。デフォルトでは Dataverse スキーマは不要です
SQL／Excel／SharePoint のデータを追加する	外部テーブル／リストのスキーマを含む Connectors。利用する場合は Screens	承認後に対応するコネクターのリーフを実行します	コネクターが表形式のデータを提供するというだけで、Dataverse モデルを追加しないでください
画面なしで新しいテーブル／エンティティを追加する	Data Model	mobile-app:data-model-architect -> /add-dataverse --skip-planning	生成済みサービスを更新します。必要に応じてサンプルデータをシードします。UI に変更がなければプレビューは不要です
テーブル／コネクター／フローの使用を停止する、またはデータソースを置き換える	Data Model/Connectors と、影響を受ける Screens	Step 6 で利用箇所を更新した後、対応するリーフを使って承認済みの廃止処理を行います	CLI がアプリの登録を削除し、サービス／設定を再生成します。Step 6.5 で残りのソースを検証し、スキーママップを更新します
画面のアーキタイプを削除、名前変更、並べ替え、または変更する	Screens	mobile-app:screen-planner の編集パス	ルートファイル／レイアウト／ナビゲーションコントラクトを更新し、承認済みファイルのみを削除して、ルートチェックを実行します
新しい静的プレビューを生成する	なし。ソースが古い場合を除く	/preview-screens	ソース編集はありません。データ／ネイティブ／デザイン関連の作業は実行しないでください
ユーザーに表示される 1 つの機能に、複数の計画セクションが必要になることがあります。これは許容されており、想定されています。1 つのプロンプトに互いに関連のない複数の機能が含まれている場合は、分けてください。機能を列挙して、どれを先に実行するか確認し、それらの変更をまとめて実行しないでください。

Data Model は条件付きです。 コネクター／アクション／ネイティブ機能を追加するからといって、Dataverse が自動的に必要になるわけではありません。既存のストレージとスキーマを再利用してください。新規または変更された Dataverse テーブル、列、リレーションシップが機能に実際に必要な場合にのみ、Dataverse の変更を計画してください。生成済みサービスが不足しているだけなら、必要なのは再生成であり、新しいスキーマではありません。コネクターの操作と外部テーブル／リストのスキーマは ## Connectors に記載してください。影響を受けない Data Model の内容はそのまま保持してください。

続行する前に、以下の抜け道がないか確認してください。

• データを読み書きする UI の追加を依頼された場合は、画面の作業を始める前に、生成済みサービスが存在することを確認するか、データソースを追加してください。画面ビルダーにサービスを作らせてはいけません。
• Dataverse と SharePoint、または別のコネクターのどれを使うか依頼内容が曖昧な場合は、/add-datasource のルーティングテーブルを読み取り専用で参照し、承認前に選択肢を確定してください。選択したリーフの実行はステップ 5 でのみ行ってください。
• 画面にネイティブラッパーが必要な場合は、画面ビルダーが src/native/* をインポートする前に /add-native を実行してください。
• ネイティブ機能がテンプレートに含まれていない場合は、明確なブロック理由を示して停止してください。ネイティブパッケージをインストールしたり、サポートを偽装したりしてはいけません。
• 画面に純粋な JavaScript ライブラリが必要な場合は、正確なバージョンを指定して ## Screens → ### JavaScript Dependencies に追加し、変更プレビューに含めてから、画面ビルダーの実行前にインストールしてください。JavaScript のみであるかどうかは、パッケージ名の接頭辞ではなく、同梱内容に基づいて判断してください。
• 依頼によってナビゲーションが変わる場合は、画面ビルダーを起動する前に、ルートレイアウトとナビゲーションコントラクトを更新してください。
• 新しい画面を追加する場合は、TSX の構築前に、必要なルートフォルダー、生成済みサービスのスナップショット、共有コード、スケルトンを生成してください。
• native-app-plan.md を書いた時点で停止しないでください。計画の更新は内部チェックポイントであり、アプリの変更と検証がユーザーに見える成果です。

PDF／署名に関する依頼では、最初に目についたセクションだけを編集するのではなく、影響を受けるすべてのセクションに変更を反映してください。

ユーザーの依頼	必要な計画の更新
署名のキャプチャ、承認、ペン、インク、描画を追加する	Native Capabilities：pen-input。Screens：キャプチャ、プレビュー、キャンセル、および該当するエラー状態。保持について確認し、新規または変更された Dataverse ストレージが必要な場合にのみ Data Model を更新する
署名済みの承認を Dataverse の画像として保存する	Data Model：Image 列。Screens：更新前に data:image/png;base64,... を正規化する。アプリ内でキャプチャする場合は Native Capabilities：pen-input
証跡 PDF を生成／エクスポート／印刷する	Native Capabilities：expo-print がある場合に限り pdf-report を追加し、ローカル共有が必要で expo-sharing がある場合に限り sharing も追加する。保持する場合に限り Data Model：File 列。Screens：生成中／失敗／成功の状態
生成した PDF を永続化する	Data Model：Dataverse の File 列または子 Attachment テーブル。Screens：先に行を作成／更新し、その後で File のバイトデータをアップロードする。Native Capabilities：pdf-report
PDF を表示／開く／プレビューする	HTTPS URL またはローカルの file:// URI に対応する @microsoft/power-apps-native-pdf-viewer 0.2.9 以降がある場合は、Native Capabilities：native-pdf-viewer。Screens：URL が無効な場合とビューアーの失敗状態

1 つの PDF／署名に関する依頼で複数の計画セクションが必要な場合は、その旨を伝え、編集ループをセクションごとに実行してください。Dataverse 列や画面状態が計画に存在しないまま、それらを参照するネイティブ機能のエントリーを書いてはいけません。

ステップ 1.5 — 影響のプレビュー（低コストの中止ゲート）

テレメトリのチェックポイント：analyze_edit_impact

アーキテクトを起動したりファイルを変更したりする前に、大まかな影響をプレビューとして表示し、続行／編集／キャンセルのいずれかを選んでもらいます。これは編集規模での /create-mobile-app のステップ 2c に相当します。

以下を算出します。

• コスト区分： 低（既存画面 1 つ）、中（新しいルート／フォーム／詳細画面、またはデータソース 1 つ）、高（複数画面／ナビゲーション／デザイン／データ／ネイティブ）、重大（全面的なデザイン刷新、または画面の大規模な再構築）。
• 影響が見込まれるプランのセクション： データモデル、ネイティブ機能、コネクター／データソース、デザイン、画面。
• 影響が見込まれるファイル： 判明している場合は、画面／レイアウト／ネイティブ／ブランド／生成済み／メモリの各ファイルを正確に示します。
• 影響が見込まれるスキル／エージェント： mobile-app:data-model-architect、mobile-app:screen-planner、mobile-app:screen-builder、/add-datasource、/add-dataverse、/add-sharepoint、/add-connector、/add-native、/design-system、/preview-screens。ユーザーが具体的な実行時の症状を示した場合に限り、任意で /debug-app も含めます。
• 検証ゲート： スキーマ、生成済みサービス、ルートの契約、画面バリデーター、プレビュー。
• 主なリスク： 環境の不整合、サポートされていないネイティブパッケージ、生成済みサービスの欠落、ナビゲーション契約の変更、デザイン全体への影響、インストール済みプラグインキャッシュの古さ。

以下を表示します。

─── Edit impact preview ─────────────────────────────
Intent        <one sentence>
Tier          <cheap|medium|heavy|major> (~<time range>)
Plan          <sections>
Skills/agents <list>
Files         <screen/layout/data/native/brand/memory summary>
Verification  <gates>
Preview       <yes/no>
Risks         <none or bullets>

Choose:
  (a) Proceed
  (b) Edit intent / answer more detail
  (c) Cancel

ユーザーが編集を選んだ場合は、ステップ 1 に戻って編集内容の概要を具体化します。キャンセルを選んだ場合は、ファイルを変更せずに停止します。続行を選んだ場合は、ステップ 2 に進みます。

ユーザーが (d) デザインを選んだ場合：

/design-system のリファレンスを読み、スキルをまだ実行せずに、デザインの変更内容を提案します。ユーザーの説明に基づいて、変更する項目を特定します。

ユーザーの発言	実行先
「色を変える」「パレット」「アクセント」	/design-system --refresh palette
「フォントを変える」「タイポグラフィ」「フォント」	/design-system --refresh typography
「コンポーネントを変える」「ボタン」「カード」	/design-system --refresh components
「間隔を変える」「密度」「コンパクト」	/design-system --refresh density
「ルールを追加」「ルールを削除」「除外」	/design-system --refresh negatives
「アニメーションを変える」「モーション」	/design-system --refresh motion
「全面的なデザイン変更」「デザイン刷新」「新しいテーマ」	/design-system --reskin

プロンプトごとの重大な変更は 1 つまでです。 ユーザーがパレットとタイポグラフィの両方を変更するよう求めた場合は、いったん断り、どちらを先に変更するか尋ねます。これは /design-system 自体の動作と一致します。

提案には、実行時のトークン／プロバイダーの接続設定と、影響を受ける画面も含めます。 /design-system はステップ 5 で実行し、それまではステップ 2〜4 を続けます。 承認前、または --plan-only の実行中にブランド関連の成果物を書き込んではなりません。また、画面の変更が必要な場合は、デザイン更新から直接検証へ進んではなりません。

ステップ 2 — 影響を受けるセクションの再計画

テレメトリのチェックポイント：revise_affected_app_plan

/create-mobile-app と同じ計画プリミティブを再利用しますが、対象は影響を受ける部分に限ります。

サーフェス	create フローから再利用する内容	アプリ編集の対象範囲
Dataverse スキーマ	data-model-architect + /add-dataverse Step 8	新規または変更されたテーブル、列、ルックアップ、計算フィールド、生成されたサービス
コネクタの選択	/add-datasource、/add-sharepoint、/add-connector	新規または変更された外部データ／アクションのサーフェス
ネイティブ機能	/add-native Step 9	編集する画面で必要となる新しいラッパー／コントロール
JavaScript の依存関係	screen-planner + shared/references/javascript-dependency-planning.md	明示的なパッケージの要求、または編集する画面で必要となる既存の JS ライブラリ
デザイン	/design-system Step 9b	トークンの更新、スキンの変更、密度／コンポーネントのルール
ナビゲーション	/create-mobile-app Step 10b	変更されたタブ、スタック、ルートグループ、モーダル／formSheet の表示方法
サービスのスナップショット	/create-mobile-app Step 10.7	データソース／スキーマの変更後、ビルダーの実行前に更新
共有コード + スケルトン	/create-mobile-app Step 10.8	新しい画面、変更されたデータインポート、新しい共有行／カード／フック
画面の実装	/create-mobile-app Step 11	mobile-app:screen-builder のウェーブを通じて、影響を受ける画面のみ
品質チェック	/create-mobile-app Step 11.4	変更された画面ファイルとルートレイアウト

native-app-plan.md の影響を受ける各セクションをそのまま読み、該当する読み取り専用エージェントへの入力として渡します。すべての Task 呼び出しではプラグインの名前空間を使用してください。

Dataverse スキーマ／新規バインディングの作業では、最初に dataverse-change-planning.md を読み、実行してください。過去の計画の全行ではなく、要求された差分と必要な依存関係を使用します。フォアグラウンドで簡潔なエビデンスを取得して検証し、アーキテクトではレガシーのライブ検出ではなく、Dataverse planning mode: required を使用します。 ネイティブ／デザイン／コネクタのみの編集、アプリバインディングの削除、保持されるサービスの更新では、この計画パスをスキップし、古い成果物を再利用しません。

最初の Task の前に、必要なリーフエージェント（mobile-app:data-model-architect、mobile-app:screen-planner、または後で実行する mobile-app:screen-builder のプリフライト）について、サイレントプリフライトを実行します。ホストがエージェントを起動できない場合は、次の文を一度だけ出力します。

「→ このホストではプランナーエージェントを利用できないため、インラインで計画を実行しています。（操作は不要です。これは自動処理です。）」

インラインへのフォールバック規則：

• Data Model：既存の計画、マニフェスト、モデル、編集概要をコンテキストとして使用しますが、判断の根拠には共有ワークフローで検証された簡潔なエビデンスを使用してください。 _dm_section.md と正規化されたスキーマコントラクトを作成し、エージェントの結果と同じ判定バリデーターを実行します。ローカルファイルだけでは、現在のサーバースキーマの証明になりません。
• Screens：agents/screen-planner.md、shared/references/screen-templates.md、既存の画面 TSX を使用して、Screen Map／Navigation Contracts／画面ごとの仕様変更をインラインで作成します。その後、エージェントの結果とまったく同じようにゲートを適用してください。
• Native Capabilities と Connectors：このスキルですでにインライン処理されています。
• リーフエージェントを利用できないという理由だけで、承認を省略してはいけません。

セクション	エージェント（読み取り専用）	出力ファイル
Data Model	mobile-app:data-model-architect	_dm_section.md + .tmp/dataverse-schema-contract.json
Native Capabilities	（インラインで処理 — 個別のエージェントなし）	_native_section.md
Screens	mobile-app:screen-planner	_screens_section.md

Spawn agent: mobile-app:<agent-name>

Prompt:
  Update the existing <section-name> section based on the user's change request.

  User request: <verbatim>
  Current section content: <verbatim>
  Working directory: <absolute path>
  Plugin root: ${PLUGIN_ROOT}
  Phase: planning
  Proposal only: <true for --plan-only or a planning-phase caller>

  Mode: edit (preserve existing decisions where the change doesn't affect them).
  Existing generated app must be updated after approval, so include enough detail for builders to mutate code without guessing.
  Return the updated section as a markdown file.

Data Model の引き継ぎには、次のフィールドもそのまま含めてください。

Dataverse planning mode: required
Normalized Dataverse foreground planning snapshot (validator input only): <SNAPSHOT_PATH>
Compact Dataverse architect evidence: <ARCHITECT_EVIDENCE_PATH>
Structured schema contract output: <working_dir>/.tmp/dataverse-schema-contract.json
Scope: <requested delta and necessary dependencies; preserve unrelated rows>
Native capabilities and connector ownership: <retained approved constraints>

構造化された Dataverse コンテキスト／リビジョンのシグナルは、一般的な再試行の上限に達する前に、共有の計画復旧処理で対応します。その他のシグナルには AGENTS.md を使用してください。 DONE の場合は出力検証に進み、DONE_WITH_CONCERNS: は提示して記録し、NEEDS_CONTEXT: は明確化したうえで一度だけ再試行し、BLOCKED: はアプリの変更前に停止します。1 行目が不明な場合は BLOCKED: malformed agent return とします。 インライン出力を含むすべての Data Model の結果は、共有の判定バリデーターに合格する必要があります。DONE だけでは Step 3 の実行は許可されません。 ネイティブ機能（個別のエージェントなし）の場合は、インラインで対応します。現在の機能テーブルを読み込み、変更を適用して、テーブルを再生成してください。PDF／ペンの行では、ストレージ／出力に関する注記をテーブル内または直下に記載してください。

• native-pdf-viewer 0.2.9+ は HTTPS URL とローカルの file:// URI を開きます。content://、blob:、http:// はサポートしていません。
• pdf-report は、expo-print が存在する場合にのみローカル PDF を生成します。ローカル出力は、native-pdf-viewer 0.2.9+ で開くか、expo-sharing が存在する場合は共有するか、Dataverse の File ストレージにアップロードできます。
• pen-input は PNG データ URI を返します。キャンセルはエラーではありません。Dataverse のターゲットは Image、File、または子 Evidence／Signature 行である必要があります。

コネクター／データソースを編集する場合は、参考資料として connector-planning.md と /add-datasource のルーティングテーブルを確認してください。操作、外部テーブル／リストのスキーマ、利用する画面を含む ## Connectors の差分を提案してください。 Step 2 では、コネクターのスキルを実行したり、接続を作成したり、サービスを生成したりしないでください。コネクターによって新しい画面／フォームが必要になる場合は Screens を更新し、承認後に選択したリーフを Step 5 で処理してください。

削除／置換については、 data-source-removal.md に従ってください。 計画を変更する前に、現在の登録状況を記録し、保持／追加／更新／削除の対象を提案してください。テーブルが記載されていないことを、そのテーブルの削除許可と解釈しないでください。画面以外の利用者とオフライン依存関係を含め、サーバーのテーブル／レコードを保持し、承認された削除対象を Step 6.5 まで引き継いでください。

Step 3 — 意図、計画、アプリ変更プレビューの承認ゲート

テレメトリチェックポイント：approve_app_mutation_plan

Dataverse の計画については、このゲートを表示する前に、現在の正規化済みコントラクトとスナップショットに対して validate-dataverse-planning-decisions.js が終了コード 0 を返す必要があります。修正時もこのチェックを繰り返してください。追加の作成フロー承認ゲートはありません。この編集で既存の UX を維持してください。

別の担当者から計画フェーズの引き継ぎを受けた場合は、ライブ計画を保存したり実装ゲートを開いたりせず、検証済みの提案と懸念点をその担当者に返してください。呼び出し元の計画への同意を、編集を適用する承認として扱わないでください。直接の --plan-only リクエストでは、以下の明示的な計画ドキュメント承認を引き続き適用してください。

変更されたすべての計画セクションについて、ユーザーに左右に並べた差分（または変更前／変更後）を表示してください。また、アプリ変更プレビューも表示してください。

• 編集の概要：意図、対象画面／ルート、データ／ネイティブ／JavaScript／デザインの依存関係、前提条件
• 実行するデータ／スキーマ操作（/add-dataverse --skip-planning、コネクターの追加、ネイティブラッパーの追加）
• アプリから削除するデータソース、利用側の更新内容、保持するサーバーデータの正確な内容
• 要求された場合は、サンプルデータのテーブル許可リストと件数／メディアポリシーの正確な内容。廃止予定のテーブルは除外し、必要なシード用親レコードは明示的な承認がある場合にのみ含めてください。 承認された対象セットが空の場合、シードデータの書き込みは許可されません。
• 作成、書き換え、名前変更、削除する画面ファイル
• 更新するナビゲーション／レイアウトファイル
• 実行する検証コマンド
• preview.html を再生成するかどうか

次のように質問してください。

「この編集を承認して、アプリに適用しますか？ (a) 承認して適用 (b) 修正 — もう一度確認するためのフィードバックを入力 (c) キャンセル — 変更を破棄」

修正の場合 → ユーザーのメモを追加して Step 2 に戻ります。承認の場合 → 続行します。キャンセルの場合 → STOP。計画とアプリは変更せず、そのままにします。

$ARGUMENTS に --plan-only が含まれる場合は、オプション (a) を「承認して計画のみ保存」に変更し、Step 4 の後で停止します。アプリは意図的に変更していないことを明確に伝えてください。

ステップ 4 — プランの差分を作成する

native-app-plan.md の承認済みセクションを承認済みの内容に置き換えます（それ以外のセクションはすべてそのまま保持します）。記録として、統一差分を出力します。

diff --git native-app-plan.md native-app-plan.md
---
+++ Section: Data Model
- | 🆕 Create (Tier 2) | contoso_workitem | ... |
+ | 🆕 Create (Tier 2) | contoso_workitem | ... |
+ | 🆕 Create (Tier 2) | contoso_case | Lookup → account, severity, status |

これが --plan-only の場合は、memory-bank.md を plan_only: true に更新し、正確な後続コマンドを出力して終了します。それ以外の場合は、直ちに続行します。

保存されたプランに記述されるのは承認済みの意図であり、適用の成功ではありません。 Data Model が変更された場合は、新たに承認された _dm_section.md の提案をここに統合します。無関係な編集に古いスクラッチ出力を再利用してはいけません。無関係なセクションを保持し、古いプランに紐付いた実行成果物や承認記録を再利用しないでください。リーフは、検証済みのスキーマ／サービスの結果に基づく場合に限り .datamodel-manifest.json を更新します。保留中の廃止は、ステップ 6.5 まで移行中の状態を維持します。このプランが適用済みであると主張せず、失敗と残りの操作を memory-bank に記録してください。 承認済みの Dataverse 実装では、共有ワークフローの contract_sha256 と最終保存された plan_sha256 を approved_scope で固定し、絶対パスである planning_snapshot、architect_evidence、schema_contract の各パスを保持してください。プランのみの保存では、この実装承認コンテキストは作成されません。

ステップ 5 — アプリの変更を適用する

テレメトリチェックポイント：apply_app_mutations

画面が常に現在のデータ／ネイティブサーフェスを参照してビルドされるよう、依存関係の順序に従ってセクションを適用します。

既存のプランのすべてのセクションではなく、承認済み差分に含まれる操作のみを実行します。ルーター経由や再試行時を含む各引き継ぎで、MOBILE_APP_ORCHESTRATING=1 と上記の明示的な実装コンテキストを渡してください。提供済みの回答を再利用し、未解決の選択肢によってスコープが変わる場合は、承認ゲートに戻ります。 0. データ編集前の環境差異チェック — Dataverse、SharePoint、コネクター、またはサンプルデータに関する作業の前に、memory-bank.md、power.config.json、.resolved-environment.json を比較します。値が一致しない場合は、その値を提示して、どの環境を使用するかユーザーに確認します。確認が取れるまで、テーブルや接続を作成しないでください。

1. データモデル — 計画内のすべての行ではなく、承認済みの差分と以下のスコープを絞った計画コンテキストを指定して、/add-dataverse --skip-planning を実行します。 リーフは証拠と承認のハッシュを検証し、スコープを絞った変更を行う前に、最新のライブ環境との照合を実施します。一部の作成のみを行う高速パス用フラグや、捏造した作成レシートは使用しません。影響を受けるサービスを更新し、検証済みのインベントリを更新して、生成されたサービスがコンパイルできる状態にします。 offline_reconciliation_owner: edit-app を渡します。オフライン照合は Step 5.6 が担当するため、リーフは確認を重ねず、検証済みの差分を返します。 処理後に npm run generate-schemas と npx --no-install tsc --noEmit を実行し、問題が解消されるまで画面の作業に進まないでください。
2. サンプルデータ — Step 3 で承認された、明示的なテーブルの許可リストに含まれるものだけをシードします。変更された画面で使用する新規作成 Dataverse テーブルは候補として提示し、プロジェクトのマニフェスト全体を対象にしないでください。createdThisEdit と、履歴を含むマニフェストの status: new を区別します。既存または再利用する親テーブルは、明示的に含める必要があります。 承認された名前を、検証済みの出力および廃止対象セットと照合します。スコープが空の場合は、シードをスキップします。対象が欠落、未検証、または廃止対象の場合、プロジェクト全体へのシードにフォールバックせず、修正のため担当者に差し戻します。以下の引き継ぎ情報を渡します。 挿入に失敗した場合は部分的な結果を記録し、アプリが空の状態を処理できる場合に限り続行します。シードが完全にカバーされたと報告してはいけません。
3. コネクター／データソース — 内容が曖昧な場合は /add-datasource を読み込んで実行し、承認済みのコネクター変更には /add-sharepoint または /add-connector を読み込んで実行します。維持するソースを更新する場合は、検証済みの ID を approved_scope に指定し、スキル専用の --refresh --data-source-name "<registered-name>" を渡します。更新を追加処理経由にしてはいけません。スキーマ変更を伴わない Dataverse のサービスのみの修復にも、同じ更新分岐を使用します。サービスを再生成し、接続に関するメモを memory-bank.md に記録します。
4. 純粋な JavaScript 依存関係 — 承認済みの ## Screens → ### JavaScript Dependencies テーブルで、新規または変更された行について、shared/references/javascript-dependency-planning.md のインストール契約を実行します。承認は、その正確なパッケージとバージョンへの同意を意味します。画面の作業に入る前にインストールと検証を行います。最終検査でネイティブコード／設定、または互換性のないランタイム依存関係が見つかった場合は、新たに追加したパッケージのみを削除し、失敗した条件を正確に示して中止します。
5. ネイティブ機能 — 新しい機能ごとに /add-native <capability> を読み込んで実行します。不足しているネイティブパッケージをインストールしたり、偽のラッパーを作成したりしないでください。現在のテンプレートが機能に対応していない場合は、その機能をインポートする画面を再構築する前に中止し、ブロックされたことを記録して、不足している上流テンプレートのサポートをユーザーに伝えます。
6. デザイン — 承認済みの /design-system 操作（更新、再スキン、テーマ、またはロールバック）を読み込んで実行します。中間のブラウザータブを抑制するため、子プロセスの環境に CODE_APPS_NATIVE_ORCHESTRATING=1 を含め、上記のスコープ付き MOBILE_APP_ORCHESTRATING=1 コンテキストも併せて指定します。検証前に、その Tamagui 統合リファレンスを変更されたトークン／テーマとプロバイダーの配線に適用します。ブランドのアーティファクトだけでは、ランタイム統合の証明になりません。トークンのみの変更では通常、画面の TSX を書き換える必要はありませんが、コンポーネント、密度、負のルールの変更では必要になる場合があります。早期終了せず、Step 6 で影響を受ける画面を再構築します。 承認済みのカスタムダークパレットでは、リファレンスの 承認済みダークパレット 分岐を実行します。darkTokens.color を appDarkTheme に配線し、続いてプロバイダーの brandedDarkTheme に配線します。エクスポートとキー、および解決後のダークサーフェス／テキストの値を検証します。brand/tokens.dark.ts を作成しただけでは完了ではありません。 Step 5 では追加と更新を適用し、削除は行いません。Data Model の変更が削除のみの場合、短縮されたプランを使って /add-dataverse の追加ワークフローを実行しないでください。古いソースの登録解除も、その利用者の安全な更新も行えません。承認済みの廃止は、ソースの利用者を更新した後の Step 6.5 まで保留してください。

Data Model、Connector/Data Source、JavaScript Dependency、または Native Capabilities に変更を加えた後、画面作業の前に、生成サービス／依存関係／ネイティブラッパーのプローブを再実行してください。画面向けプロンプトには、以前のプランが想定していた内容ではなく、現在ディスク上に存在するものを反映してください。

Dataverse の引き継ぎ（承認済みのスキーマ／新規バインディング作業のみ）：

Invoke skill: /add-dataverse

Context:
  MOBILE_APP_ORCHESTRATING=1
  orchestrator: edit-app
  working_dir: <working_dir>
  phase: implementation
  offline_reconciliation_owner: edit-app
  planning_snapshot: <SNAPSHOT_PATH>
  architect_evidence: <ARCHITECT_EVIDENCE_PATH>
  schema_contract: <working_dir>/.tmp/dataverse-schema-contract.json
  approved_scope: <accepted delta and dependencies, contract_sha256, plan_sha256>

Arguments:
  --working-dir '<working_dir>'
  --plan-section '<working_dir>/native-app-plan.md#data-model'
  --skip-planning

サンプルデータの引き継ぎ（承認済みのシード範囲が空でない場合のみ）：

Invoke skill: /add-sample-data

Context:
  MOBILE_APP_ORCHESTRATING=1
  orchestrator: edit-app
  working_dir: <working_dir>
  phase: implementation
  approved_scope: <approved seed tables, count/media policy, and lookup decisions>
  retiring_tables: <approved retirement list, or empty>

Arguments:
  --working-dir '<working_dir>'
  --tables "<approved-seed-table-logical-names>"
  --exclude-tables "<retiring-table-logical-names-or-empty>"

これらはスキルの引数であり、Dataverse CLI のフラグではありません。必須の親が許可リストに含まれていない場合は NEEDS_CONTEXT が返されます。シーディングを行うリーフは、範囲を拡大したり、カバレッジ要件を満たすために移行中の廃止対象テーブルにシードしたりしてはいけません。

Step 5.5 — 生成サービスのスナップショットを更新する

データソース／スキーマ／コネクターに変更を加えた後、画面ビルダー向けプロンプトを実行する前に、次を実行してください。

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
for svc in src/generated/services/*.ts; do
  [ -e "$svc" ] || continue
  name=$(basename "$svc" .ts)
  methods=$(grep -oE 'static async [a-zA-Z_]+' "$svc" | sed 's/static async //' | tr '\n' ',' | sed 's/,$//')
  echo "| \`$name\` | \`src/generated/services/$name.ts\` | $methods |"
done

native-app-plan.md の ## Screens の直後にある ## Generated Services (snapshot at <ISO timestamp>) セクションを置き換えるか、新たに作成してください。サービスがない場合は、空のテーブルと注記を記載してください。画面ビルダーはこのテーブルを正とみなす必要があります。

承認済みの削除セットに含まれるものの、まだ存在するサービスには、廃止予定の印を付けてください。ビルダーは、それらへの依存関係を新たに導入したり、維持したりしてはいけません。Step 6.5 の後にもこのスナップショットを更新し、実際に残っている出力を記述してください。

これらの後続スキルを手動で実行するようユーザーに依頼しないでください。このスキルがオーケストレーターです。

Step 5.6 — オフラインプロファイルの調整

Step 5 で Dataverse テーブルを作成または拡張した場合、既存の Mobile Offline Profile には、それらのテーブル／列が含まれていない可能性があります（新しいテーブルはデバイスに同期されず、新しい列は空欄で追加されます）。Step 5 の完全なスコープ指定を含む /add-dataverse --skip-planning の引き継ぎでは offline_reconciliation_owner: edit-app が指定されるため、リーフの Step 8.5 ではなく、このオーケストレーターが確認を担当します。フラグだけでは不十分です。この編集で Data Model に変更がなかった場合はスキップしてください。

追加と削除が混在する編集では、返された追加項目と、承認済みの Dataverse の保持／追加セットとの共通部分のみを、プロファイル変更の提示／適用対象にしてください。移行中のマニフェストエントリーが Step 6.5 まで残っているという理由だけで、廃止予定のテーブルをオフラインプロファイルに追加してはいけません。

ネットワークを使わずに、ローカルの差分チェックを実行してください。

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
node "${PLUGIN_ROOT}/scripts/offline-profile-delta.js" --project-root '<working_dir>'

終了ステータスと stdout/stderr を記録し、続行する前に offline-profile-reconciliation.md の失敗時の振り分け手順に従ってください。終了ステータスが 0 以外、status: error、JSON の形式不正／欠落、または不明なステータスの場合は、変更ヘルパーをスキップし、すでに変更が適用されていれば DONE_WITH_CONCERNS、そうでなければ BLOCKED で終了してください。成功として終了してはいけません。有効な no-manifest／no-profile／in-sync の場合は、何も出力せず続行してください。delta の場合は、承認を得て、参照ドキュメントの Scoped helper handoffs を、orchestrator: edit-app、同じ絶対パスの working_dir、phase: implementation、および正確に承認された環境／プロファイル／テーブルの範囲を指定して実行してください。各ヘルパーには、テーブル引数および列引数とともに --working-dir '<working_dir>' を渡し、その後、同じ失敗時の振り分け手順に従って再確認してください。結果を Step 8 の memory-bank エントリーに記録し、保留中の offlineRetirement の結果を消去しないでください。

これらのステータスが対象とするのは追加のみです。以前の試行による offlineRetirement の結果は保持し、削除リーフの更新結果は Step 6.5 で収集してください。in-sync の結果によって、保留中の廃止が解決されることはありません。

Step 6 — 影響を受ける画面を再構築する

Telemetry checkpoint: rebuild_affected_screens

プランの差分とユーザーのリクエストを使って、影響を受ける画面セットを作成してください。

変更の種類	再構築する画面
既存画面の動作／レイアウト／状態／検索の変更	指定された画面
新しい詳細画面	新しい詳細画面と、そこへ遷移する元の一覧／検索画面
新しい作成／編集フォーム	フォーム画面と、フォームを起動してフォーカス時に更新する親の一覧／詳細画面
新しいスキャナー／カメラ／PDF／ペンのワークフロー	機能画面と、そこから遷移する結果／詳細／フォーム画面
表示 UI 用のデータモデルフィールドの追加	そのフィールドを表示または書き込むすべての画面
データソースの削除／置き換え	共有フック／ヘルパーやネイティブのアップロード／同期コードを含む、承認済みのすべての利用箇所。この編集が完了するまで、古い登録は残してください
ナビゲーションパターンの変更	すべてのタブ／ルート画面と、契約が変更されたすべてのルート
デザインコンポーネント／密度／外観の変更	レイアウトの構成が影響を受けるすべての画面。全面的な外観変更の場合は、広範な画面の更新または管理されたスタイルの一括変更を実施してください

ビルダーを起動する前に：

• 承認済みの廃止対象サービス／ソースの一覧を、影響を受けるすべてのビルダーに渡してください。 まだ残っている生成ファイルは移行中の依存関係であり、編集で削除する対象の使用を継続または新たに導入してよいという意味ではありません。
• ナビゲーションが変更された場合は、/create-mobile-app Step 10b のレイアウトルールを使用してルートレイアウトファイルを更新してください。
• 新しい画面用のルートフォルダーが存在しない場合は作成してください。
• データソース／スキーマが変更された場合は、/create-mobile-app Step 10.7 のルールに従って ## Generated Services テーブルを更新してください。
• 影響を受ける2つ以上の画面で、エンティティの行／カード、選択肢マップ、カーソルフック、または保存ヘルパーを共有する場合は、/create-mobile-app Step 10.8a を使用してアプリ固有の共有コードを生成または更新してください。
• 新規画面の場合は、ビルダーを呼び出す前に、/create-mobile-app Step 10.8b のパターンに従って型付きスケルトンファイルを作成してください。
• 既存画面では、スケルトンで上書きしないでください。現在のファイル内容と変更依頼を編集モードでビルダーに渡してください。インポート／データフックが変更される場合は、ビルダーが JSX を追加または修正する前に、必要な箇所だけを更新してください。
• 削除する画面については、Step 3 でユーザーが削除を承認した場合に限り、ルートファイルを削除してレイアウトのエントリーを削除してください。

ナビゲーション／レイアウトのアルゴリズム：

• 承認済みの ## Screens Screen Map と Navigation Contracts を読み取ってください。
• 編集前に、すべての対象ファイルを Expo のルートに正規化してください。正規化後のルートが重複している場合は拒否してください。特に、<parent>/[id].tsx と <parent>/[id]/<child>.tsx の組み合わせは拒否してください。ビルダーの実行前に、詳細画面の契約を <parent>/[id]/index.tsx に移してください。
• 新しいルートごとに、親フォルダーを作成してください。ルートがネストされている場合は、内側の _layout.tsx も作成してください。
• モーダル／formSheet／詳細ルートの場合は、該当フォルダーを管理するレイアウトに、適切な <Stack.Screen name="..." options={{ presentation: 'modal' | 'formSheet' }} /> を追加してください。
• タブ／ルートの変更では、app/(app)/_layout.tsx のルート一覧のみを変更してください。認証／プロバイダーのロジックと、ルート登録に関係のないインポートは保持してください。
• 削除するルートについては、Step 3 でユーザーが明示的に承認した後に限り、ルートファイルを削除してレイアウトのエントリーを削除してください。
• ルート／レイアウトの編集後、ビルダーを起動する前に、利用可能な場合は npm run check-routes --if-present または node scripts/check-routes.js を実行してください。

共有スキャフォールドのアルゴリズム：

• src/components/index.tsx、src/hooks/index.ts、src/utils/index.ts、または src/tokens/index.ts が存在しない場合は、不足しているファイルを shared/samples/src/ からコピーしてください。既存の共有ファイルは上書きしないでください。
• 影響を受ける画面でエンティティカード／行、選択肢マップ、カーソルフック、詳細フック、または保存ヘルパーを共有する場合は、ビルダーを起動する前に、用途を絞ったアプリ固有の共有ファイルを作成または更新してください。
• 新規画面の場合は、該当する /create-mobile-app Step 10.8b のテンプレートを使用して、target_file に型付きスケルトンを作成してください。画面ビルダーの実行前に、スケルトンは return null でコンパイルできる状態にしてください。
• 既存画面では、ファイル全体をスケルトンに置き換えないでください。承認済みの編集でデータ／ネイティブのインターフェイスが変更される場合に限り、インポート／フックを部分的に更新してから、既存の動作を維持するようビルダーに依頼してください。 画面ビルダー作業の前に、ナビゲーション／スケルトンのゲートを実行します。

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
npx --no-install tsc --noEmit

失敗した場合は、レイアウト、ルート名、スケルトンのインポート、生成サービス名、共有エクスポート、またはフックのシグネチャをまとめて修正し、もう一度だけ実行します。壊れたシェルから画面ビルダーを起動しないでください。

Step 6.1 — 画面ビルダーの事前チェックとウェーブ

最初のウェーブの前に、何もしない画面名を指定して mobile-app:screen-builder の Task 事前チェックをサイレントに実行します。利用できない場合は、その旨を一度だけ表示し、agents/screen-builder.md を使ってインラインで作成します。インラインモードでも同じ品質ルールを満たす必要があります。

対象画面を、最大5画面ずつのウェーブにまとめます。各ウェーブで次を行います。

1. ウェーブの開始を表示します：Wave <N>/<W> starting: <screen names>。
2. すべてのビルダーを1つのメッセージで起動し、並列に実行できるようにします。
3. AGENTS.md に従って各ビルダーの1行目を解析します（DONE、DONE_WITH_CONCERNS、NEEDS_CONTEXT、BLOCKED）。未知の1行目は BLOCKED とします。
4. NEEDS_CONTEXT の場合は、計画／ファイル／サービスから不足しているコンテキストを補って1回だけ再試行します。
5. BLOCKED の場合は、承認済みのプレースホルダーでスキップすることをユーザーが選択しない限り停止します。
6. 次のウェーブを起動する前に、ウェーブの後で npx --no-install tsc --noEmit を実行します。
7. ウェーブのゲートに失敗した場合は、エラーを根本原因ごとにまとめ、統合した TypeScript の出力を添えて対象のビルダーを再起動します。画面ごとの再試行は最大2回です。

ウェーブNが問題なく完了するまで、ウェーブN+1を起動しないでください。

mobile-app:screen-builder エージェントを、最大5画面ずつのウェーブで起動します。各ビルダーには次のプロンプトを指定します。

Follow screen-builder.md.
Mode: edit existing generated app.
User change request: <verbatim>
working_dir: <absolute path>
screen_name: <screen id>
route: <route>
target_file: <absolute path>
plan_path: <absolute path>/native-app-plan.md
current_file: <paste current file content if the file exists>

Preserve unaffected behavior from the existing screen. Apply the approved plan diff. If this is an existing screen and no skeleton marker is present, update the screen from current_file instead of falling back to sample layout.

Step 6.5 — 廃止するデータソースの登録解除

承認済みの削除対象が空の場合はスキップします。Step 6 でコンシューマーを更新／削除した後、保持するソースが廃止予定の登録に依存していないことを再確認します。 Dataverse バインディングには /add-dataverse、SharePoint には /add-sharepoint、その他のコネクター／プロシージャ／フローには /add-connector を使い、data-source-removal.md を実行します。その際、削除モード、正確な登録済み ID、および現在承認されているオーケストレーションのコンテキストを渡します。 削除モードはスキル専用の --remove 引数で選択します。CLI には決して渡さないでください。

リーフは追加ワークフローをバイパスし、サポートされている CLI の削除コマンドを使います。このコマンドが .power/schemas/、src/generated/、および power.config.json のクリーンアップを担います。 その後、ランタイムスキーママップを再生成し、登録と生成済み出力が削除または保持されていることを確認して、アプリマニフェストとオフラインへの影響を調整します。 最終検証の前に、Generated Services のスナップショットをもう一度更新します。 何も変更されない場合、不完全なクリーンアップがある場合、またはコンシューマーが残っている場合は、完了として扱えません。新しい計画を完全に適用済みとマークしたり、生成済みファイル／設定ファイルを手動で修正したりしないでください。 各リーフの offlineRetirement ステータスを Step 8 に引き継ぎます。意図的に保持するカバレッジと、保留中の判断／移行も含めてください。これらのステータスを、Step 5.6 の追加のみの結果で置き換えないでください。

Step 7 — 検証

テレメトリチェックポイント：validate_edited_app

変更を加えた後に検証を実行します。根本原因をまとめて修正し、失敗したゲートをもう一度だけ実行します。検証項目は変更内容に応じて選択しますが、アプリに変更を加えた場合は TypeScript の検証が常に必要です。

変更内容に応じて選択する必須ゲート：

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
npm run generate-schemas      # if any data source/schema/connector changed
npx --no-install tsc --noEmit              # always after app mutation
npm run check-routes --if-present

npm run check-routes がなく、scripts/check-routes.js が存在する場合は、次を実行します。

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
node scripts/check-routes.js

画面ファイルを変更した場合は、レポートモードでモバイルプラグインのバリデーターを明示的に実行します。

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
node "${PLUGIN_ROOT}/hooks/validate-screen-quality.js" --report <changed-screen-files-or-app-dir>
node "${PLUGIN_ROOT}/hooks/validate-color-contrast.js" --report <changed-screen-files-or-app-dir>

バリデーターの指摘は、作成フローのゲート失敗と同様に扱います。一度記録し、根本原因ごとにまとめて修正した後、同じバリデーターをもう一度だけ実行します。これらのスクリプトはモバイルワークフロー内でのみ実行します。プラグイン全体のフックとして登録しないでください。

Step 7.1 — 対象を絞ったスタイル品質チェック

画面ファイルが変更された場合は、変更された画面ファイルと、この編集で変更されたルートレイアウトを対象に、/create-mobile-app の Step 11.4 を絞り込んだ形で実行します。

ルール：

1. 利用可能な場合は、validate-screen-quality.js --report と validate-color-contrast.js --report を実行します。
2. ファイルとルールごとに問題をまとめます。
3. 決定的な問題は自動修正します。具体的には、読みやすさの低いトークン、白いテキストの黄色／オレンジ色のバッジ、アイコンのみの要素に欠けている aria-label、欠けている role、小さすぎるアイコンのタップ領域、直接記述された hex トークン、欠けているセーフエリアのパディング、allowFontScaling={false} です。Tamagui 2 コンポーネントには、これらの Web 標準のアクセシビリティプロパティを適用します。生の React Native コンポーネントでは、React Native のアクセシビリティプロパティを維持します。
4. 判断が必要な項目は懸念事項として扱い、無限に修正を繰り返さないでください。複雑なセーフエリアの再構成、曖昧なブランドカラーの選択、大規模な階層の再設計、大幅な JSX の移動を伴う空状態の書き換えなどが該当します。
5. 変更したファイルに対し、同じレポート検証ツールを再実行します。ファイルごと、検証ツールごとの再試行は最大 2 回です。
6. スタイル修正後に npx --no-install tsc --noEmit を実行します。スタイル上の懸念事項は残っていてもかまいませんが、TypeScript のエラーは残してはいけません。

再試行後も自動修正可能な問題が残っている場合は、ファイル／ルールごとの概要を memory-bank.md に記録し、DONE_WITH_CONCERNS とします。

編集によって古い生成済みサービスが明らかになり、検証に失敗した場合は、画面を手作業で変更する前に、該当するデータソースの再生成を一度だけ実行してください。失敗が編集前から存在する無関係な問題による場合は、別途報告し、編集が正常に完了したかのように扱ってはいけません。

Step 8 — プレビューとメモリーバンクの更新

テレメトリチェックポイント：refresh_app_preview_and_history

Step 8 の前に、この /edit-app 実行で行ったすべてのコード編集後に npx --no-install tsc --noEmit がエラーなしで完了している必要があります。Step 7 の tsc 実行後にコードを書いた場合は、npx --no-install tsc --noEmit を再実行し、根本原因をまとめて修正してください。TypeScript のエラーがなくなってから先に進みます。

UI、デザイン、ナビゲーション、ネイティブ操作、または画面に表示されるデータの状態に変更があった場合、あるいはユーザーが明示的にプレビューを依頼した場合は、検証後に /preview-screens を読み込んで実行します。これにより preview.html が再生成され、プロジェクトの visual_companion 設定に従って開かれます。

ユーザーが具体的な実行時の症状を示し、ネイティブ dev-client フローですでに Metro が起動している場合は、静的検証とプレビューの手順後に /debug-app "<symptom>" を呼び出してもかまいません。これは任意の症状デバッグへの引き継ぎであり、検証の必須条件ではありません。画面ごとの実行時チェック、ルートの巡回、React Native Web の使用、Metro HTTP エンドポイントの直接呼び出しは行わないでください。

memory-bank.md に編集内容を追記します。

### Edit: <yyyy-mm-dd> <short title>
- Request: <verbatim or concise summary>
- Intent brief: <target screens/routes, data surface, native capability, design scope>
- Assumptions: <inferred choices or none>
- Skills/agents invoked: <data-model-architect, screen-planner, add-dataverse, screen-builder, etc.>
- Plan sections changed: <Data Model / Native Capabilities / Screens / Design / Connectors>
- App changes: <screens/routes/native wrappers/data sources>
- Verification: <commands/gates + pass/fail/skipped with reason>
- Preview: <preview.html path or not generated>
- Debug handoff: <not requested / /debug-app "<symptom>" invoked>
- Offline retirement: <per-table not-applicable / retained with reason / pending / reconciled with verification>
- Blocks/concerns: <none or list>

最終要約には、アプリで変更した内容、実施した検証、プレビューの場所、症状デバッグへの引き継ぎが依頼されたかどうかを記載します。明示的に --plan-only で実行した場合を除き、コードベースに変更を加えていないと言って締めくくらないでください。 offlineRetirement の結果が pending の場合は、DONE_WITH_CONCERNS を返し、未完了の判断について別途次のように記載します。「アプリの変更は完了しました。オフラインプロファイルには引き続き Orders が含まれており、この範囲を維持するか削除するかの判断は保留中です。」実際のテーブル名に置き換え、検証に合格した場合に限ってアプリの完了を宣言してください。この注記を解消するために、プロファイルのエントリを自動的に削除してはいけません。

メモ

• native-app-plan.md は引き続き、永続的な唯一の信頼できる情報源です。変更を適用する前に計画する必要がありますが、計画は最終状態ではありません。
• 複雑な複数セクションにまたがる編集では、必要なセクションをすべて更新してゲートを通過させてから、依存関係の順序に従って変更を適用してください。Dataverse のストレージがないのにそれを参照するネイティブ機能の項目や、計画されていない画面状態を残さないでください。
• アーキテクトエージェントは、初期作成時に native-app-planner が使用するものと同じです。そのため、ここで計画を改善すると、改善内容が反映されます。
• このスキルは、生成後の反復作業を対象としています。承認された編集に必要であれば、/edit-app が Dataverse、src/native/、ルートレイアウト、画面の TSX、ブランドトークン、preview.html、memory-bank.md を変更しても問題ありません。