uipath-rpa

UiPath RPA アシスタント

UiPath のコード化（C#）および XAML オートメーションの作成、編集、管理、検証、ビルド、実行、デバッグ、テスト、公開を行います。1 つの UIA アクティビティセットで Windows/macOS、デスクトップ／ウェブ、アンカー付きの厳密／ファジーセレクター、Computer Vision、セマンティックマッチングに対応します。uia-configure-target はルートを選択し、ルート間を自動的にフォールバックします。

参照ファイルは必ず読む必要があります。 この SKILL.md は参照先を案内するものであり、参照ファイルの代わりにはなりません。ルール、Task Navigation の項目、またはセクションからファイルが指定されている場合は、操作前にそのファイルを開き、全文を読んでください。grep、流し読み、--help の使用、既存知識による代用はしないでください。カタログで対象を絞った検索が指定されている場合（たとえば、目次には ^## を Grep する、フラグには <command> --help を使うなど）は、該当するセクションだけを読んでください。セクション名が指定されたポインター（file.md § Section）は、同じレベルの次の見出しまでが対象です。参照を省略したり、一部しか読まなかったりすると、ビルド／実行時エラーが発生することがよくあります。

このスキルを使用する場面

プロジェクト、ワークフロー、テスト、ソースファイル、設定、依存関係、アクティビティ、検証／ビルド／実行／デバッグ、アサーション、Integration Service コネクター、デスクトップ／ウェブ UI オートメーションに使用します。

UIA の前提条件

UIA の作業には、最小バージョン以上の UiPath.UIAutomation.Activities が必要です。バージョン、確認方法、検出／インストールコマンド、およびアップグレード同意マトリックス（UIA を許可なくインストールまたはアップグレードすることは絶対にしないでください）については、uia-starter-guide.md § UIA Prerequisites のみを参照してください。バージョンをハードコードしないでください。

前提条件：プロジェクトコンテキスト

作業の前に、プロジェクトディレクトリ内の .claude/rules/project-context.md を確認してください。存在し、最新であれば、そのまま進めてください。存在しない、または古い場合は、スキップゲートを実行し、該当しない場合に限り、environment-setup.md § Project Context Discovery を実行してください。これには、メタデータコメント数と現在の件数の比較、60～70% のしきい値、グリーンフィールド／空／未変更のスキャフォールドに対するスキップゲート、ホスト固有の検出エージェントのオプション、context-files:／SKIP: の処理が含まれます。コンテキストファイルはエージェントが作成します。再読したり、書き換えたりしないでください。セッションごとの検出ディスパッチは最大 1 回です。実行中のエージェントまたはその生成結果を再利用してください。後続の手順でプロジェクトコンテキストの検出が求められた場合は、2 つ目のエージェントを起動せず、先のディスパッチを統合してください。スキップゲートに該当する場合は、検出エージェントを使用せず、そのセクションに従い、ビルド後に両方のコンテキストファイルを自分で作成してください。

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

作成／変更を始める前に、environment-setup.md § Step 0.1 に従ってプロジェクトを特定してください。project.json を見つけて {projectRoot} を確定します。標準的な手順では Studio Desktop の確認は不要です。uip rpa は初回呼び出し時にヘッドレス Studio（UiPath.Studio.Helm NuGet）を自動起動します。Studio Desktop が必要なのは files diff と focus-activity の場合に限られます。コード化 UI の ObjectRepository.cs（Descriptors.*）は、[Workflow]／[TestCase] を含む .cs ファイルが存在する状態で、ファイル単位の validate を実行すると再生成されます（§ Capture-First Fast Path step 2、coded/operations-guide.md § Configure UI Targets を参照）。

プロジェクト種別の判定

PROJECT_DIR を解決したら、まず project.json の targetFramework を確認します。

• "Legacy"、または古いプロジェクトで指定がない場合：Legacy モードです。作業を中止し、references/legacy/legacy-mode-guide.md に従ってください。単独の uip rpa-legacy、.NET Framework 4.6.1、「X」の付かない従来型のアクティビティ、mscorlib を使用します。モダンなルールは適用されません。
• "Windows" または "Portable"：モダンモードです。uip rpa を使用します。Windows はモダンな Windows 専用を意味し、Windows-Legacy ではありません。

uip rpa-legacy は Legacy の場合にのみ使用し、uip rpa が利用できないという理由では使用しないでください。Modern プロジェクトでも終了コード 0 でパッケージ化できてしまうため、代わりに uip rpa の問題を修正してください。

モダンモードでは、次のように判定します。コード型：[Workflow]／[TestCase] を含む .cs があり、スキャフォールドされた Main.xaml 以外にワークフロー .xaml がないもの。XAML 型：ワークフロー .xaml があり、コード型のワークフロー .cs がないもの。両方あるもの：ハイブリッド型。coded-vs-xaml-guide.md を参照し、依頼内容に合わせてください。どちらもないもの：新規プロジェクトで、既定は XAML です。「coded」、「.cs」、「C# workflow」、「coded test case」という明示的な指定、またはコード型固有の条件（DTO／カスタムモデル／単体テスト可能なビジネスロジック）がある場合にのみ、コード型に切り替えます。それ以外では、「ワークフローを作成する」、「X を自動化する」、「自動化を構築する」は XAML を意味します。Task Navigation を経由してください。Legacy の場合は、Legacy ガイドに従います。

作成モードの選択

既存のモードに合わせます。新規または曖昧な作業では、既定で XAML を使用します。以下の表にあるユーザーの明示的な指定、またはコード型固有の条件がある場合にのみ、コード型に切り替えます。

シナリオ	モード	理由
標準的な RPA（Excel、メール、ファイル操作）	XAML（既定）	アクティビティが直接対応しており、コードは不要です
UI 自動化	XAML（既定）	すべてのアクティビティに対応しており、コード型も uiAutomation サービス経由で利用できます
Integration Service コネクタ（XAML）	XAML	IS コネクタのアクティビティでは、XAML 固有の動的なアクティビティ構成を使用します
サブタスクに一致するアクティビティがない	コード型へのフォールバック	XAML から Invoke Workflow File 経由で、小さな .cs を呼び出します
複雑なデータ変換、HTTP、解析	コード型	ネストした XAML アクティビティより C# のほうが自然です
PowerShell スクリプトを呼び出そうとしている	コード型	コード型ワークフローを優先します。本当に PS が必要な場合（管理用コマンドレット、既存の .ps1）は、InvokePowerShell<T> アクティビティを使用してください。Invoke Process と powershell.exe の組み合わせは使用しないでください。powershell-interop-guide.md を参照してください
カスタムデータモデル／DTO	コードソースファイル	XAML では型を定義できません。CodedWorkflow ベースクラスを使わない通常の .cs を使用します
アサーションを含む単体テスト	コード型テストケース	Arrange／Act／Assert を使う [TestCase]
Studio Web で編集するプロジェクト、または Flow ソリューションが開始するプロセスを含むプロジェクト	XAML、VB 式	Studio Web では、コード型ワークフローや C# 式を含むプロジェクトを開けません（Common Rule 2a）
ユーザーがコード型／XAML を明示的に指定	ユーザーの選択	明示的な希望に決して異を唱えないでください

UI 自動化の範囲

アプリ／ブラウザーを開く、クリックする、入力する、表示されている UI をスクレイピングする、フォームを送信する、UI の状態を検証するといった操作には、UiPath UIA のみを使用してください。XAML では NApplicationCard と UIA アクティビティを使用します。コード型では uiAutomation.Open／Attach と Object Repository の記述子を使用します。または、パッケージのコード型作成ガイド § Selector-Only Targets で許可されている場合に限り、CLI で取得したセレクターを TargetAppModel／Target.FromSelector（コード型）経由で使用します。InvokeCode、PowerShell、Selenium、Playwright、CDP、DOM に直接実行する JavaScript、HTTP フォームの POST、外部ブラウザードライバーで代替しないでください。コード型へのフォールバックは、UI 以外のヘルパーに限ります。ターゲット構成を取得できない場合は、外部の近道ではなく、文書化された UIA の指示経路を使用してください。

UIA を使用する作業を始める前に、{PROJECT_DIR}/.local/docs/packages/UiPath.UIAutomation.Activities/ui-automation-guide.md の § 必須：UI コードを書く前にターゲットを生成する を読み、Rule 7 に従って全文を確認してください。禁止ツールの一覧、UIA のみを使った探索、および InvokeJS／InjectJsScript の例外範囲については、このガイドに従います。

プレースホルダーセレクタースタブパターン（実際のアプリにアクセスできない場合）

実際のアプリにアクセスできない場合は、Log スタブではなく、プレースホルダーのセレクター文字列と TODO Indicate マーカーを使って、実際の UIA アクティビティを出力します。実際の NTypeInto、NClick、NGetText、NApplicationCard などを使い、XAML の DisplayName またはコード内の隣接する // TODO[Indicate] に TODO Indicate を記述します。XAML とコードの両方に適用されます。uia-starter-guide.md § Placeholder-Selector Stub Pattern をお読みください。UIA パッケージや CLI は不要です。UI ステップが単に意図をログに記録するだけのワークフローは作成しないでください。ハイブリッドオーケストレーションは Main.xaml → InvokeWorkflowFile → コードヘルパーです。全体のフローチャート、InvokeCode の抽出ルール、パターンについては coded-vs-xaml-guide.md を参照してください。

キャプチャ優先の最短手順

手動ステップに基づいてダイアログやフォームを自動化する場合、または UI テストを行う場合は、キャプチャが終わるまで作成の前提条件への対応を延期します。

1. ルール 7 に従い、uia-starter-guide.md、UIA パッケージのコアガイド、およびそのガイドで指定されているターゲットキャプチャのオーケストレーションリファレンスをすべて最後までお読みください。
2. コードの場合のみ：最初の uip rpa 呼び出し（ウィンドウのベースライン取得を含む）より前に、必要なアクティビティパッケージをすべてインストールし、空の [Workflow] public void Execute() { } クラス（名前空間はルール 17 に従う）を記述します。最初のホスト読み込み時に .local/.codedworkflows/ のスナップショットが作成されます。パッケージやスタブがないと、作成時に CS0246 'CodedWorkflow' が発生する場合があります。uip rpa project close --project-dir "<PROJECT_DIR>" でスナップショットをクリアできます。後の validate では ObjectRepository.cs のみが更新されます。CodedWorkflow.cs のサービスアクセサーと workflows.X の相互呼び出しは、最初の読み込み時のスナップショットのままです。そのため、後からパッケージをインストールした場合や、新しい相互呼び出しワークフローを追加した場合は再生成が必要です。coded/operations-guide.md § Configure UI Targets を参照してください。
3. パッケージガイドの「Window Baseline」を実行します。トップレベルウィンドウを一度一覧表示し、起動するかどうかを判断します。
4. Test Manager、PDD、またはスクリプトから手動ステップを洗い出します。「Click／Enter／Select／Verify」をそれぞれ 1 つの OR 要素に対応付け、画面ごとにグループ化し（パッケージガイド § Capturing from Manual Test Steps）、各要素と画面名をここで決定します。キャプチャ時には、その名前を一字一句変えずに適用してください。
5. 画面ごとに uia-configure-target と画面の移動操作を使ってキャプチャします（パッケージガイド § Multi-Step UI Flows）。作成は画面の境界でのみ行い、同じ画面内の呼び出しの合間には行わないでください。
6. すでにディスパッチ済みのコンテキスト探索を統合し（最大 1 回で、2 回目の起動は行わない）、モード別の作成ガイドを最後まで読んでから、作成と検証を行います。コードの場合：一度だけ validate を実行して ObjectRepository.cs を再生成し、それを読んで、各ターゲットを Descriptors.<App>.<Screen>.<Element> として参照します。メンバー名はこのファイルから取得してください。OR のキャプチャ名は使わず、このファイルがない状態で文字列のターゲット名を使って作成しないでください。

タスクに UI がない場合（データ変換、IS コネクター呼び出し、ヘッドレスのファイル／メール自動化）は、この手順を省略してください。また、タスクに UI があっても、キャプチャ対象となる実際のアプリがない場合（アプリ未インストール、GUI なし、キャプチャを開発者が後で行う場合）も省略し、代わりに「§ プレースホルダーセレクタースタブパターン」を使用してください。Window Baseline だけでは、アプリ／GUI の存在は確認できません。別途確認するか、問い合わせてください。

セッションの事前ウォームアップ

負荷の高い uip rpa 呼び出しを複数回行う場合は、セッション開始時にバックグラウンドで実行します。

uip rpa activities find --query log --output json > /dev/null 2>&1 &

最初の負荷の高い呼び出しには約 22 秒かかります。この処理は validate／build／run／activities get-default-xaml／analyzer-rules list で共有されます。負荷の高い呼び出しが 0 回または 1 回の場合は省略してください。Windows PowerShell では Start-Process powershell.exe -ArgumentList ... を使用してください（pwsh ではありません）。& ではバックグラウンド実行されないためです。Start-Process -FilePath "uip" や .ps1 は絶対に使用しないでください（メモ帳で開かれます）。

重要なルール

共通ルールは1～12です。コード化されたルール13～19は、coded/codedworkflow-reference.md § 重要なルール — コード化ワークフローに記載されています。XAML ルールは独立した16～24／25です。16～21aおよび24～25は、xaml/xaml-basics-and-rules.md § 重要なルール — XAMLに記載され、22～23は以下に記載されています。番号が重複する場合は[Coded]／[XAML]で区別します。「共通ルール10」「ルール21」「ルール24」などの相互参照は、常に番号が一意のルールを指します。

共通ルール（両モード）

1. 存在しないことを確認せずに、プロジェクトを作成してはいけません。 明示されたパス、プロジェクト名、次にCWDの順にproject.jsonを確認し、一致するものがなく、かつユーザーが明示的に作成を依頼した場合にのみ作成します。

2. 必ずuip rpa initを使用してください。 project.jsonやスキャフォールディングを手動で作成してはいけません。ユーザーがテンプレート（「REFramework」「Xをベースに」など）または業界／ドメインのパターン（SAP、ERP、銀行、メインフレーム）を指定した場合は、initの前にuip rpa templates search --query "<term>" --output jsonを実行し、environment-setup.md § テンプレートの選択に従ってください。Marketplaceを黙って選択してはいけません。候補を提示してユーザーに確認し、OfficialとMarketplaceの両方に該当するものがある場合は、どちらにするか確認してください。 2a. すべてのuip rpa initで、--target-frameworkと--expression-languageの両方を明示してください。 省略してはいけません。どちらも作成後に変更できません（ルール23）。--target-frameworkを省略すると、プロジェクトは警告なくWindowsになります。クロスプラットフォーム／Windows以外のランタイム（Linux、コンテナー、サーバーレス）またはStudio WebにはPortableを選択してください。Windows専用機能（Excel COM、従来のOffice、WPF／PresentationFramework、Windows専用のUIA）を使うWindowsランタイム、またはStudio DesktopにはWindowsを選択してください（WindowsはStudio Webで編集できません）。Studio WebがPortableを受け入れるのは、すべてのワークフローがVB式を使用するXAMLである場合に限られます。エラーは20042 Project has coded workflowsおよび20021 ... unsupported programming language: CSharpで、その場合、プロジェクトを開けるのはStudio Desktopのみになります。クロスプラットフォームのランタイムとWindows専用機能の両方を必要とする依頼は矛盾しているため、その点をユーザーに伝えてください。Windows - Legacyは最後の手段です（明示的に依頼された場合、または.NET 4.6.1が必須の場合。VB.NETや「X」なしの従来のアクティビティから推測してはいけません）。作成時はLegacyモードを使用し、最新のinitを使ってはいけません。手掛かりがない場合は、実行ホストを踏まえてWindowsとクロスプラットフォームのどちらかをAskUserQuestionで確認してください。--expression-languageの既定値はVisualBasicです。明示的に指定された場合に限りCSharpを使用してください。initは、インストールされているStudioのdotNetVersionを書き込みます。サポートされないロボットのバージョンでは、アクティビティを実行する前にError converting value "<VERSION>" to type 'UiPath.Shared.DotNetVersion'が発生します。その場合はdotNetVersionをロボットのバージョンに設定し（net10.0が拒否される場合はnet8.0に設定）、再ビルドして再公開してください。

3. フェーズごとの検証。 作成または編集を行うたびに、エラーが 0 件になるまで uip rpa validate --file-path "<FILE>" --project-dir "<PROJECT_DIR>" --output json を実行し、1 回の反復で 1 つずつ修正します。変更したすべてのファイルの検証がクリーンになったら、クリーンになるまで uip rpa build "<PROJECT_DIR>" --output json を実行します。validate は XAML の構造、参照、スキーマを検出し、build はすべてのプロジェクトワークフロー、アナライザーのルール、パッケージ化を対象とします。この分担については、cli-reference.md § 各フェーズの対象範囲を参照してください。build でエラーが発生した場合は、ビルドの詳細ログに記載された各エラーのファイルを取得し、コンパイルエラーに対してそのファイルで validate --file-path を再実行します。ファイルごとの検証ループとビルドループは、それぞれ 5 回までとします。スモークテストはビルドの代わりにはなりません。ビルドが成功した後に run --skip-build を実行することを推奨します（cli-reference.md § スモークテスト）。作成の前提条件として uip rpa analyzer-rules list を実行しないでください。依頼された場合、または同じルール群に違反する状況が繰り返される場合にのみ使用します（スコープを指定しない呼び出しには 1 分以上かかる場合があります。cli-reference.md § analyzer-rules list）。警告は納品のゲート条件ではありません。validate/build のエラーが 0 件なら納品し、警告は依頼があった場合、または受け入れへの影響がある場合にのみ調査します。警告の件数はルール ID ごとに報告してください。警告のためにゲートの試行回数を費やさないでください。想定される UIA 警告（verification-feature、Automation Hub URL、重複する表示名）については、cli-reference.md § 想定される非欠陥警告を参照してください。エラーは全文を確認してください。cli-reference.md § 検証の反復ループを参照してください。

4. 完了を宣言する前に、変更したすべてのファイルを必ず検証し、プロジェクトのビルドを確認してください。 validate がクリーンになっただけでは不十分です。出力を観測できるワークフローでは、最後に run を 1 回実行し、出力を確認してください（execution-maps-guide.md § ゲート ≠ 実行時の証明）。 4a. ファイルツールを使用してください。各 .xaml／.cs を Write で完全に書き込み、その後は Edit してください。スクリプト／テンプレートでワークフローファイルを生成してはいけません。検証と修正はファイルごとに行い、Object Repository のリンクは Edit では維持されますが、再生成では失われます。同様のファイルには、Write の並列実行、ヘルパーワークフロー、または検証済みファイルをコピーして差分を Edit する方法を使用してください。 4b. 呼び出し可能な単位だけを書いてください。再利用されるグループや独立して読み取れるグループを抽出し、単一のアクティビティや短い代入はインラインのままにしてください。引数を渡すためだけに単一のアクティビティをラップしてはいけません。アクティビティが必要とするスコープ（Application Card、アタッチなど）は、抽出する理由にはなりません。そのウィンドウを操作するステップが連続する場合は、そのステップのところでスコープを開いてください。

5. Orchestrator 連携、UIA、ドキュメントには UiPath の組み込みアクティビティを優先してください。純粋な変換、HTTP、解析には、通常の .NET／サードパーティパッケージを使用してください。

6. アクティビティやサービスを使用する前に、必要なパッケージ依存関係が project.json に含まれていることを必ず確認してください。 6a. シリアル化の前に、uip rpa cleanup --dry-run で未使用と判定された依存関係だけを削除してください（cli-reference.md § packages install）。パッケージが唯一の供給元である場合もあります。例：IntelligentOCR.StudioWeb の MergePDFs。アクティビティタグを記述する前に、uip rpa activities find --query "<verb>" --output json を実行し、返された ClassName を使用してください。表示名からタグを推測してはいけません（common-pitfalls.md § Common Activity Name Confusions）。

7. [UIA] UIA アクティビティ（<uix:N*>、uiAutomation.*、Descriptors.*）を使用する前に、references/uia-starter-guide.md を必ず 2 段階で読み込んでください。通常の全体 Read は使用しないでください。まず ^## Conditional Policies を Grep し、次にその行を起点として limit を指定して Read してください。条件付きポリシーのセクションは、該当する場合にのみ読み込みます。その後、パッケージのコアガイドを全編読み、作成前に、その § Documentation の案内に従ってモード作成ガイドを全編読んでください。「単純な」UI であっても例外はありません。セレクターを手書きしてはいけません。uia-configure-target のみを使用してください。セレクターのみを扱うコード作業でも、OR 登録は省略できますが、キャプチャは省略できません。移行時の例外は uia-starter-guide.md § Placeholder-Selector Stub Pattern です。最初に前提条件を確認してください（ルール 7a）。パッケージガイドがない場合は、最低要件を満たしていません。実行／デバッグ、実行時のセレクター復旧、スタブ成果物、UI Library の公開については、スターターガイドに従ってください。 7a. [UIA] uia-configure-target を使用する前に、前提条件を確認してください。 同意の取得を含め、uia-starter-guide.md § UIA Prerequisites に従ってください。パッケージが最低要件を下回る場合、またはコアガイドがない場合、uip rpa uia は利用できず、キャプチャ／インディケーションもこれに依存します。インストール／アップグレードを依頼してください。拒否された場合、または不可能な場合は、別の方法を使わず、TODO Indicate を含む実際のプレースホルダーアクティビティを使用してください。インディケーションのみが許可されるのは、互換性のあるパッケージが存在するものの、キャプチャで要素を認識できない場合に限ります。その場合は、計画ヘッダーに UI capture: indication-only と記録してください。スキャンが継続的に失敗する場合は、Windows がロック中／非対話型でないことを確認してください（LogonUI が表示される場合は、まずロックを解除してください）。ロック解除済みの対話型セッションで失敗した場合に限り、プレースホルダーを使用してください。

8. CLI の出力をプログラムで解析する場合は、必ず --output json を使用してください。 8a. run／debug start の判定は Data に基づいて行ってください。外側の Result だけ、またはログ行のレベルだけで判定してはいけません。キーからバックエンドを特定してください。Headless Helm：Data は {output, hasErrors, errorMessage, profiling, debugState, debugDetails} です。hasErrors が false、errorMessage が null、かつ debugState が null または "Completed" の場合に限り合格です。失敗した run は、Message に JSON フィールドを含み、外側の Result: "Failure" を返します。失敗した debug start は、Result: "Success"、debugState: "Suspended" を返し、例外は debugDetails に含まれます。ライブセッションをキャンセルするか、続行してください。Studio Desktop：Data は {output, errors, logEntries, debugState} です。errors が空で、output が "Session ended" の場合に限り合格です。エントリポイントが見つからない場合、Result: "Success"、空の errors、および output: "Failed to open the file <path>" が返されることがあります。両方の条件を確認してください。Result: "Success" を判定基準として読み取ると、どちらのバックエンドでも壊れたワークフローが成功扱いになります。成功したワークフローでも、Error／Warning のログメッセージが出力される場合があります。これらはワークフローのデータであり、失敗を意味しません。出力されたエンベロープを読んでください。run／debug start では --output-filter を使用してはいけません（現在のバックエンドに存在しないキーを指定したフィルターは、ワークフローの実行後に呼び出しを失敗させます）。また、| tail／| head も使用してはいけません。Helm ではログがエンベロープの前に出力され、Desktop では logEntries が長くなります。cli-reference.md § Capturing the verdict、cli-reference.md § Reading run / debug results、debugging.md § Output Format を参照してください。

9. 活用／再利用／共有ライブラリを探す場合は、テナントフィードを検索してください。ローカルファイルシステム、NuGet.org、キーワードの組み合わせを変えた繰り返し検索は使用しないでください。uip or libraries list --limit 500 --output-filter "<JMESPath>" --output json を実行してください。絞り込み後の結果が 0 件の場合は、キーワードを変えて再検索せず、フォールバック分岐を使用してください。SDD に §16「Shared libraries referenced」が記録されている場合、またはユーザーが以前に共有ライブラリは不要と述べている場合は、検索を省略してください。tenant-library-search-guide.md に従ってください。

10. XAML／コード形式の両方について、すべてのテストケースを project.json → designOptions.fileInfoCollection に登録してください。必須キー、GUID 形式、スキーマ、dataVariationFilePath、およびコード形式の publishAsTestCase については、references/testing-guide.md § project.json Registration と assets/json-template.md を参照してください。

11. テストケースには Given-When-Then を使用してください。references/testing-guide.md § XAML Test Case Structure を参照してください。先頭の案内から、コード形式の場合は coded/operations-guide.md を参照してください。

12. トリガーは uip rpa activities find --query "<event>" --output json で特定し、isTrigger と triggerType を確認してください。連携トリガー（true、"integration"）は、ui:TriggerScope ではなく、Main.xaml のルート Sequence の最初に配置してください。Result をワークフロースコープの変数にバインドし、残りをハンドラーとして使用してください。IS パッケージ（Mail／GSuite／O365／Salesforce／Jira／Slack／ServiceNow／任意の *.IntegrationService.Activities）では ConnectionId が必須ですが、Orchestrator ネイティブの TimeTrigger、QueueTrigger、ManualTrigger では不要です。ローカルトリガー（true、"local"）は、新しいジョブではルートの最初に配置するか、インプロセスロボットではハンドラーを <ui:TriggerScope.Action> に配置して <ui:TriggerScope.Triggers> を使用できます。どちらの配置も有効です。ランタイムモデルに応じて選択してください。接続アセットは不要です。不明なタイプ（将来追加される "scheduled" など）については、同梱ドキュメントを確認し、ユーザーに質問してください。配置方法を推測してはいけません。既存の TriggerScope の内容はローカルトリガーでなければなりません。そこに連携トリガーがある場合は壊れているため、ユーザーに知らせてください。ルートの内容にはどちらの種類も配置できるため、triggerType を確認してください。具体例、SchedulingMode のリファレンス、トリガーアクティビティのカタログ、既存の ui:TriggerScope ワークフローを編集する手順については、trigger-pattern-guide.md を参照してください。

Destination Preflight（両モード）

Studio Web では、単体のプロジェクトではなく、Solution を成果物として扱います。 Studio Web に取り込めるのは Solution のみです。単体のプロジェクトフォルダーは、SW のどちらのワークスペースタブにも表示されません。目印：「Studio Web」、「SW」、「upload to web」、「browser editor」、「cloud workspace edit」。通常どおりビルドした後、uipath-solution に引き渡します：uip solution init <NAME> → uip solution projects import "<PROJECT_DIR>" --solutionFile <SOLUTION>.uipx → uip solution upload "<SOLUTION_DIR>"。Solution を納品します。単体のプロジェクトは、ローカルの uip rpa run と Orchestrator の uip rpa pack → uip rpa publish では引き続き有効です。

実行の規律（両モード）

最後まで実行し、計画タスクが残っている間は作業完了を宣言しないでください。docs/plans/*.md が参照されている、または見つかった場合は、作業開始前と各チェックポイントでヘッダーを読んでください。Execution autonomy: autonomous の場合、すべてのチェックボックスが [x] になるか、具体的な計画の Stop 条件が発生するまで続行してください。interactive の場合、または計画がない場合は、判断を働かせ、重要な決定事項を確認してください。報告前に未チェックの項目を再読して列挙し、Stop 条件が発生していない限り続行してください。コスト、呼び出し回数、一時停止、一部のみ使える状態、複雑さは Stop 条件ではありません。計画ですでに決定された事項が優先されます。計画で指定されている場合、構成、ファイル数、セレクター戦略、キャプチャ方法について AskUserQuestion で質問しないでください。

エラー処理（両モード）

失敗時に異なる処理が必要な外部とのやり取りは、それぞれ Try/Catch で囲みます。不正な入力は BusinessRuleException（再試行せず、人による対応が必要）として分類し、一時的な障害はシステム例外（再試行後にエスカレーション）として扱います。処理が異なる箇所でキャッチし、すべてのアクティビティを囲まないでください。UI アクティビティはすでに待機し、「element not found」で失敗するため、Check App State で保護しないでください（UIA パッケージガイドの Unnecessary Check App State を参照）。純粋なロジックを一律に囲んだり、Catch を空のままにしたりしないでください。スタックトレースを保持するため、Throw New Exception(ex.Message) ではなく Rethrow を使用してください。レジリエンス対応の前に、references/error-handling-guide.md を最後まで読み、例外の分類、Retry Scope の回数／間隔、ContinueOnError、スクリーンショット、Global Exception Handler のスキャフォールド／登録／判定、状態の回復、トランザクション境界、重複作成／部分書き込みを避ける冪等な書き込み／補償書き込み、機密情報のマスキング、キュー／Retry-Scope／GEH／ジョブの各レイヤーにおける再試行の責任範囲を確認してください。

実行マップ（両モード）

すべてのビルド／編集で execution-maps-guide.md に従ってください。このガイドでは、アシスタントのターンごとのバッチ処理（新規開発は最大5件、既存コードの変更も最大5件。落とし穴の検証ターンを含む）を定めています。各ターンでは、依存する uip 呼び出しを1つの Bash 内で && につなぎ、独立した Bash／Read／Edit は並列化してください。stdout または変更結果が必要な場合にのみ分割します。ルール21のカード外探索では、並列にすべての K 個の find を実行し、続いてすべての K 個のドキュメントを Read し、その後すべての K 個の get-default-xaml を実行します。アクティビティを一つずつ実行してはいけません。templates search → init、同意／AskUserQuestion、UIA の状態遷移／表示のまたぎでバッチ処理しないでください。これらは UIA ガイドの画面ごとのゲートに従ってください。

Coded 固有のルール

13–19. [Coded] Coded ワークフロー、テストケース、ソースファイルに着手する前に、coded/codedworkflow-reference.md § Critical Rules — Coded を最後まで読んでください。同じファイルには、§ Coded Quick Reference（ファイルの種類、サービスとパッケージの対応、テンプレート）および § Task Navigation — Coded も記載されています。

XAML 固有のルール

16–21a、24–25. [XAML] XAML の重要ルールは xaml/xaml-basics-and-rules.md § Critical Rules — XAML にあります — 以下のルール 22 の全文を読む義務により、これらもカバーされます。XAML 作業を始める前に必ず読んでおくファイルに含まれています。同じファイルには、XAML タスクのナビゲーションとクイックリファレンスもあります。 22. [XAML] XAML を生成または編集する前に、必ず references/xaml/xaml-basics-and-rules.md を全文読むこと — 通常の全文 Read を、カードの Read とともにジャーニーの最初のターンで実行します（先行する検索は不要です。このファイルには必須の内容だけが含まれています）。 操作別／アクティビティ別のカタログ（編集操作、参照例）は references/xaml/xaml-editing-catalog.md にあり、項目ごとに読み込みます — ^### を Grep し、該当する操作／アクティビティに一致する項目を Read してください。判断に迷ったら読みます。次に、最初の Write／Edit の前に、references/xaml/common-pitfalls.md に照らして計画を確認してください。common-pitfalls.md は、互いに独立した注意事項セクションのカタログです — 最初から最後まで読んではいけません。見出しの一覧を取得し（ファイルに対して ^## を Grep し、事前の出力は不要なので、これも最初のターンで実行します）、次のターンで、これから作成するワークフローのアクティビティ、プロパティ、または機能に見出しが一致するすべてのセクションを Read してください。該当するか判断に迷ったセクションは読みます。これは作成時のゲートであり、単なるトラブルシューティング用リソースではありません。validate では検出できない落とし穴をデバッグするより、事前に確認するほうが効率的です。ターンの配置は execution-maps-guide.md で固定されています。見出し一覧は T1、セクションの Read は T2 で実行するため、このゲートに必要なのは 1 ターンだけで、ファイルごとに grep→Read を繰り返す必要はありません。 23. [XAML] 既存の expressionLanguage または targetFramework は変更しないでください。これらは Common Rule 2a により不変であり、プロジェクト全体に適用されます。その場で変換しないでください。environment-setup.md § Project Conversion に従って確認してください。別の場所にコピーし、新しい init を実行し、すべてのワークフローを再作成して、ユーザーの同意を得た後にのみコピーを削除します。

タスクのナビゲーション

必要な作業	モード	参照先
Legacy で作業する	Legacy	legacy/legacy-mode-guide.md — 最初に参照します。以下の Modern モードのルールは適用されません。
ビルドの各ターンを計画する	両方	execution-maps-guide.md — ビルド／編集に関する作業では、まず参照します
コード／XAML、またはハイブリッドを選択する	両方	coded-vs-xaml-guide.md → environment-setup.md § Designing Project Structure
プロジェクトを作成する	両方	environment-setup.md § Step 0.3
XAML の作成／編集タスク全般（ワークフロー、テストケース、Flowchart／StateMachine／LRW、共通アクティビティ、Data Fabric、IS コネクタ、トリガー、XAML のトラブルシューティング）	XAML	xaml/xaml-basics-and-rules.md — Rule 22 を参照してください。その他の項目については、§ Critical Rules — XAML と § Task Navigation — XAML で案内しています
コードの作成／編集タスク全般（ワークフロー、テストケース、ソースファイル、IS コネクタ、NuGet、API の検出、コードのトラブルシューティング）	Coded	coded/codedworkflow-reference.md — その他の項目については、§ Critical Rules — Coded と § Task Navigation — Coded で案内しています
データ駆動型テスト	両方	testing-guide.md § Data-Driven Testing と Rule 10
Test Manager のセットアップ	両方	cli-reference.md § Test Manager — uip rpa tm connect ／ set-default-project
エラー処理／レジリエンス（Try/Catch、Retry Scope、BusinessRuleException、ContinueOnError、エラー発生時のスクリーンショット、Global Exception Handler、アプリの状態の復旧、トランザクション境界、冪等性／作成の重複回避、キューとローカル再試行の責任分担）	両方	error-handling-guide.md
UI オートメーション	両方	UIA パッケージガイド {PROJECT_DIR}/.local/docs/packages/UiPath.UIAutomation.Activities/ui-automation-guide.md
共有 OR セレクター／UI ライブラリ	両方	uia-starter-guide.md § Object Repository as a Published UI Library
UIA を実行／デバッグする	両方	uia-starter-guide.md § Running UI Automation Workflows
キャプチャしたコントロールを操作する	両方	UIA パッケージガイド § Control-Specific Interaction Patterns
Excel／Word／Mail など	両方	.local/docs/packages/{PackageId}/、フォールバック先は references/activity-docs/{PackageId}/{closest}/
データを操作する（DataTable／LINQ、文字列、RegEx、DateTime、コレクション、JSON）	両方	data-manipulation-guide.md
IS トリガーのライフサイクルを確認する	両方	trigger-pattern-guide.md § Connection Handling と § Server-Side Filtering
ビルド／実行／検証する	両方	cli-reference.md — コマンド別の一覧です。最初から最後まで読まないでください。^## を Grep し、使用する各コマンドのセクションと § Reading run / debug results を読んでください
遅いワークフローのプロファイリング／UI オートメーションの正確性の検証	両方	debugging.md § Profiling Workflow Performance
リモートマシンで設計／デバッグ／実行する（Orchestrator の無人ロボット — Live Authoring と Remote Run Only、remote configure／status／start／stop、--remote によるデバッグ／実行、ファイル転送、リモートシェルコマンド）	両方	remote-session-guide.md
パッケージ化／公開する	両方	cli-reference.md § Pack & Publish to Orchestrator
アナライザールール	両方	cli-reference.md § analyzer-rules list
テナントライブラリを検索する	両方	tenant-library-search-guide.md
ライブラリを作成／公開する	両方	library-authoring-guide.md
PowerShell を呼び出す	両方	powershell-interop-guide.md
Data Fabric エンティティ	両方	cli-reference.md § Data Fabric Entities
プロジェクト構造	両方	environment-setup.md § Project Structure Reference

モードパック

XAML のルール、クイックリファレンス、ナビゲーション、オーサリング、構造、エントリーごとの編集カタログについては、xaml/xaml-basics-and-rules.md と xaml/xaml-editing-catalog.md を参照してください。コード化ルール、クイックリファレンス、ファイル形式、サービス／パッケージの対応付け、テンプレート、ナビゲーション、基底クラスについては、coded/codedworkflow-reference.md を参照してください。

パッケージとアクティビティのドキュメントの解決

手順 1 — パッケージがインストールされていることを確認する

project.json の依存関係を確認します。必ず --include-prerelease を指定してクエリしてください。プレビュー版に必要なアクティビティ、シグネチャ、ドキュメントが含まれている場合があります。インストール済みの場合は、そのバージョンを記録し、利用可能なバージョンをクエリします。より新しい安定版／プレビュー版がある場合は、インストール済みのバージョンと利用可能な最新バージョンを伝え、新しいパッケージがアクティビティ生成を最もよくサポートすることを説明し、アップグレードするか確認します。アップグレードを強制してはいけません。すでに最新の場合は、手順 2 に進みます。インストールされていない場合は、返された最新バージョンをインストールします（プレビュー版も可）。

uip rpa packages versions --package-id <PackageId> --include-prerelease --project-dir "<PROJECT_DIR>" --output json
uip rpa packages install --packages 'id=<PackageId>,version=<LATEST_VERSION>' --project-dir "<PROJECT_DIR>" --output json

手順 2 — アクティビティのドキュメントを探す

まず {PROJECT_DIR}/.local/docs/packages/{PackageId}/activities/<Activity>.md を直接 Read します。直接 Read に失敗した場合は、ファイルが存在しないことを確認できます。Glob／Grep は gitignore された .local/ をスキップするため、存在の証明にはなりません。正確なディレクトリに対して ls を使って一覧を取得してください。ツリー全体を列挙してはいけません。存在しない場合は、references/activity-docs/{PackageId}/ のうち、インストール済みバージョンに最も近いフォルダーを使用します。

UI オートメーションのリファレンス

スキルのリファレンスでは、前提条件／バージョンのゲーティング、実行／デバッグのオーケストレーション、プレースホルダーの成果物、UI ライブラリの公開を扱います。{PROJECT_DIR}/.local/docs/packages/UiPath.UIAutomation.Activities/ にインストールされた UIA パックでは、オーサリング、キャプチャ、CLI 構文、アクティビティのプロパティ、コード化 API、実行時の復旧、同梱の uia-configure-target を扱います。このパックは同じバージョンに対応しており、内容が異なる場合はこちらが優先されます。

UIA については、まず uia-starter-guide.md を読んでください。パックの ui-automation-guide.md は包括的なエントリーポイントであり、ターゲットのキャプチャ、タスクガイド、CLI 一覧、アクティビティのプロパティ、コード化 API、復旧、同梱スキルへの案内を提供します。正確なパスを指定した ls または直接 Read で確認してください。Glob／Grep は使用してはいけません。

完了時の出力

「完了」と報告する前に、計画の完了状況を確認します。docs/plans/*.md を再読します。自律実行中で、Stop 条件に該当せず未チェックのボックスが残っている場合は、作業を再開します。Stop 条件によって作業を停止した場合は、その条件を明示します。対話型の場合は、ステータスを報告します。execution-maps-guide.md § Cross-session memory の条件を満たすメモリパターンのみ保存します。カードに記載されたアクティビティで初回から検証ゲートを問題なく通過した場合、条件を満たす項目はありません。永続メモリが存在する場合は、条件を満たすメモリ、コンテキストファイル、レポートを最終ターンで並行して書き込みます。その後は何も実行しません。

作業が終わったら、次の内容を報告します。

1. 実施内容 — 作成、編集、削除したファイルパス。

2. 検証ステータス — 変更した各ファイルのファイルごとの validate と、プロジェクトレベルの uip rpa build。検証済みと報告するには、どちらもエラーがない必要があります。最後の編集以降にビルドを実行していない場合は、その旨を伝えます。

3. 計画の完了状況 — チェック済みの [x] タスクと、残っているすべての [ ] を、それぞれ Stop 条件の項目または「未到達」とともに示します。

4. 実行方法 — 該当する uip rpa run または uip rpa debug start コマンド。

5. 次の手順 — 接続、OR 要素、プレースホルダー、その他のフォローアップ作業。

6. 問題がありましたか？ — 問題が発生した場合は、「期待どおりに動作しなかった場合は、/uipath-feedback を使ってレポートを送信してください。」と伝えます。

計画のすべてのタスクにチェックが付いていない限り、「完了」「終了」「完成」や「オートメーションを構築しました」と言ってはいけません。それ以外の場合は、「一部完了」「 で停止」または「 によりブロック」と伝えます。